《軟體構築美學：當專案團隊遇上失控程式，最真實的解決方案》筆記

一. 棕地專案的版本控制

1.處理外來元件的相依性：

將所有需要用到的檔案都複製到應用程式的專案目錄下，並且直接參考該目錄中的檔案。

＊所有的專案參考應該使用相對路徑，而非絕對路徑。因為不是每個開發人員都會把專案原始碼放在相同的路徑下。

2.專案目錄結構：

（1）Build：包含自動建置的相關檔案。

（2）Docs：用來存放任何與程式碼直接相關的文件。

（3）Lib：包含應用程式需要用到的所有外來元件。

（4）Src：

• app：包含應用程式的原始碼。
• test：包含測試專案的原始碼。

（5）Tools：用來儲存任何工具或公用程式。

3.Tools 與 Lib 放置的檔案差異：

（1）Tools：

• 自動建置工具
• 單元測試框架
• 原型（mocking）框架
• 程式碼涵蓋範圍 / 度量分析工具

（2）Lib：

• UI 元件
• 控制反轉（inversion of control）容器
• 記錄（logging）框架
• 物件關聯對應元件
• 自行開發的共用函示庫

4.版本控制系統簽入程序：

（1）簽出你要修改的檔案。

（2）修改檔案內容。

（3）確定程式可以編譯和執行。

（4）取出應用程式的最新版本，並與你修改的部分合併。

（5）再次確認程式能否編譯和執行。

（6）將這次修改的檔案簽入儲存庫。

5.當你想撰寫新功能時，可以考慮為新功能建立分支。從主幹建立一條分支出來，然後在那個分支撰寫新功能，而不要在主幹裡面直接修改。


6.定期為你的程式加上標籤（label），以隨時能回到先前的版本，使用時機包括：

• 每當完成一項功能時
• 當你要大幅度重構程式碼時

二. 持續整合

1.導入 CI 後的簽入程序：

（1）簽出你要修改的檔案。

（2）修改檔案內容。

（3）確定程式可以編譯和執行。

（4）取出應用程式的最新版本，並與你修改的部分合併。

（5）再次確認程式能否編譯和執行。

（6）將這次修改的檔案簽入儲存庫。

（7）等待接收來自建置伺服器發出的通知訊息，以確認建置是否成功。

2.CI 程序的三個基本步驟：

（1）編譯應用程式。

（2）執行自動化測試。

（3）建立可部署的發行版本。

3.當建置失敗時應遵守的三個原則：

（1）所有人都不能再簽入程式碼，除非是為了修正建置的錯誤。

（2）所有人都應該執行取得最新版程式碼的動作。

（3）誰造成問題，誰就要負責修正。

4.平常的程式開發工作，只有在進行簽入程序時，才需要在本機執行自動化建置。

5.發行指的是進行部署時所交付的東西；部署則是將發行安裝到某個作業環境的動作。

三. 自動化測試

1.修正臭蟲之前先寫測試。不要寫那種能順利通過的測試，我們的目的是要顯現目前無法順利通過的地方。因此要撰寫的是應該通過，卻未能通過的測試。

2.撰寫測試的程式碼，也必須通過整合測試。

3.定義測試的方法：

（1）狀態測試：確認物件、物件的屬性，或變數是否符合你預期的狀態。

一般的作法，是在呼叫某個物件方法之後，檢查執行的結果是否正確。

（2）互動測試：測試兩個或多個物件彼此的互動方式。

（3）規格測試：根據使用案例來測試是否符合預期功能。

4.將既有的測試專案整和至開發流程的步驟：

（1）檢驗測試專案。

（2）處理測試。

（3）將單元測試與整合測試分開。

（4）重新檢驗測試。

（5）整合至建置程序。

5.當開發流程碰到阻礙時，不要為了想出解決方法，而讓它一直留在那。

6.在測試專案的根目錄下，至少要有兩個子目錄：

（1）integration：存放整合測試。

（2）unit：存放單元測試。

7.在撰寫測試時，注意那些要花很多時間來撰寫程式碼的地方。測試失敗時，注意那些經常出錯的地方，並蒐集錯誤的相關資訊，記錄經驗與團隊共享。

8.只要任何測試失敗，整個建置就應視為失敗。

四. 軟體度量與程式碼分析

1.度量指標：


（1）程式碼涵蓋範圍（code coverage）：監視執行程式時，有被執行到的程式碼。常用於與自動化測試工具搭配。

（2）循環複雜度（cyclomatic complexity）：根據程式的執行路徑或循環數量決定其複雜度。

（3）類別耦合度（class coupling）：代表類別之間彼此依賴的耦合度。

（4）內聚力（cohesion）：功能與責任的依賴程度。

（5）與主序帶的距離（distance from main sequence）：

<1>痛苦地帶（zone of pain）：代表組件缺乏彈性。亦即組件中包含許多具象類別，而且有很多外部組件依賴它們。

<2>無用地帶（zone of uselessness）：代表組件是抽象且不穩定的。亦即組件中有許多抽象類別或介面，而且它們依賴外部型別的程度非常高。

（6）繼承深度（depth of inheritance）：代表某個類別的繼承階層有多深、或有幾層。

五. 瑕疵管理

1.開瑕疵會議時，必須了解每一個瑕疵的三件事：

（1）能夠對它做什麼？不能做什麼？

（2）該由誰去做？

＊指派的方式有兩種：指派給開發團隊，或指派給測試團隊。如果可以輕易重現瑕疵，而且測試團隊或使用者確認這是個有效瑕疵，此時便可將它指派給開發團隊。反之則指派給測試團隊。

（3）它有多重要？

2.每當開發人員完成一項程式撰寫的工作時，就應從瑕疵清單裡挑幾個瑕疵來處理。

3.無論是什麼原因造成無效、無法重複的瑕疵，都要把它背後的邏輯寫下來，記錄明確且完整的發生原因，與團隊共享。

4.瑕疵報告應包含的資訊：

• 重現瑕疵的步驟。
• 重現瑕疵所需之任何補充資料或檔案。
• 錯誤行為的描述。
• 應有之正確行為的描述。
• 修正瑕疵的過程中所採取的動作。

5.工作項目的優先順序不是第一次決定之後，就不再改變，你應該經常看看有沒有需要重新調整的地方。

＊以數字來代表優先順序

六. 在專案中導入好的物件導向實務

1.要讓類別可以同時具備開放、可擴展性，以及保有封閉的修改特性的方式：寫（重構）成介面。

2.依賴反轉原則（dependency inversion principle）：高階層模組不應該依賴低階層模組，兩者應該依賴在一個抽象層上。抽象層不應該依賴實作細節，而是實作細節依賴抽象層。