囫圇吞棗-《軟件隨想錄》-分解時間、追蹤時間，預見未來，將任務切細再切細

我從另一本勵志書看到了個小故事：有人訪問了連續好多屆都得到馬拉松冠軍的選手，問他成功的撇步是什麼？他說：「我原先也跟大家一樣，覺得終點線就在漫漫長路的彼端，常常跑不到中途就覺得沒希望了；後來我習慣在正式比賽前一天，沿路繞過一遍，將長程的路途切分成很多小目標，沿路做記號；我所要努力的就是沿途逐步達到這些小目標，等到這些小目標一段段都完成了，那麼終點線就在眼前了。」

我還是覺得，寫 code 即生活；寫 code 就是砥礪心志。

摘錄、改寫：

如果每個日程規劃是以天為單位，我就認定那是沒用的；你必須將日程規劃先分解成一個個非常小的任務，以小時為區段，確認這些單一任務不能超過 16 小時；實際上，就是要強迫你自己把程式命名這種細微的片段都要想過；你沒想過你要做哪些功夫才能完成程式，你的程式要完成就可能遙遙無期。

詳細填寫工作時間記錄表 (TimeSheet)，久而久之，將有助你把自己完成目標的預估時間愈估愈準；多數估計的時間總是會失準，因為估算時常常沒有考慮到修正錯誤、小組開會、喝咖啡的時間等，更何況有些 PM 會三不五時來問你工作進度，也打斷你的工作時間。

你可別以為只要把每項任務預估的時間都加總起來就是程式做完的時間，系統要調參數，工作就要調時數；多做幾個專案，你就會知道自己預估好後，還要加上多少時間才是真正做完的時間。

別管老闆多會打擾你，工作時間表訂出來，按照原先訂立的工作時數去做 (看到這裡你的老闆應該會翻臉)，不過相信我，這會讓你實際完成任務以及日程規劃達到最佳效果

那些建議：

只有第一線的程式員才能提出完成日期的估算值

一發現錯誤就立即修正，並將花費的時間也計算進去

防止管理層向程式員施加壓力，或要求他們加快開發速度

水杯裝滿了，就無法再倒水進去了；不是先把水倒出來，再加水進去，就是維持原樣

所堅持要做完的功能不一定是對的；尤其是當你在開發下一版時，應該就會發現。不過誰知道呢？就在東刪西減中，把成果以完整為優先要務吧。