🎯 什麼情境該想到我
當你想讓團隊運作得更順——資訊流通、知識不集中在少數人身上、進度與問題及早被看見——的時候。
章導言引威爾遜總統：「我不仅发挥了自己的全部能力，还将我所仰仗的人的能力发挥到极致。」書的論點是：「高效的协作是敏捷开发的基石。」
| 習慣 | 良策 |
|---|---|
| 定期安排會面時間 | 使用站立會議，保持簡短、不離題 |
| 架構師必須寫代碼 | 不要用不願意寫程式的架構師 |
| 實行代碼集體所有制 | 讓開發人員輪流處理系統的不同部分 |
| 成為指導者 | 分享知識，付出的同時也有收穫 |
| 允許大家自己想辦法 | 指出方向，而不是直接給答案 |
| 準備好後再共享代碼 | 絕不要提交尚未完成的程式碼 |
| 做代碼複查 | 審查所有的程式碼 |
| 及時通報進展與問題 | 不要等著別人來問專案的狀態 |
書的第 9 章（尾聲）給了一個很實用的導入順序：搶救一個瀕臨失敗的專案時，不能所有習慣一次上馬（「胸痛的病人不能叫他馬上上跑步機」）。Venkat 的做法是：
- 先用溝通協作類的習慣穩定團隊：對事不對人、站立會議、準備好再共享程式碼、及時通報進展；
- 再引入發布相關的：保持可以發布、頻繁整合；
- 最後是編碼相關的：警告就是錯誤、各個擊破。
那個專案當時已經用掉一半時程、還有 90% 的成果要交付，最後比預定早兩週完成。書中另一個例子：一個團隊版本總是延期、bug 失控，訪談後發現，有人以為是「瘦客戶端」、有人以為是「胖客戶端」——團隊從來沒有坐下來一起討論過。只引入站立會議這一個習慣，就解決了架構上的分歧。
出處：Subramaniam & Hunt《高效程式設計師的 45 個習慣》第 8 章與第 9 章。引文保留原書簡體字。
⚙️ 怎麼用（逐項）
定期安排會面時間
Schedule Regular Face Time 什麼時候會冒出來：團隊各做各的資訊完全不同步／想開個每日短會同步障礙／遠端工作久了失去團隊連結／大家不知道彼此手上在忙什麼
魔鬼的誘惑：「会议安排得越多越好。实际上，我们要安排更多的会议，直到发现为什么工作总是完不成。」
良策：「使用立会。立会可以让团队达成共识。保证会议短小精悍不跑题。」
書中重點：
- 站著開，才會開得快。作者曾用電話參加某客戶的站立會議，某天會議時間多了一倍——原來客戶那邊把會議挪到會議室、坐在扶手椅上開。
- 每人只回答三個問題：
- 昨天有什麼收穫？
- 今天計畫做什麼？
- 遇到了哪些障礙？
- 每人大約兩分鐘，可以用計時器。要細談的話，會後再找相關的人（可以說「我需要和 Fred 討論一下資料庫」，但不在會中深入）。
- 時間：不要排在上班的第一件事，讓大家有時間從通勤中恢復；一般在大家到公司後半小時到一小時內。
- 側欄〈豬與雞〉：Scrum 把團隊成員叫做「豬」、非團隊成員叫做「雞」（出自一則寓言：雞和豬合開一家供應培根和雞蛋的餐館——雞只是參與，豬是全心投入）。只有團隊成員可以在站立會議中發言；管理者可以記下問題，但不能把會議帶開。
切身感受：「大家都盼望着立会……而且不怕把各自遇到的问题拿出来公开讨论。」
平衡的藝術：
- 站立會議最長不超過 30 分鐘，10～15 分鐘比較理想。
- 小型團隊每天開可能太多，兩天一次或一週兩次就夠了。
- 報告要具體：「我在開發登入頁面」不夠；「登入頁面目前接受 guest/guest 登入，我明天會接上資料庫做驗證」才有用。
- 準時開始，會議才會短。
- 如果覺得站立會議浪費時間，可能是大家還沒有形成真正的團隊意識——這反而是可以改進的地方。
在今天的樣子：遠端團隊常改成非同步的每日更新（在頻道中寫三個問題的答案），同步會議只處理「障礙」。重點不是形式，而是讓障礙被及早看見。
架構師必須寫代碼
Architects Must Write Code 什麼時候會冒出來：畫完架構圖就不碰程式了／設計出來的東西實作起來根本不合用／做決策的人離現場太遠／想讓設計跟真實開發接軌
魔鬼的誘惑：「我们的专家级架构师Fred会提供设计好的架构……不要用一些愚蠢的问题或者实现上的难点来浪费他的时间。」
良策：「优秀的设计从积极的程序员那里开始演化。积极的编程可以带来深入的理解。不要使用不愿意编程的架构师——不知道系统的真实情况，是无法展开设计的。」（旁註：你不能在 PowerPoint 裡寫程式）
書中重點：
- 「PowerPoint 架構師」：專案開始時畫漂亮的圖、說一堆術語，在重要的實作之前就離開——得不到任何回饋。
- 戰略決策可以在後方做，戰術決策需要清楚了解戰場。書中舉一戰的索姆河戰役：通訊中斷、戰場與預測完全不同，指揮官仍堅持原計畫。
- 引 Knuth：「新系统的设计者必须要亲自投入到实现中去。」泰米爾諺語：「只有一张蔬菜图无法做出好的咖喱菜。」
- 引 Martin Fowler：真正的架構師「应该指导开发团队，提升他们的水平，以解决更为复杂的问题」，而且「架构师最重要的任务是：通过找到移除软件设计不可逆性的方式，从而去除所谓架构的概念」。
- 「程序员在拒绝设计的同时，也就放弃了思考。」
切身感受：「架构、设计、编码和测试……感觉它们彼此之间应该是不可分割的。」
平衡的藝術：
- 首席架構師可能沒有足夠的時間寫程式，仍然要讓他參與，但不要讓他負責關鍵路徑上工作量最大的程式碼。
- 不要允許任何人單獨進行設計，特別是你自己。
在今天的樣子：「架構師不寫程式」的另一種形式是設計文件與實作脫節。對策是讓設計者參與實作與 code review，並把設計的關鍵決策寫成可以在實作中被推翻的文件（見 讓設計指導而不是操縱開發）。
實行代碼集體所有制
Collective Code Ownership 什麼時候會冒出來：某個模組只有一個人敢碰／那個人請假整個功能就動不了／想打破團隊裡的知識孤島／不敢去改別人負責的檔案
魔鬼的誘惑：「不用担心那个烦人的bug，Joe下周假期结束回来后会把它解决掉的。在此之前先想个权宜之计应付一下吧。」
良策：「要强调代码的集体所有制。让开发人员轮换完成系统不同领域中不同模块的不同任务。」
書中重點：
- 不應該像國家宣示領土一樣宣示對程式碼的所有權。只有一個人能處理的程式碼，增加了專案的風險。
- 多人參與時，程式碼會被頻繁地檢查、重構、維護；任何人都能修 bug，排程也更容易。
- 輪換任務能提升團隊的整體知識：接手別人的程式碼時，可以重構、提出有用的問題、及早深入理解問題領域。
- 知道別人會接手自己的程式碼，自己也會更守規矩。
切身感受：「项目中绝大部分的代码都可以轻松应对。」
平衡的藝術：
- 不要不小心失去團隊的專家技能——特別精通某個領域的人可以當「駐點專家」，同時系統的其他部分也對他開放。
- 集體所有制不等於隨心所欲、到處修改。
- 有些情況不適合，例如需要特殊知識的高難度即時控制系統，人多反而誤事。
- 任何人都可能遇到意外或被挖角——不分享知識，反而增加失去知識的風險。
在今天的樣子：
- 「只有一個人懂」有時被稱為巴士因子（bus factor）=1。
CODEOWNERS檔案常被誤用成「領土宣示」；比較好的用法是指定必須通知的審查者，而不是唯一能改的人。- 見 欲速則不達：沒有人敢碰的模組，會累積成「+1/-1 修正」的沼澤。
成為指導者
Be a Mentor 什麼時候會冒出來：會了東西卻不太想教別人／擔心教會徒弟會餓死師傅／想透過教別人把自己理解得更深／被指派要帶新人卻沒有方向
魔鬼的誘惑：「对别人要有所保留，这样让你看起来更有水平。让队友对你超群的技能感到恐惧吧。」
良策：「成为指导者。分享自己的知识很有趣——付出的同时便有收获。」（旁註：教學相長）
書中重點：
- 引傑佛遜：「如果你用你的蜡烛点燃了我的，我在得到光明的同时，也没有让你的周围变暗。」給錢會變少，教別人，雙方的知識都會增加。
- 詳細解釋能加深自己的理解；別人的提問能讓你發現新的角度。
- 遇到答不出的問題，代表這個領域你需要加強。好的指導者會做筆記，之後加進問題解決日誌。
- 成為指導者不是手把手地教（見下一個習慣），也不是站在白板前講課；可以在午餐會議中討論，也可以寫部落格。
- 「我们要成为指导别人的人，而不是折磨别人的人。」
切身感受：「给予别人教导，也是提升自己学识的一种方式，并且其他人亦开始相信你可以帮助他们。」
平衡的藝術：
- 同一個主題向不同的人反覆解釋，不妨寫成文章。
- 結對程式設計是有效指導的自然環境。
- 為求助設定時限：隊友卡住多久之後應該來問？書中建議一小時是不錯的選擇。
在今天的樣子：「卡住一小時就求助」是一個值得寫進團隊規範的具體數字——太早問會打斷別人、自己也學不到；太晚問會浪費一整天。
允許大家自己想辦法
Let People Figure It Out 什麼時候會冒出來：忍不住想直接把答案講出來／隊友一問我就整套做給他看／想讓成員練習自己找出解法／帶人時不知道該放手到什麼程度
魔鬼的誘惑：「你这么聪明，直接把干净利落的解决方案告诉团队其他人就好了。不用浪费时间告诉他们为什么这样做。」
良策：「给别人解决问题的机会。指给他们正确的方向，而不是直接提供解决方案。」
書中重點：
- 「授人以鱼，三餐之需；授人以渔，终生之用。」
- 不要直接給出答案，而是問：「你有沒有看過交易管理器和應用程式的鎖處理之間的互動？」
- 好處：他們學會解決問題；學到答案以外的東西；不會為類似的問題反覆來問你；你答不出來時他們能自己想辦法；他們可能想出你沒想到的解法——你也學到新東西。
- 有人提出想法，就幫忙分析優劣；別人的答案比較好，就接受並分享。引亞里斯多德：「接纳别人的想法，而不是盲目接受，这是受过教育的头脑的标志。」
切身感受：「不是有意掩饰，更非讳莫如深，而是带领大家找到自己的解决方案。」
平衡的藝術：
- 用問題回答問題，可以引導提問者走上正確的方向。
- 如果有人真的卡住了，就別折磨他們了——告訴答案，再解釋為什麼。
在今天的樣子：卡內基的 讓對方以為是他的主意 是同樣的原理：自己找到的答案，理解得更深、也更願意維護。
準備好後再共享代碼
Share Code Only When Ready 什麼時候會冒出來：把不能編譯的東西推上去了／隊友被我的提交卡住不能工作／不確定現在該不該提交／想確認測試都過了再推上去
魔鬼的誘惑：「别管是不是达到代码签入的要求，要尽可能频繁地提交代码，特别是在要下班的时候。」
良策：「准备好后再共享代码。绝不要提交尚未完成的代码。故意签入编译未通过或是没有通过单元测试的代码，对项目来说，应被视作玩忽职守的犯罪行为。」
書中重點：
- 謎語：比不用版本控制更糟的是什麼？錯誤地使用版本控制。
- 兩個方向的錯誤：
- 太久才提交（每週、每月）：完成任務就應該馬上提交。書中提到「環境黏滯性」——把事情做糟比做好更容易（例如遠端存取版本控制很慢），這是必須解決的技術問題。
- 還沒完成就提交（例如為了回家繼續寫）：把編譯錯誤或不相容的變更帶給其他人。
- 一次提交只包含同一個任務相關的檔案，並附上說明改了什麼、為什麼改。這樣的原子提交也方便回滾。
- 提交前所有單元測試都要通過。
切身感受：「感觉好像整个团队就在源代码控制系统的另一端盯着你。」
平衡的藝術：
- 有人希望提交前先審查——只要不拖延太久就沒問題；如果流程造成拖延，就修正流程。
- 仍然應該頻繁提交，不能拿「程式碼還沒完成」當藉口。
在今天的樣子：
- Git 讓「提交」與「共享」分開了：本地可以隨時 commit，推送到主幹之前才需要保證測試通過。書中的「臨時提交」需求，今天用本地分支或推送到個人的遠端分支就能解決。
- 「原子提交」的原則仍然成立：不要在同一個 commit 混合重構與行為改變（見 工具-小步重構）。
做代碼複查
Review Code 什麼時候會冒出來：程式沒有第二個人看過就上線／想靠複查提早抓出缺陷／團隊風格各寫各的很不一致／知識只留在寫的人腦袋裡
魔鬼的誘惑：「用户是最好的测试人员。别担心——如果哪里出错了，他们会告诉我们的。」
良策：「复查所有的代码。对于提升代码质量和降低错误率来说，代码复查是无价之宝……要让不同的开发人员在每个任务完成后复查代码。」
書中重點：
- 書中引用 Capers Jones 的說法：「正式地进行代码检查，其效果是任何已知形式测试的两倍，而且是移除80%缺陷的唯一已知方法。」
- Venkat 參與過一個時程緊湊、許多成員經驗不足的專案，透過嚴格的審查（每個人完成編碼與測試後、提交前，由另一位開發者徹底審查），交付了品質很高且穩定的程式碼。每個人的程式碼都要審查，不論資深與否。
- 三種方式：
- 通宵審查：每月一次的「恐怖審查之夜」——大團隊容易陷入無止境的討論，不建議。
- 撿拾式審查：程式碼完成、準備提交時，由其他人「撿起來」審查，並輪換審查者。
- 結對程式設計：一人寫、一人看，不時互換——等於持續的審查。
- 基本檢查清單：讀得懂嗎？有明顯的錯誤嗎？會對其他部分產生不良影響嗎？有重複的程式碼嗎？有可以改進或重構的地方嗎？
切身感受：「感觉复查活动就像是项目正在进行的一部分，而不是一种令人畏惧的事情。」
平衡的藝術：
- 橡皮圖章式的審查沒有任何價值。
- 審查要評估設計與清晰度，而不只是檢查變數名稱和格式。
- 同樣的功能不同人寫法不同，差異不代表不好——除非能讓程式碼明確變好，否則不要隨意批評。
- 審查中的建議如果沒有後續追蹤，就沒有價值。
在今天的樣子：今天的 PR 流程就是「撿拾式審查」。格式與命名交給工具，人的注意力留給設計與正確性。審查意見的措辭見 對事不對人 與 用提問代替命令。
及時通報進展與問題
Keep Others Informed 什麼時候會冒出來：出狀況了悶著不敢跟人講／主管一直來問現在做到哪／風險拖到爆炸了才被發現／想主動同步進度跟卡點
魔鬼的誘惑：「如果他们想知道进展状况，会主动找你要的。还是埋头继续做事吧。」
良策：「及时通报进展与问题。发布进展状况、新的想法和目前正在关注的主题。不要等着别人来问项目状态如何。」
書中重點：
- 等到截止日才在演示會上說「還沒完成」，除了尷尬，也傷害職業生涯。
- 等到最後才報壞消息，等於邀請主管對你微觀管理——他們會每天檢查好幾次，「你的生活就开始变得像呆伯特的漫画一样了」。
- 任務做到一半發現可能無法準時完成，主動通知相關的人，他們就能提前想辦法：找其他人幫忙、重新分配給更熟悉的人、增加資源、或調整範圍；客戶也可能願意拿另一個同樣重要的任務來交換。
- 資訊輻射器（Alistair Cockburn 提出）：像牆上的海報一樣，以「推送」的方式傳遞資訊，路過的人一看就懂，不必再來問。
切身感受：「当经理或同事来询问工作进展、最新的设计，或研究状况时，不会感到头痛。」
平衡的藝術：
- 每日站立會議讓每個人了解最新進展。
- 展示進度要照顧受眾關心的細節程度——CEO 不會關心抽象基底類別的設計。
- 不要花太多時間在通報上。
- 經常抬頭看看四周，而不是只埋頭在自己的工作裡。
在今天的樣子：
- 資訊輻射器的現代版：團隊的看板、公開的儀表板、部署與事故的頻道。
- 「及早報壞消息」需要組織的配合——蒙格的 波斯信使症候群 解釋了為什麼人們不願意報壞消息，以及主管該怎麼做。
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
- 協作習慣要先於技術習慣：書中第 9 章的搶救順序說明了這一點——團隊溝通不順，技術實踐很難推得動。
- 以身作則比行政命令有效：書中給程式設計師的建議是從自己的單元測試開始，幾週內見效——下午 5 點準時下班、不會半夜被叫起來修 bug，別人自然會想學。「你可以把马带到水边……但是你不能强迫它使用你最钟爱的代码编辑器。」
🔗 相關工具
- 工具-心理安全感 —— 這些協作習慣能運作的前提
- 工具-對事不對人的協作 —— 從本書萃取的即用工具卡
- 高效程式設計師的45個習慣 —— 書卡