這樣寫 code 好不好?辨識、分析、改善,寫出易讀易維護的程式碼

仙塲大也

  • 出版商: 旗標科技
  • 出版日期: 2024-10-07
  • 定價: $630
  • 售價: 7.9$498
  • 語言: 繁體中文
  • 頁數: 416
  • ISBN: 9863128082
  • ISBN-13: 9789863128083
  • 銷售排行: 🥈 2024/10 繁體中文書 銷售排行 第 2 名

    立即出貨 (庫存 > 10)

  • 這樣寫 code 好不好?辨識、分析、改善,寫出易讀易維護的程式碼-preview-1
  • 這樣寫 code 好不好?辨識、分析、改善,寫出易讀易維護的程式碼-preview-2
  • 這樣寫 code 好不好?辨識、分析、改善,寫出易讀易維護的程式碼-preview-3
  • 這樣寫 code 好不好?辨識、分析、改善,寫出易讀易維護的程式碼-preview-4
  • 這樣寫 code 好不好?辨識、分析、改善,寫出易讀易維護的程式碼-preview-5
  • 這樣寫 code 好不好?辨識、分析、改善,寫出易讀易維護的程式碼-preview-6
  • 這樣寫 code 好不好?辨識、分析、改善,寫出易讀易維護的程式碼-preview-7
  • 這樣寫 code 好不好?辨識、分析、改善,寫出易讀易維護的程式碼-preview-8
  • 這樣寫 code 好不好?辨識、分析、改善,寫出易讀易維護的程式碼-preview-9
  • 這樣寫 code 好不好?辨識、分析、改善,寫出易讀易維護的程式碼-preview-10
  • 這樣寫 code 好不好?辨識、分析、改善,寫出易讀易維護的程式碼-preview-11
  • 這樣寫 code 好不好?辨識、分析、改善,寫出易讀易維護的程式碼-preview-12
  • 這樣寫 code 好不好?辨識、分析、改善,寫出易讀易維護的程式碼-preview-13
這樣寫 code 好不好?辨識、分析、改善,寫出易讀易維護的程式碼-preview-1

買這商品的人也買了...

相關主題

商品描述

內容介紹:

程式要寫得好,不只是執行結果正確就好。
這些情況是否似曾相識?

.過個週末就看不懂自己寫了什麼 code
.修好一邊的 bug,另一邊就出新 bug
.稍微調整功能,就必須地毯式檢查整個專案

【寫程式別再靠直覺和乖乖!】

只要建立優良的程式結構,就算交給其他人接手,
也可以快速地理解、維護、修改原始碼。
本書所傳授的,就是寫出「好程式」的「設計技巧」。

辨識
- 資深軟體架構師的職場實際負面案例,親眼見證業界 bad code
- 低內聚、密耦合、半熟物件、退化註解……認識壞結構就能一眼看破

分析
- 防衛不足、功能分散、職責不清……分析主要弊病,對症下藥
- YAGNI、Tell, Don't Ask、單一責任、最小驚訝……認識設計原則,檢討程式碼

改善
- 防衛子句、值物件、工廠類別、策略模式……各種技巧範例實際解決問題
- 學習地圖、職場心法無私分享,軟體設計不再是紙上談兵

程式人人都能寫,好程式卻是寥若晨星;
掌握軟體設計力,才能創造工程師的專業價值 & 不可取代性!

 

本書特色:

◆293 個精心準備的程式範例
以電商系統與電玩遊戲為例,挑選主流語言共通語法,逐步示範將粗劣程式碼縫補、修整的過程。

詳細列舉優質、劣質程式碼的特徵與影響
基於資深職業經驗,具體說明,在現實程式碼也能活用書中技巧。

觀念基礎扎實,說明清晰易懂
以多種比喻、聯想來說明,而非通篇艱澀道理,可與生活經驗融會貫通。

旁徵博引,融合歷來軟體經典概念
引述軟體設計各大經典書籍,一本集結知識精華,也是銜接經典的橋樑。

作者簡介

作者簡介:

仙塲大也
出身於青森縣。曾任職知名電機製造商,目前在 READYFOR 擔任軟體架構師,致力於推廣重構與軟體設計。
在與劣質程式碼戰鬥的過程中發現了軟體設計的魅力。有空的時候就會在腦中重構程式碼。
曾獲 IT 工程書大賞 2023 技術書部門大賞、Developers Summit 2023 話題賞第 1 名、最佳講者賞第 3 名,多次受邀演講。
Twitter(現 X):ミノ駆動(@MinoDriven)

