91 的團隊開發規範與限制

個人的最佳化,不一定是團隊的最佳化。如果團隊中的每個人設計能力都是到收放自如、清楚知道什麼是剛好的設計,自然不需要一些限制、一致的標準或規範去束縛他們。

但實務上就是,團隊永遠不知道會不會補進一位還沒到這種功力的成員,而且成員與成員之間,對「剛好」的定義不盡相同,對程式碼風格也不盡相同,而這對團隊程式碼共享、互相支援、產品維護成本都息息相關。

不同團隊跟環境,該採取的步驟、限制、規範本來就會不一樣。在上課中很多學員的問題,我都會提到很多「為什麼我們團隊這樣限制」。很多規範是 over design,得要付出一定的成本,只是在我們團隊,這樣的代價所帶來可降低的維護成本跟風險相當划算。

曾經在團隊中建立的規範

  1. 3 layer (presentation layer/UI layer, business logic layer/service layer, data access layer/persistence layer) 職責的強制性
  2. layer 之間一定用 interface 隔開
  3. 不允許在 context 中直接初始化(new instance)物件,除非被初始化的該物件是 DTO(data transfer object), 也就是拿來當參數傳遞的 value object
  4. 循環複雜度規定,高標低於10, 低標低於15。(工廠職責不受限於規定)
  5. 物件相依於 interface, 採依賴注入設計(不一定會使用 DI framework, 但一定有 DI 的設計)
  6. 繼承深度 < 3 (從自訂物件開始算)
  7. 程式碼相似度行數限制,高標 < 15 行,低標 < 25 行,但這一條通常是檢查用,而不是規範用。也就是檢查 duplicate 的程式碼是否合理。
  8. function 程式碼行數應低於 30 行或高度小於螢幕的一頁
標準只是拿來當健康檢查指標用,不代表不可撼動、調整的規定。但特例一定得說得出為什麼,以便大家瞭解、認同並回饋回去標準制訂是否需要調整。

工具

  1. StyleCop
  2. SourceMonitor
  3. Simian
  4. FxCop
  5. Visual Studio 程式碼品質分析
  6. Code Maid
  7. 建立 Code Snippet (Visual Studio Extension - Snippet Designer 簡介)
  8. T4 code generator

常用自動測試導入優先序

  1. 先針對 business layer 做 isolated unit test (含 controller isolated unit tests)
  2. 針對 data access layer 做 integration test
  3. 針對 business layer 做 integration test
  4. 針對 controller 做 integration test (含 Web API site)
  5. 針對 UI 做 end-to-end web testing

對敏捷開發有興趣的朋友,可以參考我的粉絲專頁:91敏捷開發之路

對 TDD 課程有興趣的朋友,課程內容、大綱與學員心得,可以參考 skilltree 的公開課程:自動測試與 TDD 實務開發

若需要聯絡我,可以透過粉絲專頁私訊或是側欄的關於我。