第一章——注重實效的哲學
作為乙個負責人的程式設計師，在遇到問題時，應該是提供各種選擇，不要找蹩腳的藉口。
在寫**的過程中，破窗效應同樣適用，所以在出現小問題的時候就應該及時解決，不要容忍破窗戶。我們看到過整潔、執行良好的系統，一旦窗戶開始破裂，就相當迅速的惡化。置之不理會更快的加速腐爛的程序。
石頭湯的故事，站在士兵的角度，做變化的催化劑，我們常常可以效仿這些士兵，協作共贏；同時站在村民的角度，應該記住大圖景，大多數軟體災難都是從微不足道的小事情開始的。要持續不斷的觀察周圍發生的事情，而不只是你自己在做的事情。
我們應該讓你的使用者參與權衡，使質量成為需求問題。知道何時止步，在某些方面來說，程式設計也像是繪畫，不要因為過度修飾和過於求精而毀損完好的程式，繼續前進，讓你的**憑著自己的質量站立一會兒。它也許不完美，但不用擔心，它不可能完美。
學會經營我們的知識資產，基本上一句話概括：技多不壓身，你知道的東西越多，你就越有價值。持續學習，尤其是計算機領域變化很快，掌握技術越多，越能更好的進行調整，趕上變化。在學習的過程中也要注意進行批判性的思考，不要人云亦云，要有自己的想法，批判的分析你讀到的和聽到的。
學會交流，你說什麼和你怎麼說同樣重要。
第二章——注重實效的途徑
遵循dry原則：don't repeat yourself.使系統中的重複降到最小，降低各元件間的依賴性。
正交性，即互不依賴性，這樣會提高生產率和降低風險。消除無關事物之間的影響。編碼時避免使用全域性資料，避免編寫相似的函式。
關鍵決策不容易撤銷，否則會付出極大的代價，不存在最終決策。
架構的靈活性，沒人會知道未來會怎樣，所以要讓你的**學會「搖滾」，可以「搖」就「搖」，必須「滾」就"滾」。
第三章——基本工具
用純文字儲存知識，優點是保證不過時，易於測試。
估算，避免發生意外。在著手前進行估算，提前發現潛在的問題。
用好一種編輯器。
總是用原始碼控制。能夠被安全的儲存。可以進行自動的和可重複的產品構建。
自從14世紀以來，bug（蟲子、臭蟲）一詞就一直被用於描述「恐怖的東西」。
接受事實：除錯就是解決問題，要據此發起進攻。要修正問題，而不是發出指責。記住除錯的第一準則：不要恐慌。
咱就是說，有的知識我也不知道是什麼意思，雖然沒寫的我也不知道，咱就是說還得再學習，不太理解。
閱讀《程式設計師修煉之道 從小工到專家》有感 3
第七章 在專案開始之前 不要蒐集需求，挖掘它們。需求是對需要完成的某件事情的陳述。與使用者一同工作，以像使用者一樣思考。開採需求地過程也是開始與使用者群建立和諧地關係 了他們對你正在構建地系統的期許和希望的時候。需求不是架構。需求不是設計，也不是使用者介面。需求是需要。製作需求文件時的一大危險是太過...
程式設計師修煉之道 從小工到專家
在專案開始之前 需求需要挖掘，而不僅僅是收集。找出使用者為何要做特定事情的原因，而不是他們目前做這件事情的方式。建立需求文件 把形式化的模板做備忘錄 好的需求文件會保持抽象 專案範圍的增大需要被記錄和可追溯，以及可評價 通過統計資訊 需求的收集和設計實現不是單向的線性關係，而是雙向關係。它們是 交付...
程式設計師修煉之道 從小工到專家
基本工具 構建自己的工具庫。使用原始碼控制。除錯bug 找到問題根源 可以快速 復現 bug。跟蹤。向別人解釋程式以找到問題所在。找bug範圍 先自己 確定無誤再找類庫或系統問題。不要固執的認為自己的 沒問題。不要假設，要驗證。注重實效的偏執 放棄寫出完美軟體的偏執。進行防禦性程式設計。合約。規定 ...