團隊邊界（Team Boundaries）#

架構師與開發團隊之間的互動方式，會深刻影響架構的實現品質。架構師必須在控制（control）與放手（letting go）之間找到平衡——這個平衡點取決於團隊的特性和專案的情況。

架構師對開發團隊產生的影響力，體現在他們設定的邊界（boundaries）上：太緊的邊界會扼殺團隊創造力，太鬆的邊界則可能導致架構失控。

架構師性格類型（Architect Personalities）#

作者將架構師的行為模式歸類為三種性格類型，每種會產生不同的團隊邊界：

Control Freak（控制狂）#

• 對開發團隊的每個技術決策都試圖嚴格控制
• 設定非常窄的邊界，幾乎不留給開發者自主空間
• 團隊成員感到窒息，士氣低落，優秀的人才傾向離開
• 雖然短期內可能確保決策一致性，但長期來看會阻礙團隊成長

Armchair Architect（紙上談兵型架構師）#

• 制定架構決策後不參與實作，對團隊的實際困難漠不關心
• 設定的邊界過於寬鬆或不切實際
• 這類架構師往往與開發現實脫節，做出的架構決策可能無法落地
• 團隊對架構師失去信任，最終忽略架構指導

Effective Architect（有效的架構師）#

• 根據情境動態調整控制程度，在指導與信任之間取得平衡
• 與團隊保持密切合作，了解實作中的挑戰
• 設定適當的邊界——足以維護架構完整性，又給予團隊合理的自主空間
• 讓團隊感覺是被支持而非被控制

有效的架構師不是一味放權，也不是事事插手，而是能根據團隊和專案的情境，動態調整控制程度。

控制程度的決定因素（How Much Control?）#

架構師應根據以下五個因素來決定對團隊施加多少控制：

Team Familiarity（團隊熟悉度）#

• 團隊成員之間是否合作過？彼此了解嗎？
• 新組建的團隊需要更多架構師的指導和控制
• 磨合良好的團隊可以給予更多自主空間

Team Size（團隊規模）#

• 較大的團隊通常需要更多控制，確保一致性
• 較小的團隊溝通成本低，可以給予更多彈性

Overall Experience（整體經驗）#

• 團隊的資深程度直接影響需要多少架構指導
• 經驗豐富的團隊通常自主能力更強
• 初級團隊需要更具體的架構指導和更多的 code review

Project Complexity（專案複雜度）#

• 高複雜度的專案需要更嚴格的架構控制
• 簡單的專案可以給予更多自由度
• 複雜的整合需求、高度耦合的元件都需要更多架構師的介入

Project Duration（專案持續時間）#

• 長期專案初期需要更多控制，隨著團隊成熟可以逐漸放鬆
• 短期專案由於沒有時間修正方向，可能需要從一開始就維持適度控制

這五個因素應該綜合評估，而非單獨看待。例如：一個經驗豐富但剛組建的團隊，可能需要中等程度的控制——利用成員的經驗，同時幫助團隊建立共識。

團隊警示信號（Team Warning Signs）#

以下跡象表明團隊可能過大或出現問題：

• Process loss（流程損失） — 隨著團隊規模增長，用於協調溝通的時間比例增加，真正產出的時間減少
• Pluralistic ignorance（多元無知） — 團隊成員私下不同意某個決定，但以為自己是唯一持異議者，因此保持沉默
• Diffusion of responsibility（責任分散） — 團隊越大，個人責任感越弱，「別人會處理」的心態蔓延

當發現這些警示信號時，架構師應考慮拆分團隊或調整團隊結構，而不是單純增加流程和會議。

善用檢查清單（Leveraging Checklists）#

受到 Atul Gawande 著作 The Checklist Manifesto 的啟發，作者建議架構師為開發團隊建立適當的檢查清單（checklists），降低遺漏的風險。適合建立檢查清單的領域包括：

• Code completion checklist — 程式碼完成前須確認的項目（如單元測試覆蓋率、logging、exception handling）
• Unit and functional testing checklist — 確保測試的完整性
• Software release checklist — 發布流程中的關鍵檢查點

檢查清單的價值不在於限制開發者，而在於確保重要但容易被忽略的步驟不會被遺漏。尤其在壓力大或時間緊迫的情況下，檢查清單能有效防止人為疏失。

提供指導（Providing Guidance）#

Code Reviews（程式碼審查）#

• 架構師應參與 code review，確保架構決策和設計原則被遵循
• 不需要審查每一行程式碼，而是聚焦在架構相關的面向
• Code review 也是指導團隊、傳遞架構知識的好機會

Pair Programming（結對程式設計）#

• 架構師與開發者進行 pair programming 是最直接的指導方式
• 讓架構師了解團隊面臨的實際挑戰
• 幫助架構師保持技術敏銳度，避免成為 armchair architect

無論使用哪種指導方式，關鍵是架構師要持續參與團隊的日常工作，而不是只在設計階段出現。

Conway’s Law 及其影響#

Conway’s Law 定義#

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

— Melvin Conway, 1968

組織的溝通結構會不可避免地影響其產出的系統架構。例如：

• 如果有四個團隊負責開發一個 compiler，最終很可能會得到一個 four-pass compiler
• 如果前端和後端由不同團隊開發，系統自然會形成前後端分離的架構

實務影響#

• 架構師在設計架構時，必須考慮組織結構的影響
• 有時候改變架構需要先改變組織結構
• 如果組織結構與期望的架構不匹配，組織結構通常會「贏」

架構與團隊拓樸（Architecture and Team Topology）#

根據 Conway’s Law 的啟示，架構師應該認識到架構和團隊結構是相互關聯的。

• Inverse Conway Maneuver（逆向 Conway 操作） — 刻意設計組織結構以促進期望的架構。如果你想要 microservices 架構，就把團隊按照服務邊界來組織
• 團隊的物理位置、溝通模式和組織層級都會影響最終的架構結構
• 架構師不能只關注技術架構，還必須關注團隊拓樸如何與架構互相支持

架構和團隊結構是一體兩面。試圖在不匹配的組織結構上強推某種架構風格，通常會以失敗告終。聰明的架構師會同時考慮技術架構和團隊拓樸。