接著上次的感悟繼續往下走。
第一章 大都是作者的在實踐中的深刻的建議，從下面開始，作者開始從一些具體開發例項進行解析。
1、重複的危害
a.給予計算機兩項自相矛盾的知識，是james t. kirk艦長（出自star trek，「星際迷航」——譯註）喜歡用來使四處劫掠的人工智慧生命失效的方法。遺憾的是，同樣的原則也能有效地使你的**失效。
b.可靠地開發軟體、並讓我們的開發更易於理解和維護的惟一途徑，是遵循我們稱之為dry的原則：系統中的每一項知識都必須具有單
一、無歧義、權威的表示。
1）無意的重複（inadvertent duplication）。開發者沒有意識到他們在重複資訊。
2) 無耐性的重複（impatient duplication）。開發者偷懶，他們重複，因為那樣似乎更容易。
3) 開發者之間的重複（interdeveloper duplication）。同一團隊（或不同團隊）的幾個人重複了同樣的資訊。
2、時間耦合
a.時間是軟體架構的乙個常常被忽視的方面，吸引我們的時間只是進度表上的時間。作為軟體自身的一種設計要素，時間有兩個方面對我們很重要：併發和次序。我們在程式設計時，通常並沒有把這兩個方面放在心上。當人們最初坐下來開始設計架構、或是編寫程式時，事情往往是線性的，那是大多數人的思考方式——總是先做這個，然後再做那個。但這樣思考會帶來時間耦合：在時間上的耦合，方法a必須總在方法b之前呼叫，「嘀」必須在「嗒」之前發生。
b.程式在時序性上的依賴是客觀存在的，對不得已的時序依賴一定要寫入文件或者標明注釋。
3、重構
a.隨著程式的演化，我們有必要重新思考早先的決策，並重寫部分**。這一過程非常自然。**需要演化；它不是靜態的事物。
b.無論**具有下面的哪些特徵，你都應該考慮重構**：重複；非正交的設計；過時的知識（最典型的就是需求已經下線、方案已經改變，但過時**卻還殘留甚至執行）；效能問題。
c.重構在實踐上的指導
1） 不要試圖在重構的同時增加功能。
2） 在開始重構前，確保你擁有良好的測試。
3） 採取短小，深思熟慮的步驟。把整體重構工作認真的分解為獨立、輕量的幾個步驟，每個步驟完成都可以進行測試，這將有助於快速定位問題。
4、可撤銷性
a.（there are no finaldecisions）不存在最終決策沒有人知道未來會悄怎樣，尤其是我們！所以要讓你的**學會「搖滾」：可以「搖」就「搖」，必須「滾」就「滾」。
b.我們不必做出許多關鍵的、不可逆轉的決策。這是一件好事情，因為我們並非總能在一開始就做出最好的決策。我們採用了某種技術，卻發現我們僱不到足夠的具有必需技能的人。我們剛剛選定某個第三方**商，他們就被競爭者收購了。與我們開發軟體的速度相比，需求、使用者以及硬體變得更快。
5、曳光彈
a.這個模擬也許有點暴力，但它適用於新的專案，特別是當你構建從未構建過的東西時。與槍手一樣，你也設法在黑暗中擊中目標。因為你的使用者從未見過這樣的系統，他們的需求可能會含糊不清。因為你在使用不熟悉的演算法、技術、語言或庫，你面對著大量未知的事物。同時，因為完成專案需要時間，在很大程度上你能夠確知，你的工作環境將在你完成之前發生變化。
b.用曳光彈找到目標（use tracer bullets tofind the target）
c.曳光開發與專案永不會結束的理念是一致的：總有改動需要完成，總有功能需要增加。這是乙個漸進的過程。
程式設計師修煉之道 從小工到專家
在專案開始之前 需求需要挖掘，而不僅僅是收集。找出使用者為何要做特定事情的原因，而不是他們目前做這件事情的方式。建立需求文件 把形式化的模板做備忘錄 好的需求文件會保持抽象 專案範圍的增大需要被記錄和可追溯，以及可評價 通過統計資訊 需求的收集和設計實現不是單向的線性關係，而是雙向關係。它們是 交付...
程式設計師修煉之道 從小工到專家
基本工具 構建自己的工具庫。使用原始碼控制。除錯bug 找到問題根源 可以快速 復現 bug。跟蹤。向別人解釋程式以找到問題所在。找bug範圍 先自己 確定無誤再找類庫或系統問題。不要固執的認為自己的 沒問題。不要假設，要驗證。注重實效的偏執 放棄寫出完美軟體的偏執。進行防禦性程式設計。合約。規定 ...
程式設計師修煉之道 從小工到專家
這本書的適用範圍可以從初學者到有經驗的程式設計師再到專案經理，作為一本偏向理論與思想的書，書中不可避免有些假大空的地方，再加上作者寫完本書的時間還在1999年，書中的很多方法與標準放在今天也已不再實用。但這些都不能掩蓋它的優秀之處，作者曾在本書完成十年後說過，如果這本書是放在現在編寫，1999年的那...