|
|
我始終認為，代碼應作為架構的一部分，不如此，不足以表達代碼質量的重要性。我知道，這與傳統學院派對架構的定義是相悖的。一般認為，架構是描述設計藍圖的宏觀過程，然而，敏捷方法的逐步普遍，卻慢慢開始顛覆這種事前設計的論調，代碼不僅要體現架構的原則與思想，還要通過代碼對架構施加影響，甚至利用代碼來補充與完善架構。
Yourdon與Constantine認為軟件系統的整體成本等于開發成本加維護成本，而后者成本遠遠大于開發成本。維護成本包括理解、變更、測試與部署的成本。其中，所謂“理解”主要還在于維護人員如何理解代碼，尤其是當變更發生時。只有清晰的代碼結構，才有助于我們理解系統；也只有清晰的代碼結構，才能提高代碼質量。所以，我認為代碼是納米架構（Nano Architecture）的一部分。
在將代碼提升到一定高度之后，再讓我們來看看如何改善代碼質量。除了需保持代碼的清晰與可讀性之外，代碼的數量也開始獲得了人們的關注。InfoQ最近發表了新聞《代碼是債務，越少越好》，根據精益方法中的庫存得到減少代碼數量的結論。《修改代碼的藝術》（英文書名Working Effectively with Legacy Code）的作者Michael Feathers最善于處理遺留代碼，他認為“代碼也是我們持有的庫存，并且需要最小化。”這篇新聞中摘錄的觀點都是警示之語，喚起了我們對代碼數量的關注。
就本人而言，我認為減少代碼量的最佳做法莫過于提高代碼的重用性。《程序員修煉之道》中認為，重復的類型包括：
1、強加的重復
2、無意的重復
3、無耐性的重復
4、開發者之間的重復
綜合而論，我認為導致代碼重復的原因有三個：
1、懶惰，所以能夠容忍不好的代碼；
2、技能不足，常常會出現不必要的重復代碼；
3、缺乏溝通，團隊之間協作不夠，因而重復制造輪子。
重用的關鍵是保持合適的粒度，以及對關系的解耦。粒度表現在方法級，就是需要編寫許多小的方法，找到類中可以重復調用的職責，抽取為單獨的方法。類級的粒度可以采用輔助類，也可以通過尋找共性，以泛化的方式提取共性特征。對于模塊級，則主要需考慮模塊的復用原則，合理解除模塊之間的依賴關系。
之所以出現很多糟糕混亂的遺留代碼，主要原因還是在于職責的分配與分離做得不夠好。職責的分配不準確，就可能導致代碼結構不清晰，而職責的分離做得不好，就可能導致代碼的重復。在經歷了太多維護遺留代碼的工作后，我往往發現這些遺留代碼都沒有做好模塊的劃分，而是率意為之，有時候甚至會出現一個龐大的項目，包含了數據訪問、業務邏輯與界面表現等所有對象，這意味著它沒有合理的分層架構。我現在在設計和開發時，非常注意對模塊的劃分，盡量避免模塊之間的雙向依賴與循環依賴。同時，還要站著發布的角度來思考模塊的劃分與定義。在編碼時，我會思考類的歸屬，要讓其放到合適的位置，既表達出它的職責，又不會產生糾纏不清的依賴。
我們還可以通過用例識別重用。在用例圖中，存在包含、擴展與泛化關系的用例，都可能是潛在的重用點。
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
