我始終認為，程式碼應作為 網頁設計 架構的一部分，不如此，不足以表達程式碼品質的重要性。我知道，這與傳統學院派對架構的定義是相悖的。一般認為，網頁設計架構是描述設計藍圖的宏觀過程， 然而，敏捷方法的逐步普遍，卻慢慢開始顛覆這種事前設計的論調，程式碼不僅要體現網頁設計架構的原則與思想，還要通過程式碼對架構施加影響，甚至利用程式 碼來補充與完善網頁設計架構。
Yourdon與Constantine認為軟體系統的整體成本等於開發成本加維護成本，而後者成本遠遠大於開發成本。維護成本包括理解、變更、測 試與部署的成本。其中，所謂“理解”主要還在於維護人員如何理解程式碼，尤其是當變更發生時。只有清晰的程式碼結構，才有助於我們理解系統；也只有清晰的 程式碼結構，才能提高程式碼品質。所以，我認為程式碼是納米架構（Nano Architecture）的一部分。
在將程式碼提升到一定高度之後，再讓我們來看看如何改善程式碼品質。除了需保持程式碼的清晰與可讀性之外，程式碼的數量也開始獲得了人們的關注。 InfoQ最近發表了新聞《程式碼是債務，越少越好》，根據精益方法中的庫存得到減少程式碼數量的結論。《修改程式碼的藝術》（英文書名Working Effectively with Legacy Code）的作者Michael Feathers最善於處理遺留程式碼，他認為“程式碼也是我們持有的庫存，並且需要最小化。”這篇新聞中摘錄的觀點都是警示之語，喚起了我們對程式碼數 量的關注。
就本人而言，我認為減少程式碼量的最佳做法莫過於提高程式碼的重用性。《程式師修煉之道》中認為，重複的類型包括：
1、強加的重複
2、無意的重複
3、無耐性的重複
4、開發者之間的重複
綜合而論，我認為導致程式碼重複的原因有三個：
1、懶惰，所以能夠容忍不好的程式碼；
2、技能不足，常常會出現不必要的重複程式碼；
3、缺乏溝通，團隊之間協作不夠，因而重複製造輪子。
重用的關鍵是保持合適的粒度，以及對關係的解耦。粒度表現在方法級，就是需要編寫許多小的方法，找到類中可以重複調用的職責，抽取為單獨的方法。類級的粒 度可以採用輔助類，也可以通過尋找共性，以泛化的方式提取共性特徵。對於模組級，則主要需考慮模組的複用原則，合理解除網頁設計模組之間的依賴關係。
之所以出現很多糟糕混亂的遺留程式碼，主要原因還是在於職責的分配與分離做得不夠好。職責的分配不準確，就可能導致程式碼結構不清晰，而職責的分離 做得不好，就可能導致程式碼的重複。在經歷了太多維護遺留程式碼的工作後，我往往發現這些遺留程式碼都沒有做好模組的劃分，而是率意為之，有時候甚至會出 現一個龐大的專案，包含了資料訪問、業務邏輯與介面表現等所有物件，這意味著它沒有合理的分層架構。我現在在設計和開發時，非常注意對模組的劃分，儘量避 免模組之間的雙向依賴與迴圈依賴。同時，還要站著發佈的角度來思考模組的劃分與定義。在編碼時，我會思考類的歸屬，要讓其放到合適的位置，既表達出它的職 責，又不會產生糾纏不清的依賴。
我們還可以通過用例識別重用。在用例圖中，存在包含、擴展與泛化關係的用例，都可能是潛在的重用點。
轉貼來源：網頁設計知識部落格
http://www.piece2ec.com.tw/news.asp?ID=1894
參考文獻：
1.易芙瑛，2002，影響企業導入可延伸性企業報告語言(XBRL)之因素探討，私立中原大學 會計系碩士班未出版論文。
2.吳政隆，2002，以XML 為資料擷取介面之審計系統實作，私立中原大學 會計系碩士班未出版論文。
3.陳柏任，2001，網際網路財務報告揭露之系統架構研究，私立中原大學 會計系碩士班未出版論文。
留言列表
