在專案開始之前：
需求需要挖掘，而不僅僅是收集。找出使用者為何要做特定事情的原因，而不是他們目前做這件事情的方式。 建立需求文件：把形式化的模板做備忘錄 好的需求文件會保持抽象 專案範圍的增大需要被記錄和可追溯，以及可評價(通過統計資訊) 需求的收集和設計實現不是單向的線性關係，而是雙向關係。它們是「交付高質量的系統」的不同方面。 解開謎題 解開謎題的關鍵在於確定施加的各種約束，並確定你確實擁有的自由度 確定真正的約束 對約束進行分類，並劃定優先順序 你所需要的知識真正的約束，令人誤解的約束，還有區分它們的智慧型。 編寫程式規範 編寫程式規範是乙個交流活動，旨在解釋並闡明系統的需求 不要追求捕捉系統或需求的每一處細節和細微差別，因為細節不一定可以被自然語言以可理解的方式定義。 不要陷入對規範的追求中，在合適的時候編碼，反哺規範。 不要做方法的奴隸，適合的就是最好的，能解決問題就行。
注重實效的專案：
不符合使用者期望的專案注定是失敗的。即以使用者為中心。 使專案級活動保持一致和可靠的乙個最重要的因素是使你的各種工作流程自動化。 專案的各種活動，分析，設計，編碼，測試不會孤立地發生，它們是看待同一問題的不同方式。 在開發乙個專案時，我們再尋求內聚的，在很大程度上自足的團隊。使用組織**使用的技術，像合約，解耦，正交性，這樣的技術來組織各種資源，有助於使團隊作為整體與變化的各種效應隔離開來。 測試： 早測試，常測試，自動測試。 要通過全部的測試，編碼才算完成。 整合測試說明組成專案的主要子系統能工作，並且能很好的協同。 測試狀態覆蓋，而不是**覆蓋。 大多數測試都應該自動完成。 注釋：注釋應該討論為何要做某事，它的目的。**已經說明了它是怎樣完成的。
程式設計師修煉之道 從小工到專家
基本工具 構建自己的工具庫。使用原始碼控制。除錯bug 找到問題根源 可以快速 復現 bug。跟蹤。向別人解釋程式以找到問題所在。找bug範圍 先自己 確定無誤再找類庫或系統問題。不要固執的認為自己的 沒問題。不要假設，要驗證。注重實效的偏執 放棄寫出完美軟體的偏執。進行防禦性程式設計。合約。規定 ...
程式設計師修煉之道 從小工到專家
這本書的適用範圍可以從初學者到有經驗的程式設計師再到專案經理，作為一本偏向理論與思想的書，書中不可避免有些假大空的地方，再加上作者寫完本書的時間還在1999年，書中的很多方法與標準放在今天也已不再實用。但這些都不能掩蓋它的優秀之處，作者曾在本書完成十年後說過，如果這本書是放在現在編寫，1999年的那...
程式設計師修煉之道 從小工到專家（三）
1 斷言式程式設計 a.在自責中有一種滿足感。當我們責備自己時，會覺得再沒人有權責備我們。奧斯卡 王爾德 多里安 格雷的畫像 2 靠巧合程式設計 a.不要靠巧合程式設計 don t program by coincidence b.不要使用你不理解的嚮導 don t use wizard code ...