這本書是從多看上買來看的，睡前翻啊翻的慢慢的把他看完，其實也不是說了多麼高深的事情，就是強調一些程序員的想法，再搭配上一些敏捷的方法，不過說真的，這本書的確值得一讀。
- 李笑來老師在《把時間當作朋友》一書中提到：“所有學習上的成功，都只靠兩件事：策略和堅持，而堅持本身就應該是最重要的策略之一。”
- 當我們決定做一件事情的時候，首先就要多問問自己：為什麼要做這件事情？
- 不管路走了多遠，錯了就要重新返回。 ——土耳其諺語
- 如果你沒有犯過任何錯誤，就說明你可能沒有努力去工作。
- 你必須把重點放在解決問題上，而不是去極力證明誰的主意更好。
- 用Les Brown的一句話說就是：“你不需要很出色才能起步，但是你必須起步才能變得很出色。
- 這裡建議你牢記亞里士多德的一句格言：“能容納自己並不接受的想法，表明你的頭腦足夠有學識。”
- 真正的敵人是變化。
- 開發者（及項目經理）能做的一個最重要的決定就是：判斷哪些是自己決定不了的，應該讓企業主做決定
- 記住Ted Neward的評論：對象—關係的映射就是計算機科學的越南戰場
- 需求就像是流動著的油墨 Requirements are as fluid as ink
- 解決方案是，在每4周的迭代中間安排一週的維護任務。沒有規定說迭代必須要緊挨著下一個迭代。
- PIE原則，代碼必須明確說出你的意圖，而且必須富有表達力。這樣可以讓代碼更易於被別人閱讀 理解。代碼不讓人迷惑，也就減少了發生潛在錯誤的可能。一言以蔽之，代碼應意圖清晰，表達明確
- 代碼被閱讀的次數要遠超過被編寫的次數，所以在編程時多付出一點努力來做好文檔，會讓你在將來受益匪淺。
- 要將目標牢記在心：簡單、可讀性高的代碼。
- 告知，不要詢問。不要搶別的對象或是組件的工作。告訴它做什麼，然後盯著你自己的職責就好了。
- 針對is-a關係使用繼承；針對has-a或uses-a關係使用委託
- 記錄問題的時間不能超過在解決問題上花費的時間
- Martin Fowler在題為“Who Needs an Architect？”的文章中提到：一個真正的架構師“……應該指導開發團隊，提升他們的水平，以解決更為複雜的問題
- 代碼複查需要積極評估代碼的設計和清晰程度，而不只是考量變量名和代碼格式是否符合組織的標準
- 除非你可以讓某段代碼明確變得更好，否則不要隨意批評別人的代碼。