Mike Lewis

脆弱的程式碼庫#

每個有業界經驗的人都一定曾經遇過這樣的專案：程式碼庫搖搖欲墜。系統的分解設計（factoring）很差，修改一個東西總是會破壞另一個不相關的功能。每次新增模組時，程式設計師的目標就是盡量少改動，並在每次發佈時屏住呼吸。這就像是用工字鋼玩**疊疊樂（Jenga）**來蓋摩天大樓——注定要出事。

系統需要「手術」#

改變讓人緊張的原因，是因為系統已經「生病」了。它需要醫生，否則只會越來越惡化。你已經知道系統哪裡有問題，但你害怕打破雞蛋來做蛋捲。一個熟練的外科醫生知道手術需要動刀，但也知道這些切口是暫時的，會癒合。 手術的最終結果值得初期的痛苦，患者會恢復到比手術前更好的狀態。

不要害怕你的程式碼#

不要害怕你的程式碼。暫時有東西壞掉又如何呢？ 對改變的癱瘓性恐懼才是讓你的專案陷入困境的原因。投入時間重構將在專案的生命週期中多次回本。額外的好處是，你的團隊在處理這個系統的經驗讓大家都成為專家，知道它應該如何運作。運用這些知識，而不是怨恨它。

具體做法#

• 重新定義內部介面，重組模組，重構複製貼上的程式碼
• 透過減少依賴關係來簡化設計
• 消除邊角案例來降低程式碼複雜度——這些案例往往源自功能耦合不當
• 慢慢地將舊結構過渡到新結構，沿途測試。不要嘗試一次完成大重構——「一次搞定」會讓你在中途就想放棄

做那個不怕切除病灶、騰出空間讓系統痊癒的外科醫生。這種態度是有感染力的，會激勵其他人開始處理他們一直推遲的清理工作。

維護一份團隊認為值得處理的「衛生清單（hygiene list）」。讓管理層相信，即使這些任務不會產出直接可見的成果，它們也會降低成本並加速未來的發佈。永遠不要停止關心程式碼的整體「健康」。