程式碼整潔之道
簡介：
本書是程式設計大師“Bob 大叔”40餘年程式設計生涯的心得體會的總結，講解要成為真正專業的程式設計師需要具備什麼樣的態度，需要遵循什麼樣的原則，需要採取什麼樣的行動。作者以自己以及身邊的同事走過的彎路、犯過的錯誤為例，意在為後來者引路，助其職業生涯邁上更高臺階。
本書適合所有程式設計師閱讀，也可供所有想成為具備職業素養的職場人士參考。
第十章 預估
預估是軟體開發人員面對的最簡單、也是最可怕的活動之一了。預估影響到的商業價值巨大，關乎聲譽，也給我們帶來了很多的苦惱和挫折。預估是業務人員和開發人員之間最主要的障礙，橫亙在雙方之間的種種不信任，幾乎都由它引發。
10.1 什麼是預估
不同的人對預估有不同的看法。業務方覺得預估就是承諾。開發方認為預估就是猜測。兩者相差迥異。
承諾：
既然承諾了，就必須兌現。承諾是必須做到的。如果你承諾在某天做成某事，就必須按時完成。即便它意味著你必須每天工作12小時，放棄週末的休假，也不得不如此。
承諾是關於確定性的。其他人會把你的承諾當真，據此擬定計劃。如果不能兌現承諾，他們的損失，以及你的聲譽受到的影響，都是巨大的。不能兌現的承諾也是一種欺騙，只不過比明目張膽的欺騙好一點。
10.2 預估：
預估是一種猜測。它不包含任何承諾的色彩。它不需要做任何約定。
預估不是個定數，預估的結果是一種機率分佈。
專業開發人員能夠清楚區分預估和承諾。只有在確切知道可以完成的前提下，他們才會給出承諾。此外，他們也會小心避免給出暗示性的承諾。他們會盡可能清楚地說明預估的機率分佈，這樣主管就可以做出合適的計劃。
PERT:
PERT的一部分內容就是對預估的計算方法。這種技術包含了一個非常簡單而有效的辦法，把預估變成機率分佈，讓主管們看懂。
透過對專案開發進度的三種不同角度預估，即樂觀預估、標稱預估、悲觀預估。 然後求其期望值。
10.3 預估任務：
在預估時，最重要的資源是你周圍的人。他們可以看到你看不到的東西。相比自己單幹，他們可以幫你更精確地預估任務。
德菲爾法：
辦法非常簡單。一組人集合起來，討論某項任務，預估完成時間，然後重複“討論－預估”的過程，直到意見統一。
具體操作：
-
亮手指
大家圍坐在桌旁。每次討論一項任務。針對每項任務，都必須討論這個任務涉及什麼，什麼因素會把它搞複雜，它應該如何實現。然後所有參與者把手埋到桌底下，根據自己的判斷，伸出0～5個手指。這時候，主持人數1－2－3，所有人都把手亮出來。如果大家伸出的手指數相同，就開始討論下一個任務。否則，就開始討論為什麼有分歧。如此重複，直到意見統一。
-
規劃撲克
規劃撲克的玩法非常簡單。向參與預估的每位成員發出不同點數的牌。如果發給每個人的牌的張數在0到5之間，那麼從邏輯上說，這就是亮手指遊戲。挑一個任務進行討論。到某個時候，主持人要求每個人出一張牌。團隊成員根據自己的預估選出一張牌，背面朝外，保證其他人都看不到牌的點數。然後主持人讓每個人亮牌。剩下的就和亮手指一樣。如果達成共識，就表示認可了預估。否則把牌收回去，繼續討論這項任務。
-
關聯預估
在關聯預估中，所有任務都寫在卡片上，卡片上沒有任何關於預估的資訊。讓參與預估的人圍成一圈站在桌子邊或是牆邊，把卡片打亂鋪開。大家保持靜默，只是卡片按照任務所需時間的長短排序，需要時間長的放右邊，短的放左邊。任何時候，任何人，都可以移動任何卡片，不需要關心之前是否有人移動過。如果哪張卡片移動過超過η次，就需要抽出來單獨討論。最終，靜默的排序終止。大家開始討論，詳細瞭解排序意見的分歧所在，也可以透過簡短的設計討論或者手繪的線框草圖來幫助取得共識。
-
三元預估
如果為單個任務做標稱預估，德爾菲法是不錯的辦法。但是之前說過，大多數情況下需要做3種預估，才能得出機率分佈。不論使用德爾菲法的哪種形式，都可以迅速得到每個任務的樂觀預估值和悲觀預估值。舉例來說，如果選擇使用規劃撲克，可以要求大家根據悲觀預估亮出紙牌，然後選擇點數最大的那張。樂觀估計也是如此，只不過是選出點數最小的那張。
10.4大數定理
預估是非常容易出錯的，所以才叫預估。控制錯誤的辦法之一是使用大數定律。該定律的意思是：把大任務分成許多小任務，分開預估再加總，結果會比單獨評估大任務要準確很多。這樣做之所以能提高準確度，是因為小任務的預估錯誤幾乎可以忽略，不會對總的結果產生明顯影響。
坦率地說，這也是比較樂觀的想法。預估中的錯誤通常會被低估而不是高估，所以拆分再加總很難做到完美。不過，把大任務拆分成小任務分開預估，仍然是個好辦法。有些錯誤會被忽略，而且拆分成小任務也更利於理解任務本身及其他意外因素。
10.5 結論
- 專業開發人員懂得如何為業務人員提供可信的預估結果，以便做出計劃。如果做不到，或者不確定能做到，專業開發人員不會給出承諾。
- 專業開發人員一旦做了承諾，就會提供確定的數字，按時兌現。但是大多數情況下，他們都不會做這種承諾，而是提供機率預估，來描述期望的完成時間及可能的變數。
- 對需要妥善對待的預估結果，專業開發人員會與團隊的其他人協商，以取得共識。