打造可維護軟體C#版 第九章 保持小規模的程式碼基礎

       第九章作者再提高層級談到系統，小系統比大系統還要容易維護。一般工程師不會接觸到系統的層級，知道觀念如同種下種子還是對未來可能會有幫助。

指導方針：

盡可能保持小規模的程式碼基礎

避免程式碼基礎過度增長，積極減少小系統規模

小產品、小專案與小團隊是成功的要因，能夠提升系統的維護性。

 

9.1  動機

 

以建構大型程式碼基礎為目標的專案比較容易失敗

大型程式碼基礎較難維護

大型系統的缺陷密度較高

 

9.2  如何應用這個指導方針？

要想要保持較小的程式碼基礎，首先必須限制系統功能，然後有限制地撰寫程式碼數量。

防止範疇蔓延：

範疇蔓延scope creep 是常見的現象，需求在開發過程中不斷增加，可能導致可有可無的功能性。

在額外功能的價值與專案延遲或維護成本之間權衡取捨，避免範疇蔓延的現象。

功能標準化：

程式行為與互動一致（？）避免稍微不同的方式實作相同的核心功能，功能標準化讓程式可以重新利用。

技術層面的措施

不要複製與貼上程式碼：

參考第四章避免製造重複的程式碼。

重構既有程式碼：

使用第三方程式庫和框架：

使用前人完成的程式碼，可以避免不必要的工作。

拆分大型系統：

將大型系統拆分多個小系統。

9.3 常見的反對意見

反對意見：生產力量測有礙程式碼基礎的規模縮減

有的公司用程式碼的長短來評估員工有沒有做事。作者指出這樣只會逼員工用複製貼上的方法寫程式。

生產力應該根據增加的價值來評估，而不是增加的程式碼行數。

反對意見：編程語言有礙程式碼基礎的規模縮減

努力還是會有成果，即使是那些很難抽象化的低階語言。

反對意見：系統複雜性促使程式碼不得不複製

分析程式碼可找到一些共同的功能，最後可找到一段能夠獨立引用的程式碼。

反對意見：因為平台架構關係，我們無法拆分程式碼基礎

一個有效縮減程式碼基礎的辦法就是將系統解耦合，並且轉成基於插件的架構。

反對意見：拆分程式碼基礎導致程式碼重複

參考第四章，可以選擇將常用功能寫成單獨的擴充，作為共通程式碼基礎的一部分。

反對意見：由於緊密耦合，根本無法拆分程式碼基礎

要對系統解耦合，可撰寫一些特定介面，作為功能的統一進入點。

目的是實作可以獨立維護的子系統，而不是獨立運作的系統。