我的程式碼會說話 第2章 劣質程式碼是怎麼產生的

       第二章作者列出劣質程式碼產生的原因。我對「按照流程圖來撰寫程式碼」很有感觸！

2.1 理論知識匱乏

1.複製貼上

2.按照流程圖來撰寫程式碼

採用流程圖設計程式，會把物件關係抽象放在次要地位，會導致圈複雜度變高，導致Bug變多。

3.臨時對策

時間壓力下的臨時對策會累積技術債務，有一天會付出代價。

4.定式思維

(1)  認為動作必須是方法

針對不同的動作採用分支+不同的函數處理，作者建議可用多型+工廠模式取代分支+不同的函數。

(2) 認為狀態只能採用整數來定義

狀態通常也是用分支進行處理，作者建議可用STATE模式（？）來處理。

(3)認為switch-case必須有default

(4)認為Listener 必須寫成匿名類別

??????

(5) 認為for必須有下標

forEach 可取代 for

(6) 認為for必須三段都寫

2.2 對程式語言不熟悉

1.泛型

沒有用泛型導致缺少型別安全驗證。

2.正規表示式

Java語言String.split依據正規表達式進行拆解。

3.List 排序

List 有sort方法可以排序

4.列舉類型

5.toString

Java語言Object類別本身有toString方法，可以override這個方法，System.out.println(object)可按照格式化的字串輸出物件。

6.clone()

clone方法可透過記憶體來複製一個物件，想使用clone方法，類別還需要實作Cloneable介面。

2.3 對開發環境不熟悉

本書使用Java

2.4 對設計方法不瞭解

常見對設計方法不瞭解而造成的問題：

重複與類似

套件結構不清晰

類別責任不明卻

常數資料類別

長方法

複雜分支

類別膨脹

類別爆炸

 

2.5 程式設計的習慣不佳

1. 缺少必要的註解

遺留未完成的功能不寫註解，會導致將來無法尋找。 空白的Exception如果不寫註解，其他人不明白可忽略還是處理上的遺漏。

2.迷信IDE自動產生的程式碼

IDE產生的程式碼僅供參考

3.命名習慣不好

4.沒有管理好程式碼的職責

假設有個驗證電子郵件的函數，最簡單直接的方法是直接寫在UI程式，但這樣就無法重新使用這個函數。

可以把這個函數寫在Util類別，就可以再使用。最好的方法是在電子郵件類別中來實作。

5.對照教材照本宣科

教科書的教材都比較簡單。

6.不考慮呼叫時的形式

例如 setVisible(true) 比 render(true) 表達更清楚。

7.不考慮命名的一致性

例如  remove 代表刪除，就不要再用delete代表刪除。

8.不設計就Coding

2.6 英文能力不足

1.詞性不對

集合性質的變數命名可採用複數形式，例如books比bookList好。

變數應用名詞，action比 act 好。

只有開關兩種狀態可用形容詞，多種取值的屬性應該使用對應的名詞。

 

2.詞彙不對

 

表示縮短 shorten 比 makeShorter 好

表示認證 authenticate 比 doLogin 好

 

Stack 應用 Push 和 Pop，餘額應用balance 而不是leftMoney

3.時態不對

原形動詞會不知道正在發生還是已經發生，用過去式或現在進行式可表達狀態。

4.語法沒有善加利用

判斷cell是否在最後一排的寫法

if(cell.isAtLastColumn()) 比較易讀好懂。

2.7 管理人員的誤導

1.按照模組劃分任務

好處是每個人的責任明確，壞處是產生重複和類似。

2.形而上學的編碼規範

 

(1) 每行長度不能超過80個字元

 

作者建議筆電的情況可採用120字元做為長度限制。

 

(2) 統一採用4個空格縮排

 

(3)最小修改範圍

 

有版本管理工具可以不用太在乎這個規則。

 

(4)程式碼中殘留修改的歷史記錄

 

有版本管理工具可不用留下歷史記錄。

 

(5)方法命名必須以動詞開頭

 

3.時間壓力下的催促

 

4.認為別人一定比自己好

 

5.過分限制開發人員