個人的最佳化，不一定是團隊的最佳化。如果團隊中的每個人設計能力都是到收放自如、清楚知道什麼是剛好的設計，自然不需要一些限制、一致的標準或規範去束縛他們。
但實務上就是，團隊永遠不知道會不會補進一位還沒到這種功力的成員，而且成員與成員之間，對「剛好」的定義不盡相同，對程式碼風格也不盡相同，而這對團隊程式碼共享、互相支援、產品維護成本都息息相關。
不同團隊跟環境，該採取的步驟、限制、規範本來就會不一樣。在上課中很多學員的問題，我都會提到很多「為什麼我們團隊這樣限制」。很多規範是 over design，得要付出一定的成本，只是在我們團隊，這樣的代價所帶來可降低的維護成本跟風險相當划算。
曾經在團隊中建立的規範
- 3 layer (presentation layer/UI layer, business logic layer/service layer, data access layer/persistence layer) 職責的強制性
- layer 之間一定用 interface 隔開
- 不允許在 context 中直接初始化(new instance)物件，除非被初始化的該物件是 DTO(data transfer object), 也就是拿來當參數傳遞的 value object
- 循環複雜度規定，高標低於10, 低標低於15。（工廠職責不受限於規定）
- 物件相依於 interface, 採依賴注入設計（不一定會使用 DI framework, 但一定有 DI 的設計）
- 繼承深度 < 3 (從自訂物件開始算)
- 程式碼相似度行數限制，高標 < 15 行，低標 < 25 行，但這一條通常是檢查用，而不是規範用。也就是檢查 duplicate 的程式碼是否合理。
- function 程式碼行數應低於 30 行或高度小於螢幕的一頁
標準只是拿來當健康檢查指標用，不代表不可撼動、調整的規定。但特例一定得說得出為什麼，以便大家瞭解、認同並回饋回去標準制訂是否需要調整。
工具
- StyleCop
- SourceMonitor
- Simian
- FxCop
- Visual Studio 程式碼品質分析
- Code Maid
- 建立 Code Snippet (Visual Studio Extension - Snippet Designer 簡介)
- T4 code generator
常用自動測試導入優先序
- 先針對 business layer 做 isolated unit test (含 controller isolated unit tests)
- 針對 data access layer 做 integration test
- 針對 business layer 做 integration test
- 針對 controller 做 integration test (含 Web API site)
- 針對 UI 做 end-to-end web testing
blog 與課程更新內容，請前往新站位置：http://tdd.best/
