純文字的威力< 用純文字儲存知識 >缺點：1）與壓縮的二進位制格式相比，儲存純文字所需空間更多2）要解釋及處理純文字檔案，計算上的代價可能更昂貴6優點：1）保證不過時2）槓桿作用3）更易於測試。unix 哲學：提供」鋒利「的小工具，其中每一樣都意在把一件事情做好（面向行的純文字檔案）
原始碼控制：進步遠非由變化組成，而是取決於好記星。不能記住過去的人，被判重複過去。
除錯：除錯的心理學< 要修正問題，而不是發出指責 >
除錯的思維方式：最容易欺騙的人是乙個人自己。橡皮鴨：找到問題的原因的一種非常簡單、卻又特別有用的技術，是向別人解釋他< 不要假定，要證明 >
按合約設計：沒有什麼比常識和坦率更讓人感到驚訝。按合約設計： 一種簡單而強大的技術，他關注的是用文件記載（並約定）軟體模組的權利與責任，以確保程式正確性< 通過合約進行設計 >出錯時要偏向消費者，這是我們對行為的保證
斷言式程式設計：在自責中有一種滿足感。當我們責備自己時，會覺得再沒有人有權責備我們。這絕不會發生。。。我們不要這樣自我欺騙，特別是在編碼時< 如果他不可能發生，用斷言確保他不會發生 >
何時使用異常
解耦與得墨忒耳法則：好籬笆促成好鄰居。函式的得墨忒耳法則檢視使任何給定程式中的模組之間的耦合減至最少
元程式設計：再多的天才也無法勝過對細節的專注。我們可以讓我們的**變得高度可配置和」軟和「 ------ 也就是容易適應變化
< 要配置，不要整合 >< 將抽象放進**，細節放進元資料
不要讓你的專案（或你的職業生涯）走上渡渡鳥的道路（毛里裘斯島上的渡渡鳥不能適應人類和他們的家畜的出現，很久就滅絕了。這是人類
記載的第一起物種滅絕）
時間是軟體架構的乙個常常被忽視的方面。時間有兩個方面對我們很重要：併發（事情在同一時間發生）和次序（事情在時間中的相對位置）
我們需要容許併發，並考慮解除任何時間或次序上的依賴
它只是檢視：那人依然只聽到，他想要聽到的東西，而不顧其他。不要把程式寫成乙個大塊，應該」分而治之「，吧程式劃分成模組
模組的乙個好定義就是，他具有單一的、定義良好的責任讓檢視與模型分離
黑板系統讓我們完全解除了我們的物件之間的耦合，並提供了乙個」論壇「，知識消費者和生產者可以在**匿名、非同步地交換資料，還能減少我們必須編寫的**的數量。
可以用黑板協調完全不同的事實和因素，同時又使個參與方保持獨立、甚至隔離。
人最容易欺騙的人是乙個人自己，其實不論是在編碼還是生活中，我們每天都在欺騙自己，由於自己的懶惰，得過且過。
這個任務就這樣吧，這個作業就這樣吧，反正老師也不會看，而工作或者作業中存在的問題還有很多，這個時候我們自己就會給自己乙個跡象，這個跡象告訴我們，這個任務已經完成了，不需要再去完善他了。這時我們明知道這個任務沒有完成但我們也不會再去開啟它。造成的後果是工作上你可能會丟掉工作，學習上你可能會掛科。
所以認真對待自己做過的每一件事，不要欺騙自己！
程式設計師修煉之道 從小工到專家
在專案開始之前 需求需要挖掘，而不僅僅是收集。找出使用者為何要做特定事情的原因，而不是他們目前做這件事情的方式。建立需求文件 把形式化的模板做備忘錄 好的需求文件會保持抽象 專案範圍的增大需要被記錄和可追溯，以及可評價 通過統計資訊 需求的收集和設計實現不是單向的線性關係，而是雙向關係。它們是 交付...
程式設計師修煉之道 從小工到專家
基本工具 構建自己的工具庫。使用原始碼控制。除錯bug 找到問題根源 可以快速 復現 bug。跟蹤。向別人解釋程式以找到問題所在。找bug範圍 先自己 確定無誤再找類庫或系統問題。不要固執的認為自己的 沒問題。不要假設，要驗證。注重實效的偏執 放棄寫出完美軟體的偏執。進行防禦性程式設計。合約。規定 ...
程式設計師修煉之道 從小工到專家
這本書的適用範圍可以從初學者到有經驗的程式設計師再到專案經理，作為一本偏向理論與思想的書，書中不可避免有些假大空的地方，再加上作者寫完本書的時間還在1999年，書中的很多方法與標準放在今天也已不再實用。但這些都不能掩蓋它的優秀之處，作者曾在本書完成十年後說過，如果這本書是放在現在編寫，1999年的那...