最近uncle bob發表了新的部落格《為什麼估算這麼難？》。
bob大叔首先丟擲乙個問題，如何將著名的葛底斯堡演說的237個單詞以固定字型和固定行寬寫在一張書籤上。如果人工執行這個任務，假設每秒鐘處理乙個單詞來尋找合適的斷句點，估計5分鐘內就可以完成，而且實際花費時間也和估計的差不多。然而，如果要編寫程式來做，要花多久？而且是在知曉演算法、沒有意外情況、沒有絆腳石、無需備份和恢復功能的情況下，編寫程式要花多久時間？
bob大叔提醒說：程式只不過是遵循某個過程的具體指令，而這個過程是已知的。在動手寫程式之前給出3個估算，最佳情況、最差情況和正常情況。根據bob大叔的統計，大部分人需要花上30-45分鐘，也有人用了15分鐘，還有人用90分鐘。這樣，很多人之前的估算與實際花費相差懸殊。其中乙個原因，他們基於手工任務看似簡單來進行估算的。
bob大叔回憶某個下午和kent beck採用測試驅動開發
來結對程式設計寫這個演算法。他們估計這需要10-15分鐘，結果花了30分鐘卻毫無進展。在被迫接受這個體驗後思考，為什麼這演算法這麼難？為什麼把如此簡單和直觀的過程寫下來這麼難？
其實，人類是目標導向的，在分解文字時，人類不會遵循乙個過程，而是不斷評估輸出，然後調整做法直到正確為止，因此會預估5分鐘之內完成。而過程是盲目的，它不管輸出是否正確。如果過程錯了，那輸出結果也會錯。人類不了解過程，不了解過程的難度如何。人類不是電腦，做事的時候不會遵循過程，所以無法比較過程任務和手工任務的複雜性。這就是估算為什麼難，而且經常犯錯的乙個原因：任務看上去簡單，人們基於這個表面現象來估算，之後卻發現寫出過程實際上是多麼複雜。人們估算不准是因為估算了錯誤的東西。
回到分解長字串的例子。每次分解一行，記錄下分解位置和選擇這個位置的原因。將其概括為三個不同的場景：
1.如果單詞長於10個字元，在第10字元處斷詞。
2.如果第11個字元是空格，在第11字元處斷詞。
3.從第10個字元向回查詢，如果找到乙個空格，就在該處斷詞。
這些場景仍然需要被組成乙個過程，但是至少知道這個過程有幾個部分組成，從而使估算更容易。
這個故事的寓意是任務看似容易被人類解決，卻經常被描述為複雜的過程。所以估算時，確保不要被簡單的表面現象所迷惑。深入進去，嘗試列舉出過程所包含的場景數量。
博文顯示估算失真有多容易。人腦不善於回答抽象問題，往往替換實際問題為乙個直覺問題。而直覺在尋找答案時，如同博文所說，以期望結果的產生來考慮問題，不關注未知或可能出錯的東西，而是關注那些能夠理解的東西。
博文引發大量討論。有人認為分解過程為小的片段並無價值，有價值的是知道哪類問題是困難的和為什麼困難。也有人認為多練習有助於提高估算準確度，或者讓有經驗的人而不是新手估算。然而經驗最可以依靠，卻仍然可能出錯，除非專案與之前完全一樣。
除了博文所討論的原因，還有人認為，團隊水平、辦公室政治、企業缺乏變更控制，也都成為導致估算不準確的原因。
更多的人吐槽：在實際中，估算往往發生在沒有明確需求可以參考的時候，更不用說之後不斷變化的需求、未知因素、**基礎中隱藏的陷阱。因此固執地遵循最初的時間表也使得估算看起來是不準確的。而且開發人員面對來自於客戶和經理的壓力時，往往傾向於低估時間表。
各位讀者，你們對於估算有什麼樣的經驗？什麼時候估算得準確，什麼時候又不夠準確呢？
堅持是一件很難的事情
1，覺得堅持是一件很難的事情有幾種情況，第一是預期收益沒有想象之中那麼高，第二是這件事情並不是自己所喜歡的事情，第三是沒有志同道合的朋友，第四只能證明自己本身就是一條懶狗。2，現在覺得自己可能是比較符合第四點 3，對於我這種人來說，乙個比較好的監督其實是要比任何的情況更重要的。4，眼前的是無盡的迷茫...
一件重要的事情
流也寫了。希望你們能動動手。寫個銀行業務系統，以下功能就夠了 程式剛執行，有 1.開戶 2.登入 3.銷戶 三個選擇 登入後有 1.存錢 2.取錢 3.轉賬 三個選擇 沒學資料庫。就用.txt檔案來代替 賬戶密碼儲存在.txt檔案中，選擇登入的時候，scanner實現輸入一行 賬號 再一行 密碼 賬...
一件新的事情 指令碼
pure c 是一件有趣的事情 dlr也是一件有趣的事情，但顯然不夠有趣。我想要乙個更可靠的指令碼系統 強型別，可以編譯期檢查排錯 可以跟蹤執行 很遺憾，沒有發現有合適的開源專案可用 於是，我自己來弄乙個。首先基本設計了位元組碼執行引擎的指令 設計了8條指令，因為想要極致簡潔，並且可以快速實現，這張...