程式碼整潔之道
簡介：
本書是程式設計大師“Bob 大叔”40餘年程式設計生涯的心得體會的總結，講解要成為真正專業的程式設計師需要具備什麼樣的態度，需要遵循什麼樣的原則，需要採取什麼樣的行動。作者以自己以及身邊的同事走過的彎路、犯過的錯誤為例，意在為後來者引路，助其職業生涯邁上更高臺階。
本書適合所有程式設計師閱讀，也可供所有想成為具備職業素養的職場人士參考。
第九章 時間管理
8小時其實非常短暫，只有480分鐘，28800秒。身為專業開發人員，你肯定希望能在這短暫的時間裡儘可能高效地工作，取得儘可能多的成果。有什麼辦法能確保不浪費這寶貴的時間呢？怎樣才能有效地管理時間？
9.1 會議
關於會議，有兩條真理：
（1）會議是必需的；
（2）會議浪費了大量的時間。
專業開發人員同樣清楚會議的高昂成本，他們同樣清楚自己的時間是寶貴的，他們同樣需要時間來寫程式碼，來處理日程表上的事務。所以，如果會議沒有現實且顯著的成效，他們會主動拒絕。
拒絕：
邀請你參加會議的人並不負責管理你的時間，為時間負責的只有你。所以，如果你收到會議邀請，務必確保出席會議可以給自己目前的工作帶來切實且顯著的成效，否則不必參與。
有些會議是關於你已經完成的某些事項的，對目前的工作並沒有現實意義。這時候，就應當權衡自己專案的損失與他人的收益。這話有點兒不中聽，但你理應把自己的專案擺在最重要的位置。
還有些時候，有職權的人（比如其他專案的高階工程師或者主管）命令你必須參加某些會議。這時候應當問問自己，他們的職權是否比自己的工作計劃更重要。同樣，自己團隊的同事和領導也可以幫忙決策。
離席：
這些年來，我學到了一條簡單規則：如果會議讓人厭煩，就離席。
重要的是，你應當明白，繼續待在會議室裡是浪費時間；繼續參加對你沒有太多意義的會議，是不專業的行為。因為你有責任合理分配老闆給你的時間和金錢，所以，選個合適的機會商量如何離席，並非不專業的做法。
如果確實需要開會，確定議程與目標：
- 如果收到會議邀請，務必弄清楚指定的議題是什麼，每個議題花多長時間，要取得什麼成果。如果得不到確切的答案，你可以禮貌拒絕。
- 迭代計劃會議：迭代計劃會議用來選擇在下一輪迭代中實現的開發任務。在會議召開前必須完成兩項任務：評估可選擇任務的開發時間，確定這些任務的業務價值。如果組織得足夠好，驗收/元件測試也應當在會議召開前完成，或者至少要有概略方案。
- 迭代回顧和Demo展示：這類會議在迭代的末尾召開。團隊成員討論本輪迭代中什麼做得對，什麼做得不對。如果組織不當，這類會議可能浪費很多時間，所以不妨在最後一天下班前45分鐘召開。花20分鐘來回顧，花25分鐘來演示。請記住，這類會議只牽涉到最近一兩週的工作，所以沒有太多內容要討論。
- 爭論\反對：*凡是不能在5分鐘內解決的爭論，都不能靠辯論解決。爭論之所以要花這麼多時間，是因為各方都拿不出足夠有力的證據。所以這類爭論依據的不是事實，而是信念。
- 如果觀點無法在短時間（5～30分鐘）裡達成一致，就永遠無法達成一致。唯一的出路是，用資料說話。
- 在爭論中如果你同意對方的結論，就必須拿出行動來。
- 要小心這類會議：它們的目的是發洩情緒，或者讓大家站隊。如果會議上只有一面之詞，就要避免參加。
- 如果爭論必須解決，就應當要求爭論各方在5分鐘時間內向大家擺明問題，然後大家投票。這樣，整個會議花的時間不會超過15分鐘。
9.2 注意力點數：
- 程式設計是需要持續投入精力和注意力的智力活動。注意力是稀缺的資源，它類似魔力點數[2]。如果你用光了自己的注意力點數，必須花一個小時或更多的時間做不需要注意力的事情，來補充它。
- 職業開發人員會學習安排時間，妥善使用自己的注意力點數。我們選擇注意力點數充裕的時候程式設計，在注意力點數匱乏時做其他事情。
- 注意力點數也會隨時間流逝而減少。如果不及時使用，它就會消失。會議之所以具有巨大的破壞力，原因之一就在於此。如果你所有的注意力點數都用在了會議上，程式設計時就大腦空空了。
- 憂慮和分心也會消耗注意力點數。昨天晚上的夫妻吵架，今天早上的汽車剮蹭，上週忘記付款的賬單，都會迅速耗光你的注意力點數。
睡眠：專業開發人員會安排好他們的睡眠，保證清晨有飽滿的注意力點數去上班。
咖啡因：毋庸置疑，對有些人來說，適量的咖啡因可以幫他們更有效地使用注意力點數。但是請小心，咖啡因也會給你的注意力添亂。
恢復：一旦注意力點數耗盡，你就沒法控制注意力。你仍然可以寫程式碼，但是多半需要第二天重寫，或者在幾周或幾個月之後備受這段程式碼的煎熬。所以，更好的辦法還是花30到60分鐘來換換腦子。
肌肉注意力：肌肉注意力有助於改善心智注意力，而且不僅僅是簡單的恢復。我發現，定期訓練肌肉注意力，可以提升心智注意力的上限。
9.3 輸入與輸出
關於注意力，我知道的另一重點是平衡輸入與輸出。程式設計是一項創造性勞動。我發現，如果能接觸到其他人的創造性思維，我的創造力也最旺盛，所以我閱讀大量的科幻小說。這些作者的創造力會激發我對軟體的創造力。
時間拆分法和番茄工作法：
把廚房用的計時器（通常它的形狀很像番茄）設定到25分鐘。倒數計時期間不要讓任何事情干擾你的工作。如果電話響了，接起來並禮貌告訴人家，請在25分鐘之後打來；如果有人來打斷你問問題，禮貌地問他是否能過25分鐘再來問。無論什麼干擾，都必須等到25分鐘結束再處理。
畢竟，幾乎沒有事情會緊急到25分鐘都等不了。計時器響的時候，停下手上的工作，轉去處理這25分鐘內遇到的其他事情。之後休息5分鐘左右。然後，再把定時器設定為25分鐘，開始一個新的番茄時間段。每完成4個番茄時間段時間，休息30分鐘左右。
9.4 要避免的行為
有時候你工作時會心不在焉。很可能是因為要做的事情讓人恐慌、難受，或者厭煩。你可能會認為，工作是你被迫面對的，自己無從脫身。或者，你就是不喜歡這份工作。
優先順序錯亂：無論什麼原因，我們都可以找到辦法逃避真正的工作。你說服自己有些工作更緊急，所以轉去處理，這種行為叫作優先順序錯亂——提高某個任務的優先順序，之後就有藉口推遲真正急迫的任務。
優先順序錯亂是自我麻醉的謊言，因為不能面對真正需要做的事情，所以我們告訴自己，其他事情更重要。我們知道這不是真的，但還是用它來欺騙自己。
死衚衕：
- 所有軟體開發者都要遇到死衚衕。比如你做了決定，選擇了走不通的技術道路。你對這個決定越是堅持，浪費的時間就越多。如果你認為這關係到自己的專業信譽，就永遠也走不出來。
- 在走入死衚衕時可以迅速意識到，並有足夠的勇氣走回頭路。這就是所謂的坑法則（The Rule of Holes）：如果你掉進了坑裡，別挖。
- 專業開發人員不會執拗於不容放棄也無法繞開的主意。他們會保持開放的頭腦來聽取其他意見，所以即使走到盡頭，他們仍然有其他選擇。
泥潭：
- 比死衚衕更糟的是泥潭。泥潭會減慢你的速度，但不會讓你徹底停下來。泥潭會阻礙你前進，但如果使盡全力，你仍然可以取得進展。
- 之所以說泥潭比死衚衕更麻煩，是因為在泥潭中，你仍然可以看到前進的道路，而且看起來總是比走回頭路要短（雖然實際不是這樣）。
- 在泥潭中繼續前進的危害是不易察覺的。面對簡單問題，你給出解決方案，保持程式碼的簡單、整潔。之後問題不斷擴充套件，越來越複雜，你則擴充套件程式碼庫，儘可能保持整潔。
- 走回頭路看起來代價很高，因為要把已有程式碼推翻重來，但是走回頭路絕對是最簡單的方法。如果繼續前進，系統就可能陷入泥潭，永遠不得脫身。
結論：
- 專業開發人員會用心管理自己的時間和注意力。他們知道優先順序錯亂的誘惑，他們也珍視自己的聲譽，所以會抵制優先順序錯亂。
- 他們永遠有多種選擇，永遠敞開心扉聽取其他解決方案，他們從來不會執拗於某個無法放棄的解決方案。
- 他們也時刻警惕著正在顯露的泥潭，一旦看清楚，就會避開。最糟糕的事情，莫過於看到一群開發人員在徒勞地拼力工作，結果卻陷入越來越深的泥潭。