我始終認為，代碼應(yīng)作為架構(gòu)的一部分，不如此，不足以表達代碼質(zhì)量的重要性。我知道，這與傳統(tǒng)學(xué)院派對架構(gòu)的定義是相悖的。一般認為，架構(gòu)是描述設(shè)計藍圖的宏觀過程，然而，敏捷方法的逐步普遍，卻慢慢開始顛覆這種事前設(shè)計的論調(diào)，代碼不僅要體現(xiàn)架構(gòu)的原則與思想，還要通過代碼對架構(gòu)施加影響，甚至利用代碼來補充與完善架構(gòu)。

　　Yourdon與Constantine認為軟件系統(tǒng)的整體成本等于開發(fā)成本加維護成本，而后者成本遠遠大于開發(fā)成本。維護成本包括理解、變更、測試與部署的成本。其中，所謂“理解”主要還在于維護人員如何理解代碼，尤其是當(dāng)變更發(fā)生時。只有清晰的代碼結(jié)構(gòu)，才有助于我們理解系統(tǒng)；也只有清晰的代碼結(jié)構(gòu)，才能提高代碼質(zhì)量。所以，我認為代碼是納米架構(gòu)（Nano Architecture）的一部分。

　　在將代碼提升到一定高度之后，再讓我們來看看如何改善代碼質(zhì)量。除了需保持代碼的清晰與可讀性之外，代碼的數(shù)量也開始獲得了人們的關(guān)注。InfoQ最近發(fā)表了新聞《代碼是債務(wù)，越少越好》，根據(jù)精益方法中的庫存得到減少代碼數(shù)量的結(jié)論。《修改代碼的藝術(shù)》（英文書名Working Effectively with Legacy Code）的作者Michael Feathers最善于處理遺留代碼，他認為“代碼也是我們持有的庫存，并且需要最小化。”這篇新聞中摘錄的觀點都是警示之語，喚起了我們對代碼數(shù)量的關(guān)注。

　　就本人而言，我認為減少代碼量的最佳做法莫過于提高代碼的重用性。《程序員修煉之道》中認為，重復(fù)的類型包括：
　　1、強加的重復(fù)
　　2、無意的重復(fù)
　　3、無耐性的重復(fù)
　　4、開發(fā)者之間的重復(fù)

　　綜合而論，我認為導(dǎo)致代碼重復(fù)的原因有三個：
　　1、懶惰，所以能夠容忍不好的代碼；
　　2、技能不足，常常會出現(xiàn)不必要的重復(fù)代碼；
　　3、缺乏溝通，團隊之間協(xié)作不夠，因而重復(fù)制造輪子。

　　重用的關(guān)鍵是保持合適的粒度，以及對關(guān)系的解耦。粒度表現(xiàn)在方法級，就是需要編寫許多小的方法，找到類中可以重復(fù)調(diào)用的職責(zé)，抽取為單獨的方法。類級的粒度可以采用輔助類，也可以通過尋找共性，以泛化的方式提取共性特征。對于模塊級，則主要需考慮模塊的復(fù)用原則，合理解除模塊之間的依賴關(guān)系。

　　之所以出現(xiàn)很多糟糕混亂的遺留代碼，主要原因還是在于職責(zé)的分配與分離做得不夠好。職責(zé)的分配不準(zhǔn)確，就可能導(dǎo)致代碼結(jié)構(gòu)不清晰，而職責(zé)的分離做得不好，就可能導(dǎo)致代碼的重復(fù)。在經(jīng)歷了太多維護遺留代碼的工作后，我往往發(fā)現(xiàn)這些遺留代碼都沒有做好模塊的劃分，而是率意為之，有時候甚至?xí)霈F(xiàn)一個龐大的項目，包含了數(shù)據(jù)訪問、業(yè)務(wù)邏輯與界面表現(xiàn)等所有對象，這意味著它沒有合理的分層架構(gòu)。我現(xiàn)在在設(shè)計和開發(fā)時，非常注意對模塊的劃分，盡量避免模塊之間的雙向依賴與循環(huán)依賴。同時，還要站著發(fā)布的角度來思考模塊的劃分與定義。在編碼時，我會思考類的歸屬，要讓其放到合適的位置，既表達出它的職責(zé)，又不會產(chǎn)生糾纏不清的依賴。

　　我們還可以通過用例識別重用。在用例圖中，存在包含、擴展與泛化關(guān)系的用例，都可能是潛在的重用點。

it知識庫：如何減少代碼的量，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。