[打造可維護軟體] Part III

source: google

前篇中我們關注了元件與元件間的連結，在本書的最後幾章，作者再把範圍擴大，談到了系統的整體規劃，以及好的RD的工作習慣。

保持架構元件平衡

物件導向的一大特色，就是「封裝」。封裝的下一步則是分層。分層後的程式有個很大的好處：「表達抽象意圖」。Teddy Chen曾說過：「…簡言之，越靠近使用的就越上層，越靠近I/O的就越下層。」

Joost Viesser認為：

• 最上層的元件數量應落在6–12之間，9是很理想的數字，
• 各元件尺寸應差不多大

原因很簡單：好查、好找。

最上層的元件因為最接近user，因此應該最能表達出抽象邏輯。所以，如果每個元件尺寸與涵蓋範圍不一樣大，分析與維護工作就不容易，因為一定會有少數元件做太多「不應屬於它份內的事」。此外，要達到平衡，必定也要先做到「邊界明確」，而一旦元件間能有明確分界，再佐以清楚的命名，程式自然好查好找了。

保持小規模的程式碼基礎

近來，産品管理吹起一陣「敏捷風」，而程式也是一樣。小自method與class，大至系統，都強調「靈活」。要怎麼靈活？首先，大就不可能靈活了。近年流行的SaaS，FaaS …什麼都要aaS一下才可以，其實講的就是「專心做一件事」。

系統一大就切小、一大就切小…惟有如此，才能永遠保持元件間的鬆散耦合，隨時保持彈性。

自動化測試 與 撰寫乾淨的程式碼

我的天啊，這兩項不用我再多解釋了吧？我不想花任何力氣解釋自動測試與Clean Code的重要性了。

「連李倩蓉都開始看Clean Code了，你還沒看過？」

沒看過Clean Code沒關係，看這本吧：「打造可維護軟體 — Java版」

快去買一本來看吧！