Kirk Pepperdine

效能調校的隱形地雷#

效能調校（performance tuning）往往需要你修改程式碼。而每一段過於複雜或高度耦合的程式碼，都是一顆埋伏著的髒程式碼炸彈（dirty code bomb），等著破壞你的計畫。

• 如果前方道路平坦，你就能預測完成時間
• 如果意外遭遇髒程式碼，預估就變得不可能

連鎖反應的陷阱#

想像你發現了一個效能熱點（execution hot spot），通常的做法是降低底層演算法的強度。假設你告訴主管需要 3-4 小時。

當你開始修復時，卻發現修改破壞了一個相依的部分。由於緊密耦合的事物通常會互相關聯，這種破壞在預料之中。但如果修復這個相依又導致其他遙遠的部分也壞了呢？而且距離原始問題越遠，你就越不容易辨識出這個相依關係並將它納入估算。

突然之間，你的 3-4 小時估算輕易地膨脹到 3-4 週。這種意外的時程膨脹常常一兩天地發生。「快速」重構最終花費數月才完成的情況並不罕見，團隊的信譽和政治資本可能因此遭受嚴重甚至致命的損害。

用軟體指標來預防#

我們其實有許多方法可以衡量和控制程式碼的耦合程度與複雜度。**軟體指標（software metrics）**可以用來計算程式碼中特定特徵的出現次數，其數值與程式碼品質相關。

兩個衡量耦合的重要指標是 fan-in 和 fan-out：

• Fan-out：一個類別直接或間接引用的其他類別數量（也可理解為編譯前必須先編譯的類別數量）
• Fan-in：依賴於該類別的其他類別數量

利用 fan-out（fo）和 fan-in（fi），可以計算不穩定因子：I = fo / (fi + fo)

• 當 I 接近 0 時，套件越穩定
• 當 I 接近 1 時，套件越不穩定

穩定的套件是低風險的重構目標，不穩定的套件則更可能埋有髒程式碼炸彈。重構的目標是讓 I 趨近於 0。

軟體指標可以成為我們追求乾淨程式碼的強大工具。善用它們，在髒程式碼炸彈對效能調校造成嚴重威脅之前，及早識別並消除它們。