目錄大綱

目錄:

序言

1 瞭解不良構造的後果
1.1 意義不明的命名
1.2 難以理解的巢狀條件判斷結構
1.3 容易召喚各式各樣惡魔的資料類別
1.4 驅魔的基本

2 設計的第一步
2.1 選擇清楚表達功能的名稱
2.2 不重複使用變數,要為不同功能準備不同變數
2.3 不寫流水帳,把功能區分為函式
2.4 將相關的資料和邏輯統整到類別中

3 類別設計串接一切的設計基礎
3.1
設計時應確保類別能獨立運作
3.2 讓類別獨當一面的設計技巧
3.3 檢驗驅魔的效果
3.4 解決程式結構問題的設計模式

4 活用不可變性質建立穩定的結果
4.1
重複賦值
4.2 可變狀態帶來的意外後果
4.3 不可變和可變的處理方針

5 低內聚七零八落的物件
5.1
靜態函式的誤用
5.2 初始化函式的分散
5.3 通用工具類別(CommonUtil
5.4 使用引數回傳結果
5.5 過多的引數
5.6 成員變數串

6 條件判斷解開迷宮般的流程控制
6.1
巢狀條件判斷造成可讀性降低
6.2 大量重覆的 switch
6.3
重複、巢狀條件判斷
6.4 不要以型別判斷作為條件判斷
6.5 熟練運用介面是邁向中級者的第一步
6.6 旗標引數

7 集合化解巢狀結構的結構化技術
7.1
重覆製作集合原有的函式
7.2 迴圈內的巢狀條件判斷
7.3 低內聚的集合操作

8 密耦合緊密糾纏、難分難解的結構
8.1
密耦合與職責
8.2 密耦合的案例和解決方案

9 危害設計健全性的各種惡魔
9.1 死碼(Dead Code
9.2 YAGNI 原則
9.3 魔法數字(magic number
9.4 字串型別執著
9.5 全域變數
9.6 null 問題
9.7 例外的擱置
9.8 破壞設計秩序的元程式設計
9.9 套件的技術包裝法(技術驅動包裝)
9.10 複製貼上的範例程式碼
9.11 銀彈

10 名稱設計讓人可以看透程式結構的名稱
10.1
召來惡魔的名稱
10.2 設計名稱目標式名稱設計
10.3 需要保持警覺的名稱事項
10.4 用途不明的名稱
10.5 導致構造大幅歪曲的名稱
10.6 和函式的位置格格不入的名稱
10.7 過度縮寫的名稱

11 註解讓程式更穩定、更易修改的文字
11.1
退化註解
11.2 用註解掩飾不良的命名
11.3 註解應標示用途及更改規格的注意事項
11.4 註解原則總結
11.5 註解文件

12 函式優秀的類別必有優秀的函式
12.1
使用同一類別的成員變數
12.2 以不可變為基礎以防止意外行為
12.3 只下令、不詢問
12.4 CQS(命令查詢分離)
12.5 引數
12.6 回傳值

13 建模類別設計的基石
13.1
容易陷入邪惡結構的 User 類別
13.2 模型的思考方式和理想的結構
13.3 不良模型的問題和解決方法
13.4 影響功能性的建模

14 重構讓舊有程式碼脫胎換骨的技術
14.1
重構的流程
14.2 以單元測試防止重構失誤
14.3 規格不明確時的分析方法
14.4 IDE 的重構功能
14.5 重構的注意事項

15 設計的意義與設計師的態度
15.1 本書所談論的設計問題
15.2 缺乏設計將導致開發效率下降
15.3 軟體與工程師的成長性
15.4 解決設計不良的問題
15.5 判斷程式碼好壞的軟體度量
15.6 程式碼的分析工具
15.7 設計目標與性價比
15.8 成為掌握時間的超能力者

 
16 克服職場的阻礙、實踐設計觀念與技術
16.1 溝通
16.2 設計
16.3 實作
16.4 審查
16.5 提升團隊的設計能力

17 軟體設計之旅的下一站
17.1 更進階的軟體設計書籍
17.2 提升設計技能的學習之路