打造可維護軟體C#版 第九章 保持小規模的程式碼基礎
第九章作者再提高層級談到系統,小系統比大系統還要容易維護。一般工程師不會接觸到系統的層級,知道觀念如同種下種子還是對未來可能會有幫助。
指導方針:
盡可能保持小規模的程式碼基礎
避免程式碼基礎過度增長,積極減少小系統規模
小產品、小專案與小團隊是成功的要因,能夠提升系統的維護性。
9.1 動機
以建構大型程式碼基礎為目標的專案比較容易失敗
大型程式碼基礎較難維護
大型系統的缺陷密度較高
9.2 如何應用這個指導方針?
要想要保持較小的程式碼基礎,首先必須限制系統功能,然後有限制地撰寫程式碼數量。
防止範疇蔓延:
範疇蔓延scope creep 是常見的現象,需求在開發過程中不斷增加,可能導致可有可無的功能性。
在額外功能的價值與專案延遲或維護成本之間權衡取捨,避免範疇蔓延的現象。
功能標準化:
程式行為與互動一致(?)避免稍微不同的方式實作相同的核心功能,功能標準化讓程式可以重新利用。
技術層面的措施
不要複製與貼上程式碼:
參考第四章避免製造重複的程式碼。
重構既有程式碼:
使用第三方程式庫和框架:
使用前人完成的程式碼,可以避免不必要的工作。
拆分大型系統:
將大型系統拆分多個小系統。
9.3 常見的反對意見
反對意見:生產力量測有礙程式碼基礎的規模縮減
有的公司用程式碼的長短來評估員工有沒有做事。作者指出這樣只會逼員工用複製貼上的方法寫程式。
生產力應該根據增加的價值來評估,而不是增加的程式碼行數。
反對意見:編程語言有礙程式碼基礎的規模縮減
努力還是會有成果,即使是那些很難抽象化的低階語言。
反對意見:系統複雜性促使程式碼不得不複製
分析程式碼可找到一些共同的功能,最後可找到一段能夠獨立引用的程式碼。
反對意見:因為平台架構關係,我們無法拆分程式碼基礎
一個有效縮減程式碼基礎的辦法就是將系統解耦合,並且轉成基於插件的架構。
反對意見:拆分程式碼基礎導致程式碼重複
參考第四章,可以選擇將常用功能寫成單獨的擴充,作為共通程式碼基礎的一部分。
反對意見:由於緊密耦合,根本無法拆分程式碼基礎
要對系統解耦合,可撰寫一些特定介面,作為功能的統一進入點。
目的是實作可以獨立維護的子系統,而不是獨立運作的系統。
留言
張貼留言