Chap8 注重實效的專案

專案開發中的注意事項與小技巧。

注重實效的團隊：針對團隊，前述的技術全都有效。

不要留破窗戶：在團隊中，不要容許小的、沒有人願意去修改的小錯誤。

煮青蛙。隨時注意專案和環境的新變動，注意專案範圍的擴大、新的特性和需求等。不要讓變動失控。

交流：文件、術語應該一致。為了加強交流，可以使用一個團隊名稱，尤其是奇怪的名稱，以帶來歸屬感。（我們組的名稱就挺奇怪的……）

不要重複自己：要有良好的交流與分工，開發過程中職能不要重複。如果不該自己負責的地方出現了問題，不要自己解決，而應該去找負責人。

正交性：用模組功能將成員分組，而不要根據分析師、程式設計師、測試人員這樣的等級劃分將成員分組，每個團隊自給自足。分析、程式設計、測試是不正交的，而且隱含了等級關係，不利於合作。

自動化。

知道何時停止：要給別人空間，尤其是組長要給組員空間。

無處不在的自動化：不要做重複的工作。

用批處理檔案/指令碼實現可自動化的內容。用cron等工具實現週期性的行為，如備份、網站構建等。

專案編譯時，用makefile生成程式碼、編譯、測試。要將構建自動化，定期編譯並測試。如果構建與常規構建不同，如有特殊的版本號或某個優化方式，可以用單獨的make目標表示，並一定要另外測試。

對專案自動化管理。如果用網站實現內部溝通，網站應該自動生成，這同樣是DRY原則的應用。批准流程也可以自動化。

無情的測試：要積極地測試，最好自動化測試。

主要的測試型別有：

單元測試，對單個模組進行測試。

整合測試，對模組整合的子系統進行測試，其實是單元測試的拓展。

驗證和校驗，檢查系統是否滿足使用者需求、是否能夠處理現實資料。

資源耗盡、錯誤及恢復。可能的限制包括：記憶體、磁碟、CPU頻寬、磁碟頻寬、網路頻寬、視訊解析度、掛鐘時間、調色盤……要儘量檢查環境限制。如果失敗，要儲存狀態、避免工作丟失。

效能測試。

可用性測試。

測試的方法包括：

迴歸測試，改動程式碼後檢查測試輸出與之前是否一致，以檢查在改動時有沒有破壞功能。

測試資料，可以從現實世界獲取或人工合成。人工合成的資料包括隨機資料和特殊的極端資料。

測試GUI。首先測試GUI背後的邏輯，確定沒有問題之後用工具或人工測試GUI。遺憾的是測試GUI的工具大多不完善。

對測試進行測試，故意引發bug，觀察測試系統能否捕捉。

徹底測試是不可能的。（完美永遠是不可能的……）

普通測試的時間應該儘可能頻繁，一旦程式碼存在就要測試。可以自動化測試。壓力測試之類的特殊測試可以不那麼頻繁，但仍要定期測試。

如果發現過一個bug，那麼要將這個bug加入測試集，而不要相信這個bug不會復現。

全都是寫：講文件的寫法。文件分為內部文件（原始碼註釋，設計與測試文件）和外部文件。

對於內部文件：

程式碼中的註釋應該解釋程式碼要做何事及為何這麼做，而不應該解釋如何做。如何做會與程式碼重複。程式碼中的變數名應該清晰易懂，貼合功能。註釋中不應該出現：程式碼中的函式列表，修訂歷史，檔案使用的其它檔案列表，檔名。這些都可以通過其它工具得到。

可執行文件：可以對文件進行解析，分析出模式自動生成程式碼，如資料庫schema。

文件很容易過時，所以在網站顯示往往比列印更方便。

可以使用標記語言，如html（我又想到了markdown）編寫文件，這樣更方便、功能更強大，且內容和外觀可以解耦。

極大的期望：滿足使用者需求很重要，所以最好時時就需求進行溝通，避免取得的進展不是使用者想要的。不過為了避免使用者缺乏驚喜，有必要比需求略多一點特性。

傲慢與偏見：有必要對程式碼進行署名，可以帶來自豪感，同時減少糟糕的程式設計。但是要避免領地意識。