## 舉例 我們做一個簡單的修改用戶信息功能的API。那么我們在某一個Java技術棧上可能的任務列表是長這樣的： 1. 寫UserController （10分鐘） 2. 寫UserDAO （15分鐘） 當你真正開始做的時候，會碰到兩種主要的意外： 1. 任務列表擴張 2. 時間估計不準 下面就這個例子，就講一講當我們遇到這兩種意外，該怎么反思和處理。 ### 任務列表擴張 任務列表擴張，顧名思義，就是指我們所估計的任務數量會隨著我們開始工作變的比預想的多，可能有兩種主要原因： 1. 技術原因 2. 業務原因 技術原因： 比如在這個案例里面，第二項任務是“寫UserDAO”，就是一個沒想清楚的事情。我們還需要建數據庫表，我們在一個有migration腳本支持的技術棧設計上工作，我們還需要寫初始化腳本和回滾腳本。也許這是我的第一個表，所以我還得配置數據庫，搞不好還要把ORM的基礎代碼都寫完，所以這些導致了我可能任務估少了。 再比如，項目規范要求我們Controller不能直接調DAO，要在中間加一個Service，盡管我個人覺得這是一件很二的規范，然而規范就是規范，我對項目技術規范不熟悉，導致我的計劃缺少了一些必要的任務。再比如，我們的項目采用了Jersey，根本沒有Controller這么一個東西，那么不了解技術框架導致我的任務表從根本上就列錯了。 這種情況屬于我對技術了解不足，通過對任務列表擴張的原因進行Check，我會得出一些Action：去了解技術規范、項目的技術架構、現有的代碼，以防止以后的任務畫錯。 業務原因： 也比如在這個例子里，在更新用戶的API里不能更新密碼，所以我們還需要一個專門修改密碼的API。再比如，這是一個遺留系統，用戶信息的修改會觸發數據庫里的一系列觸發器，進而修改系統的其他數據，然而有些修改是有前提的，那么我就需要更多的任務去處理這些前提條件；或者當數據變化時，要求我去修改系統里的其他數據，那么我就需要更多的任務去完成這些工作。 這種情況屬于我對整個系統的業務了解不足，通過對任務列表擴張原因的Check，我會得出一些Action：通讀數據庫表、通讀代碼、更全面的閱讀需求，或者跟需求方更多的溝通，以了解業務。 ### 時間估計不準 時間估計不準就簡單很多，在這個例子里，可能的主要原因也有三個： 1. 任務列表擴張了，但是我沒意識到。比如UserDAO寫起來沒有我想的那么簡單，所以多花了時間； 2. 單純的技術不熟練； 3. 花了太多時間在糾結上； 對于隱藏的任務列表擴張，不準確的時間估計給了我們一個很好的線索去發現。一旦發現了，可以如前文所述去處理，也就不再贅述。  對于單純的技術不熟練，正如前文所述，要設計刻意練習。比如我就曾設計過針對數據庫的增刪改查訓練以提升自己的速度，使我即便使用TDD依然保持一個極高的速度。**我們或許不曾意識到，基礎能力的薄弱對于我們的高級能力的限制有多嚴重，這種體驗也只有基礎能力已經熟練的人去教基礎能力不熟練的人一些高級技能的時候才會發現。**這種視而不見的收益，使得大多數人都會輕視基本功的練習。哪怕已經獲得收益的人，也容易鼓吹要更多的啟發而忽略了基本功的價值。 **對于花了太多時間在糾結上，這其實也是一種不熟練，是對設計知識和能力的不熟練。**之前看的設計知識只能有一個大概的感覺，對于每個知識的邊界、使用之后的發展、如何從一種設計過渡為另一種設計了解不清，從而害怕在那一刻犯錯。實際上真正值得糾結的部分沒有那么多，大多是自己嚇自己，或者引入了過度設計。 **當然也有一種情況是暴露出了架構級的問題，比如我們對于應該提出的原則性規范沒有提出，導致我們每個地方都要現想**，大家可以想象在沒有RESTful之前設計Web API，我們可能真的是每一個API都現想的，有了它之后，我們的糾結時間就變少了。這種情況下，通過本方法，架構師也算是有了相應的數據支持，那么架構師也就有了發現問題的一種工具。