Dan Bergh Johnsson
三位程式設計師的故事#
作者拍了三位程式設計師的肩膀，問他們在做什麼：
- 第一位回答：「我正在重構這些方法。」
- 第二位回答：「我正在為這個 web action 增加一些參數。」
- 第三位回答：「我正在做這個 user story。」
表面上看，第三位似乎有更好的全局觀，而前兩位只專注於細節。然而，當作者問他們什麼時候會 commit、會 commit 什麼時，情況完全逆轉。
- 前兩位很清楚會涉及哪些檔案，大約一個小時左右就能完成
- 第三位則回答：「嗯，我猜幾天內會好。大概會新增幾個類別，可能會改改那些 service。」
以 Commit 為導向的工作方式#
前兩位並非缺乏對整體目標的視野。他們選擇了朝向有成效方向的任務，且能在幾個小時內完成。一旦完成，他們會再選擇一個新的功能或重構來進行。所有寫出的程式碼都帶有明確的目的和有限的、可達成的目標。
第三位則無法將問題分解，同時處理所有面向。他基本上在做投機式程式設計（speculative programming）——希望在某個時刻能到達可以 commit 的狀態。很可能最初寫的程式碼與最終的方案並不匹配。
超過預期時間怎麼辦？#
如果前兩位的任務超過兩個小時會怎樣？他們很可能會：
- 丟掉修改
- 定義更小的任務
- 重新開始
繼續硬撐會讓人失去焦點，導致投機性的程式碼進入儲存庫。修改雖然被丟掉了，但洞見會被保留下來。
第三位程式設計師則可能繼續猜測，拼湊出勉強可以 commit 的東西。畢竟，你不能丟掉已經寫好的程式碼吧？不幸的是，不丟掉這些缺乏明確目的的程式碼，會導致稍顯怪異的程式碼進入儲存庫。
投機式探索的價值#
有時候，即使是以 commit 為導向的程式設計師，也可能在兩個小時內找不到有用的成果。這時他們會直接進入投機模式，嘗試和探索程式碼，當獲得洞見時就丟掉修改，回到正軌。即使是看似無結構的探索也有其目的：學習足夠的知識來定義一個能構成有成效步驟的任務。
了解你的下一次 commit。 如果無法完成，就丟掉修改，帶著已獲得的洞見重新定義一個新任務。適時做投機式探索，但不要讓自己在不知不覺中滑入投機模式。不要把猜測性的程式碼 commit 到儲存庫。