《告別失控》這本書是聽《極客時間》的時候哪位大神（可能是左耳朵耗子）推薦的，最近正在讀這本書。
在本文中布魯斯同學挑選了7條個人喜歡的名言，大言不慚地評論一番。
Martin Golding (Or John F. Woods)
始終應當把將來負責維護你代碼的人想象成一個知道你住在哪裏的狂暴的精神病患者，以此來敦促自己小心翼翼地編碼。
爲了人身安全，我決心把這一句話當做Rule 1 - 第一條也是最重要的一條守則。攻城獅同學們，爲了不被祭天，爲了不暴屍街頭，寫代碼一定要三思而後提交啊。
候世達（Douglas Hofstadter）定律
做事所花費的時間總是比你預期的要長，即使你的預期中考慮了侯世達定律。
這個定律布魯斯同學深有體會。每個sprint無論怎麼修訂預期，怎麼加上多的緩衝時間也沒用。不僅僅整個sprint是這樣，單個的user story也是這樣。預估兩天能夠完成的，四天弄完算不錯了。如果一個任務預估需要5天，那就呵呵了，最後一定不是完成而是“被完成”。關於“完成”的定義和理解，請看下面。
Chris Sims
要給“完成”下一個定義。若你的團隊沒有對“完成”的定義達成共識，自然很難去爲工作的圓滿完成而歡欣鼓舞。當團隊成員說他們“完成”了他們負責的那部分特性時，究竟是意味着：
- 在他們的機器上可以執行？
- 已檢入到源代碼管理系統中？
- 進行過完整的驗收測試？
- 所有測試都通過了？
- 文檔編寫完成了？
- 經過同伴審查了？
以前我總覺得程序員的素質都很高，關於“definition of done”的主體部分應該是共識：例如代碼已經實現了並且添加了對應的單元測試，已經check in到代碼庫等等。然而，情況並不是這樣的，現實中不樂觀。要達成共識，一定是要明確地提出來，並且黑紙白字寫下來。
有一半的項目都不是中途出問題，而是一開始就錯了。因此一定要保證頭6個星期做得正確。
正如“好的開始是成功的一半”這句諺語說的，開始階段非常重要。項目的開始階段，大多工作就是“搭架子”，“定規矩”。沒有規矩不成方圓，而架子底座如果歪了，後期要糾正就非常困難了。引申一點，說說“演進型原型”和“拋棄型原型”。以前我總覺得講一個系統原型拋棄掉，真的蠻可惜。雖然說重新做的工程量不是特別大，但是總有些浪費。但是，如果採用”演進型原型“常常會造成嚴重的問題，就是團隊成員，尤其是新的成員，可能會誤以爲項目的要求不高：因爲他們看到原型項目裏邊的代碼質量可能不高，也沒用什麼嚴肅的測試，所以心理上的就有一種“錨定”效應。現在我是“拋棄型原型”的粉絲，每次的原型都丟掉重新開一個新的代碼庫重頭開始設計。
Ray Ozzie, Lotus Notes的創造者，Groove公司的創立者，微軟公司的CTO
複雜性是個要命的東西。它會榨取開發者的生命力，會使產品難於計劃、構建和測試，會帶來安全性上的挑戰，還會使最終用戶和管理員垂頭喪氣。
作爲程序員，我們面對的最大困難不是掌握編程語言的語法語義，不是熟悉工具和框架等等，最有挑戰性的事情就是管理複雜性。項目的規模和複雜程度不是線線關係。根據業界的經驗，問題的複雜性每增加10%，軟件解決方案的複雜性就會相應地增加100%。(Robert L. Glass) 一些項目並不是開始就變壞的，而是隨着需求越來越多，“特例‘越來越猖狂，代碼的複雜度終於超過團隊能夠管理的範圍。
Linus Torvalds, Linux的爸比
大多數優秀的程序員從事編程不是爲了工資，也不是爲了受公衆崇拜，而是因爲編程很有趣。
這一點我也非常認同，雖然說掙錢很重要。但是沒有興趣，可能真堅持不下來。
噹噹噹當，最後一條來了。
寫文檔就像過性生活：如果做得好，那就非常非常號；如果做得不好，那也
總比沒有好。-- Dick Brabdon
是不是很驚喜？！我覺得這老哥說的蠻對的。每次接受一個遺留項目就先問：有沒有文檔？如果發現沒有的時候，那個失望的感覺。。。。。。