有些提示和訣竅可以應用於軟體開發的所有層面，有些想法幾乎是公理，有些過程實際上普遍使用。但是人們幾乎沒有為這些途徑建立這樣的文件。
重複的危害
系統中的每一項知識都必須具有單
一、無歧義、權威的表示。
dry——don't repeat yourself 不要重複你自己
重複是怎樣發生的：
無奈性的重複很常見，在我們的程式設計中體現的淋漓盡致，開發乙個web系統，每次都是呼叫第一次的時候的，一些功能**也是直接就ctrl+c，ctrl+v弄過來，然後改一改就ok了，實際上有好多重複，這就多了很多**，但是一旦除了錯誤，很難找到源頭，不知道從何改**，所以自己以後寫**的時候一定要注意這個問題，在寫**的時候不能偷懶，為了避免以後有更多的麻煩。
正交性
消除無關事物之間的影響，寫正交的系統，提高生產率與降低風險。
工具箱與庫
當自己引入第三方工具箱和庫時，要注意保持系統的正交性，要明智的選擇技術。
編碼測試
正交地設計和實現的系統也更易於測試，因為系統的各元件之間的互動是形式化的和有限的，更多的系統測試可以花在單個的模組級進行，這是好訊息，因為與整合測試相比，模組級測試要更容易規定和進行得多。在《構建之法》中也看過軟體測試的方法也是一些功能性測試。
可撤銷性
如果某個想法是你唯一的想法，再也沒有什麼比這更危險的事情了
——emil-auguste chartier,propos sur la religion,1938
不存在最終決策。
靈活的架構
有許多人會設法保持**的靈活性，而你還需要考慮維持架構、部署及**商整合等領域的靈活性。
曳光彈用曳光彈找到目標
曳光**有很多的優點：使用者能夠及早看到能工作的東西；開發者構建了乙個他們能在其中工作的結構；你有了乙個整合平台；你有了可用於演示的東西；你將更能感受到工作進展。
曳光彈並非總能擊中目標，曳光彈告訴你擊中的是什麼，那不一定總是目標，於是你調整準星，直到完全擊中目標為止，這正是要點所在。
曳光**也是如此，你在不能100%確定該去往何處的情形下使用這項技術，如果最初的幾次嘗試錯過了目標——使用者說：「那不是我的意思」，你需要的資料在你需要他時不可用，或是效能好像有問題，你不該感到驚奇，反而你應該高興。
自己在寫**的時候要有大局觀念，及時發現自己**中的不足，採用正交性書寫方法，減少後期的麻煩，同時也減少自己**的重複，對於一些冗餘**要及時清理，還要加上注釋，寫函式的時候要注意不起相似名字的函式，避免呼叫錯誤。
程式設計師修煉之道 從小工到專家
在專案開始之前 需求需要挖掘，而不僅僅是收集。找出使用者為何要做特定事情的原因，而不是他們目前做這件事情的方式。建立需求文件 把形式化的模板做備忘錄 好的需求文件會保持抽象 專案範圍的增大需要被記錄和可追溯，以及可評價 通過統計資訊 需求的收集和設計實現不是單向的線性關係，而是雙向關係。它們是 交付...
程式設計師修煉之道 從小工到專家
基本工具 構建自己的工具庫。使用原始碼控制。除錯bug 找到問題根源 可以快速 復現 bug。跟蹤。向別人解釋程式以找到問題所在。找bug範圍 先自己 確定無誤再找類庫或系統問題。不要固執的認為自己的 沒問題。不要假設，要驗證。注重實效的偏執 放棄寫出完美軟體的偏執。進行防禦性程式設計。合約。規定 ...
程式設計師修煉之道 從小工到專家
這本書的適用範圍可以從初學者到有經驗的程式設計師再到專案經理，作為一本偏向理論與思想的書，書中不可避免有些假大空的地方，再加上作者寫完本書的時間還在1999年，書中的很多方法與標準放在今天也已不再實用。但這些都不能掩蓋它的優秀之處，作者曾在本書完成十年後說過，如果這本書是放在現在編寫，1999年的那...