原文地址：http://blog.sina.com.cn/s/blog_65a86d8e0100nr5s.html
譯序
- 編程是一種技藝，一種需要用心學習的技藝，也許，只有在長久的學習之後，我們纔會開始明白“hacker”的真正含義："Someone who loves to program and enjoys being clever about it"。
前言
- 思考你的工作
序
- 調整你的方法，以適應當前情形與環境
- 注重時效的程序員不僅要完成工作，而且要完成得漂亮
- 每一個開發真都是獨特的，有着個人的力量和弱點、偏好和嫌惡
- 每一條小知識都可能會影響今後幾年裏的某項決策
- 不要靠自動駕駛儀，不間斷的思考，實時的批判你的工作，老IBM公司的箴言，THINK！
- 我們採集的只是石頭，卻必須時刻展望未來的大教堂——採石工人的信條
第1章 注重實效的哲學
- 能夠越出直接的問題去思考，設法把問題放在更大的語境中，總是設法注意更大的圖景。
- 對所做的每件事情負責。
- 你需要擁有廣泛的知識和經驗基礎才能贏得一切。學習是一個持續不斷的過程。
- 在所有弱點中，最大的弱點就是害怕暴露弱點
- 爲你自己和你的行爲負責這樣一種觀念，是注重實效的哲學的一塊基石。注重實效的程序員對他或她自己的職業生涯負責，並且不害怕承認無知或錯誤。
- 我們可以爲我們的能力自豪，但對於我們的缺點——還有我們的無知和我們的錯誤——我們必須誠實。
- 負責是你主動承擔的東西。你承諾確保某件事情正確完成，但你不一定能直接控制事情的每一個方面，除了盡你所能以外，你必須分析風險是否超出了你的控制。對於不可能做到的事情或是風險太大的事情，你有權不去爲之負責。你必須基於你自己的道德準則和判斷來做出決定。
- 如果確實同意要爲某個結果負責，你就必須切實負起責任。當你犯錯誤，或是判斷失誤時，誠實的承認它，並設法給出各種選擇，不要責備別人或別的東西，或是拼湊藉口。
- 要提供各種選擇，而不是找接口。不要說事情做不到，要說明能夠做什麼來挽回局面。
- 不要害怕提出要求，也不要害怕承認你需要幫助。
- 在有些情況下，你也許確切的知道需要做什麼，以及怎樣去做，整個系統就在你的眼前——你知道它是對的。但請求許可去做事情，你會遇到拖延和漠然。 設計出你可以合理要求的東西，好好開發它，一旦完成，就拿給大家看，讓他們大吃一驚。然後說：“要是我們增加……可能就會更好”。假裝那並不重要。坐回椅子上，等着他們開始要你增加你本來就想要的功能。人們發現，參與正在發生的成功要更容易。讓他們瞥見未來，你就能讓他們聚集在你周圍。
- 常常是小事情的累積破壞了士氣和團隊。
- 請求原諒比獲取許可更容易
- 欲求更好，常把好事變糟。
- 時間、技術和急躁都在合謀反對我們。
- 知道何時止步、
- 不要因爲過度修飾和過於求精而損毀完好的程序
- 知識上的投資總能得到最好的回報
- 你的知識和經驗是你最重要的職業財富。
- 程序員所知道的關於計算技術和他們所工作的應用領域的全部事實以及他們的所有經驗視爲他們的知識資產。管理知識資產與管理金融資產非常相似。
- 經營你的資產
-
- 定期投資——就像金融投資一樣，你必須定期爲你的知識資產投資，即使投資量很小，習慣自身也和總量一樣重要。
- 多元化——你知道的不同的事情越多，你就越有價值。未作底線，你需要知道你目前所用的特定技術的各種特性。但不要就此止步，你掌握的技術越多，你就越能更好的進行調整，趕上變化。
- 管理風險——從高風險、可能有高回報，到低風險、低迴報，技術存在於這樣一條譜帶上，把你所有的金錢都投入可能突然崩盤的高風險股票並不是一個好主意，你也不應太保守，錯過可能的機會。不要把你所有的技術雞蛋都放在一個籃子裏。
- 低買高賣——在新興的技術流行之前學習它可能就和找到被低估的股票一樣困難，但所得到的就和那樣的股票帶來的收益一樣。
- 重新評估和平衡。
- 目標
-
- 每年至少學習一種新語言——不同語言以不同方式解決相同的問題，通過學習若干不同的方法，可以幫助你拓寬你的思維，並避免墨守成規。
- 每季度閱讀一本技術書籍——一旦你養成習慣，就一個月讀一本書。在你掌握了你正在使用的技術之後，拓寬範圍，閱讀一些與你項目無關的書籍。
- 也要閱讀非技術書籍。
- 上課
- 參加本地用戶組織——與世隔絕對你的職業生涯來說可能是致命的，打聽一下你們公司以外的人都在做什麼。
- 試驗不同的環境
- 跟上潮流——選擇所涵蓋的技術與你當前項目不同的刊物。
- 上網
- 持續投入十分重要，一旦你熟悉了某種新語言或新技術，繼續前進，學習另外一種。
- 設法把你學到的東西應用到你當前的項目中。即使你的項目沒有使用該技術，你或許也能借鑑一些想法。
- 如果你自己找不到答案，就去找能找到答案的人。不要把問題擱在那裏，與他人交談可以幫助你建立人際網絡，而因爲在這個過程中找到了其他不相關問題的解決方案，你也許還會讓自己大吃一驚。
- 所有閱讀和研究都需要時間，而時間已經很短缺。所以你需要預先規劃，讓自己在空閒的片刻時間裏總有東西可讀。
- 批判的思考你讀到的和聽到的。你需要確保你的資產中的知識是準確的，並且沒有收到供應商或媒體炒作的影響。
- 與Guru打交道的禮節與教養：
-
- 確切的知道你想問什麼，並儘量明確具體
- 小心而得體的組織你的問題。記住你是在請求幫助；不要顯得好像是在要求對方回答。
- 組織好問題後，停下來，再找找答案
- 決定你是想公開提問還是私下提問
- 坐回椅子上，耐心等候。
- 我相信，被打量比被忽略要好
- 問題不只是你有什麼，還要看你怎樣包裝它，除非你能夠與他人交流，否則就算你擁有最好的主意，最漂亮的代碼，或是最注重實效的想法，最終也毫無結果，沒有有效的交流，一個好想法就只是一個無人關心的孤兒。
- 只有當你是在傳達信息時，你纔是在交流
- 與製作文檔的過程相比，我們製作出的文檔最後並沒有那麼重要。
- 如果你想要大家聽你說話，你必須使用一種方法，聽他們說話。
- e-mail是永久性的，要設法像對待任何書面備忘錄或報告一樣小心對待e-mail
第2章 注重實效的途徑
- 不要在系統各處對知識進行重複；不要把任何一項知識分散在多個系統組件中。
- 我們都是在一個時間和資源有限世界上工作，如果你善於估計事情需要多長時間完成，你就能更好的在兩者都很匱乏的情況下生存下去。
- 系統中的每一項只是都必須具有單一、無歧義、權威的表示。
- 糟糕的代碼才需要註釋
- 不可信任的註釋比完全沒有註釋更糟
- 欲速則不達
- 你所要做的是營造一種環境，在其中要找到並複用已有的東西，比自己編寫更容易。如果不容易，大家就不會去複用。而如果不進行復用，你們就會有重複知識的風險。
- 非正交系統的改變與控制更復雜是其固有的性質。當任何系統的各組件互相高度依賴時，就不再有局部修正(local fix)這樣的事情。
- 編寫正交系統的好處：提高生產率與降低風險。
-
- 提高生產率
-
- 改動得以局部化，所以開發時間和測試時間得以降低。
- 正交的途徑還能促進複用
- 如果你對正交的組件進行組合，生產率會有相當微妙的提高。
- 降低風險
-
- 有問題的代碼區域被隔離開來
- 所得系統更健壯
- 正交系統很可能能得到更好的測試
- 你不會與特定的供應商、產品、或是平臺緊綁在一起
- 從基礎設施與應用分離開始，每個主要的基礎設施組件有自己的子團隊，如果應用功能的劃分顯而易見，那就照此劃分，然後我們考察我們現有的（或計劃有的）人員，並對分組進行相應的調整。
- 不要依賴你無法控制的事物屬性。
- 在你引入第三方工具箱和庫時，要注意保持系統的正交性，要明智的選擇技術。
- 第三方庫細節與代碼隔離有額外的好處：它使得你在以後更容易更換供應商。
- 用於維持正交性的技術：
-
- 讓你的代碼保持解耦
- 避免使用全局數據
-
- 使用Singleton要小心，它可能造成不必要的關聯
- 避免編寫相似的函數
- 要成不斷的批判對待自己的代碼的習慣，尋找任何重新進行組織，以改善其結構和正交性的機會，這個過程叫重構。
- 構建但願測試本身是對正交性的一項有趣測試
- 如果你參加了一個項目，大家都在不顧一切的做出改動，而每一處改動似乎都會造成別的東西出錯，回想一下直升機的噩夢，項目很可能沒有進行正交的設計和編碼，是重構的時候了。
- 如果某個想法是你唯一的想法，再沒有什麼比這個更危險的事情了。
- 如果你嚴重依賴某一事實，你幾乎可以確定它將會變化
- 可以把第三方產品隱藏在定義良好的抽象接口後面
- 無論你使用的是何種機制，讓它可以撤銷，如果某樣東西是自動添加的，它也可以被自動去掉
- 沒有人知道未來會怎樣，尤其是我們！所以要讓你的代碼學會“搖滾”，可以“搖”就“搖”，可以“滾”就“滾”。
- 一旦你在系統的各組件間實現了端到端的鏈接，你就可以檢查你離目標還有多遠，並在必要的情況下進行調整，一旦你完全瞄準，增加功能將是一件容易的事情。
- 曳光彈代碼方法的優點：
-
- 用戶能夠及早看到能工作的東西
- 開發者構建了一個他們能在其中工作的結構
- 你有了一個集成平臺
- 你有了可用於演示的東西
- 你將更能夠感覺到工作進展
- 原型製作是一種學習經驗，其價值並不在於所產生的代碼，而在於所學到的經驗教訓。那纔是原型製作的要點所在。
- 語言的界限就是一個人的世界的界限
- 計算機語言會影響你思考問題的方式，以及你看待交流的方式
- 問題領域的語言也可能會提示出編程方案
- 應該讓你的項目更靠近問題領域，通過在更高的抽象層面上編碼，你獲得了專心解決領域問題的自由，並且可以忽略瑣碎的實現細節。
- 數據語言產生某種形式的數據結構給應用使用，這些語言常用語表示配置信息。
- 命令語言將被實際執行，包含語句、控制結構，以及類型的東西。
- 把高級命令語言直接嵌入你的應用程序是一種常見做法。
- 在被要求進行估算時說：“我等會回答你”，放慢估算速度，並花一點時間仔細檢查各步驟，你幾乎總能得到更好的結果。
第3章 基本工具
- 工具放大你的才幹，你的工具越好，你越是能更好的掌握它們的用法，你的生產力就越高。
- 如果你沒有高超的調試技巧，你就不可能成爲了不起的程序員。
- 通過純文本，你可以做你通過某種二進制格式所能所的每件事情。
- 大多數二進制格式的問題在於，理解數據所必須的語境與數據本身是分離的。通過純文本，你可以獲得自描述的不依賴於創建它的應用的數據流。
- 使用純文本的兩個主要缺點：
-
- 與壓縮的二進制格式相比，存貯純文本所需空間更多
- 要解釋及處理純文本文件，計算上的代價可能更昂貴
- 文本的威力：
-
- 保證不過時
- 槓桿作用
- 更易於測試
- GUI的好處是WYSIWYG——所見即所得(what you see is what you get)，缺點是WYSIAYG——所見即全部所得（what you see is all you get）。
- 現代計算機系統仍然侷限於做你告訴它的事情，而不一定是你想要它做的事情。
- 在技術競技場上，你應該專注於修正問題，而不是發出指責。
- bug是你的過錯還是別人的過錯，並不是真的很有關係，它仍然是你的問題。
- 調試的第一準則：不要恐慌。
- 我們想要的不是能夠通過長長的步驟再現的bug；我們要的是能夠通過一條命令再現的bug。
- bug有可能存在於OS、編譯器、或是第三方產品中——但這不應該是你的第一想法。有大得多的可能性的是，bug存在於正在開發的應用代碼中。
- 當你遇到讓人吃驚的bug時，除了只是修正它而外，你還需要確定先前爲什麼沒有找出這個故障。考慮你是否需要改進單元測試或其他代碼，以讓它們有能力找出這個故障。
- 確保無論發生什麼，你都知道它是否會再次發生。如果修正這個bug需要很長時間，問問你自己爲什麼。你是否可以做點什麼，讓下一次修正這個bug變得更容易？
- 如果bug是某人的錯誤假定的結果，與整個團隊討論這個問題，如果一個人有誤解，那麼許多人可能也有。
第4章 注重實效的偏執
- 當每個人都確實要對你不利時，偏執就是一個好主意
- 沒有什麼比常識和坦率更讓人感到驚訝
- 與計算機系統打交道很困難，與人打交道更困難
- 保持坦率的最佳方案之一就是合約。合約即規定你的權利與責任，也規定對方的權利與責任。此外，還有關於任何一方沒有遵守合約的後果的約定。
- 通過早崩潰，在問題現場找到和診斷問題要容易得多。
- 有時候別人在你自己意識到之前就能覺察到你的事情出了問題。
- 儘早檢測問題的好處之一是你可以更早崩潰。許多時候，讓你的程序崩潰是你的最佳選擇。
- 死程序帶來的危害通常要比有疾患的程序小得多。
- 無論何時你發現自己在思考“但那當然不可能發生”，增加代碼檢查它，最容易的辦法是使用斷言。
- 分配某項資源的例程或對象應該負責解除該資源的分配。
- 當你解除頂層結構的分配時，該如何決定誰爲某個聚集數據結構中的數據負責：
-
- 頂層結構還負責釋放它包含的任何子結構，這些結構隨機遞歸的刪除它們包含的數據
- 只是解除頂層結構的分配，它指向的（沒有在別處引用的）任何結構都會被遺棄。
- 如果頂層結構含有任何子結構，它就拒絕解除自身的分配。
第5章 彎曲，或折斷
- 編寫羞怯的代碼是有益的：不向別人暴露你自己，不與太多人打交道。
- 使若干模塊緊密耦合，你可以獲得重大的性能改進，只要對於那些被耦合在一起的模塊而言，這是衆所周知的和可以接受的，你的設計就沒有問題。
- 時間有兩個方面對我們很重要：併發（事情在同一時間發生）和次序（事情在事件中的相對位置）。
- 大多數人的思考方式——總是先做這個，然後再做那個，但這樣思考會帶來時間耦合，在時間上的耦合。
- 我們創建的不是組件，而是服務——位於定義良好的，一致的接口之後的獨立，併發的對象。
- MVC：
-
- 模型：表示目標對象的抽象數據模型，模型對任何視圖或控制器都沒有直接的瞭解。
- 視圖：解釋模型的方式，它訂閱模型中的變化和來自控制器的邏輯事件。
- 控制器：控制視圖，並向模型提供新數據的途徑，它既向模型，也向視圖發佈事件。
- 黑板方式的編程消除了對太多接口的需要，從而能帶來更優雅、更一直的系統。
- 黑板：數據到達的次序無關緊要；在收到某項事實時，它可以出發適當的規則，反饋也很容易處理；任何規則集的輸出都可以張貼到黑板上，並出發更爲適用的規則。
- 可以用黑板協調完全不同的事實和因素，同時又使各參與方保持獨立，甚至隔離。
第6章 當你編碼時
- 編碼不是機械工作，程序員每一分鐘都需要作出決策——如果要讓所得的程序享有長久、無誤和富有生產力的“一生”，就必須對這些決策進行仔細的思考和判斷。
- 不主動思考他們的代碼的開發者是在靠巧合編程——代碼也許能工作，但卻沒有特別的理由說明他們爲何能工作。
- 要讓代碼易於測試
- 小心那些替你編寫大量代碼的工具，除非你理解他們在做什麼。
- 保持警覺能夠很好的防治災難的發生。
- 怎樣深思熟慮的編程：
-
- 總是意識到你在做什麼
- 不要盲目的編程，試圖構建你不完全理解的應用，或是使用你不熟悉的技術，就是希望自己被巧合誤導
- 按照計劃行事
- 依靠可靠的事物
- 爲你的假定建立文檔
- 不要只是測試你的代碼，還要測試你的假定。編寫斷言測試你的假定，如果的你斷言是對的，你就改善了代碼中的文檔，如果你的假定是錯的，那麼就爲自己慶幸吧。
- 爲你的工作劃分優先級，把時間花在重要的方面，很有可能，他們是最難的部分。如果基本原則或基礎設施不正確，再花哨的鈴聲和口哨也是沒有用的。
- 不做歷史的努力。不要讓已有的代碼吃陪將來的代碼，如果不再使用，所有的代碼都可被替換。不要讓你已經做完的事情約束你下一步要做的事情——準備好進行重構。
- 每個開發者都應該有設計與分析算法的才能。
- 隨着程序的演化，我們有必要重新思考早先的決策，並重寫部分代碼。這一過程非常自然，代碼需要演化，它不是靜態的事物。
- 時間壓力常常被用作不進行重構的藉口，但這個藉口並不成立。
- 追蹤需要重構的事物。如果你不能立刻重構某樣東西，就一定要把它列入計劃。確保收到影響的代碼的使用者知道該代碼計劃要重構，以及這可能會怎樣影響他們。
- 重構是一項需要慎重，深思熟慮，小心進行的活動。
-
- 不要試圖在重構的同時增加功能
- 在開始重構前，確保你擁有良好的測試。儘可能經常運行這些測試。這樣，如果你的改動破壞了任何東西，你就能很快知道。
- 採用短小、深思熟慮的步驟。如果你使你的步驟保持短小，並在每個步驟之後進行測試，你將能夠避免長時間的調試。
- 你看到不怎麼合理的代碼是，既要修正它，也要修正依賴於它的每樣東西。要管理痛苦：如果它現在有損害，但以後的損害會更大。你也許最好一勞永逸的修正它，記住軟件熵中的教訓：不要容忍破窗戶。
- 不管是那種方法，要記住：如果你不容易找到它，你就不會使用它。
- 如果代碼曾經出現過問題，它很可能還會再出問題。
- 你編寫的所有軟件都將進行測試——如果不是由你和你們團隊測試，那就要由最終用於測試——所以你最好計劃好對其進行徹底的測試。
- 測試是技術，但更是文化。
- 毋庸否認，應用的編寫正變得越來越難。特別是用戶界面，正在日益變得複雜。
第7章 在項目開始之前
- 項目啓動太快是一個問題，但等得太久可能會更糟。
- 完美，不是在沒有什麼需要增加，而是在沒有什麼需要去掉時達到的。
- 需求很少存在於表面上。通常，他們深深地埋藏在層層假定、誤解和政治手段的下面。
- 找出用戶爲何要做特定事情的原因，而不是他們目前做這件事情的方式，這很重要。開發必須解決用戶的商業問題，而不只是滿足他們陳述的需求。
- 儘管奴隸般重複已經存在的事物會阻礙進步，但我們必須要提供通往未來的過渡。
- 成功的工具會適應使用它們的雙手。
- 不要做任何表示方法的奴隸。
- 需求不是架構，需求不是設計，也不是用戶界面，需求是需要。
- 許多項目的失敗都歸咎於項目範圍的增大——也稱爲特性膨脹、蔓延特性論、或是需求蔓延。
- 管理需求增長的關鍵是向項目出資人指出每項新特性對項目進度的影響。
- 有些約束是絕對的，有些則是先入之見。絕對的約束必須受到尊重，不管它們看上去有多討厭或多愚蠢；另一方面，有些外表上的約束也許根本不是真正的約束。
- 解開謎題的關鍵在於確定加給你的各種約束，並確定你確實擁有的自由度。
- 在面對棘手的問題時，列出所有在你面前的可能途徑。不要排除任何東西，不管它聽起來有多無用或愚蠢。現在，逐一檢查列表中的每一項，並解釋爲何不能採用某個特定的途徑。你確定嗎？你能否證明？
- 軟件開發仍然不是科學，讓你的直覺爲你的表演做出貢獻。
- 沒有給編碼者留下任何解釋餘地的設計剝奪了他們發揮技巧和藝術才能的權利。
- 你越是把規範當做安樂毯，不讓開發者進入可怕的編碼世界，進入編碼階段就越困難。
- 盲目的採用任何技術，而不把它放進你的開發實踐和能力的語境中，這樣的處方肯定會讓你失望。
- 決不要低估採用新工具和新方法的代價，要做好準備，把使用這些技術的第一個項目當做一種學習經驗。
- 要記住誰是主人，不要變成方法學的奴隸。
第8章 注重實效的項目
- 質量是一個團隊問題，不應該容忍破窗戶。
- 質量只可能源於全體團隊成員都作出自己的貢獻。
- 團隊無需拒絕無法控制的變化——你只需注意到它們正在發生。
- 看上去沉悶寡言的項目是最糟糕的團隊。
- 有一個簡單的營銷訣竅，能幫助團隊作爲整體與外界交流：創立品牌。
- 把你的人劃分成小團隊，分別負責最終系統的特定方面的功能。讓各團隊按照各人的能力，在內部自行進行組織。按照他們約定的承諾，對項目中的其他團隊負有責任。
- 創立一組自行其是的團隊並放任自流，是一種災難性的處方。項目至少需要兩個“頭”——一個主管技術，另一個主管行政。
-
- 技術主管設定開發哲學和風格，給各團隊指派責任，並仲裁成員之間不可避免的“討論”，技術主管還要不斷關注大圖景，設法找出團隊之間任何不必要的，可能降低總體正交性的交叉。
- 行政主管（或項目經理）調度各團隊所需的各種資源，見識並報告緊張情況，並根據商業需要幫助確定各種優先級，在與外界交流時，行政主管還要充當團隊的大使。
- 確保一致和準確的一種很好的方式是使團隊所做的每件事情自動化。
- 團隊是由個體組成的，讓每個成員都能以他們自己的方式閃亮，給他們足夠的控件，以支持他們，並確保項目的交付能夠符合需求。
- 文明通過增加我們不加思索就能完成的重要操作的數目而取得進步。
- 人工流程不能保證一致性，也無法保證可重複性，特別是在不同的人對流程的各個方面有不同解釋時。
- 讓計算機去做重複，庸常的事情——它會做得比我們更好，我們有更重要，更困難的事情要做。
- 用戶高速了你他們需要什麼，但那是他們需要的嗎？
- 註釋應該討論爲何要做某事，它的目的和目標，代碼已經說明了它是怎樣完成。
- 匈牙利表示法在OO系統是絕對不合適的。
- 對待文檔要像對待代碼一樣用新，用戶（還有後來的維護者）會爲你唱讚歌的。
- 在現實中，項目的成功是由它在多大程度上滿足了用戶的期望來衡量的。不符合用於期望的項目註定是失敗的，不管交付的產品在絕對的意義上有多好。
- 決不要忘了你的應用要解決的商業問題。
- 給他們的東西要比他們期望的多一點。給系統增加某種面向用戶的特性所需的一點額外努力將一次又一次在商譽上帶來回報。
- 爲用戶的機構定製splash屏幕。
提示
- Care About Your Craft. 關心你的技藝。
- Think! About Your Work. 思考！你的工作。
- Provide Options, Don't Make Lame Excuses. 提供各種選擇，不要找蹩腳的藉口。
- Don't Live with Broken Windows. 不要容忍破窗戶。
- Be a Catalyst for Change. 做變化的催化劑。
- Remember the Big Picture. 記住大圖景。
- Make Quality a Requirements Issue. 使質量成爲需求。
- Invest Regularly in Your Knowledge Portfolio. 定期爲你的知識資產投資。
- Critically Analyze What You Read and Hear. 批判的分析你讀到的和聽到的。
- It's Both What You Say and the Way You Say It. 你說什麼和你怎麼說同樣重要。
- DRY - Don't Repeat Yourself. 不要重複你自己。
- Make it Easy to Reuse. 讓複用變得容易。
- Eliminate Effects Between Unrelated Things. 消除無關事物之間的影響。
- There Are No Final Decisions. 不存在最終決策。
- Use Tracer Bullets to Find the Target. 用曳光彈找到目標。
- Prototype to Learn. 爲了學習而製作原型。
- Program Close to the Problem domain. 靠近問題領域編程。
- Estimate to Avoid Surprises. 估算，以避免發生意外。
- Iterate the Schedule with the Code. 通過代碼對進度表進行迭代。
- Keep Knowledge in Plain Text. 用純文本保存知識。
- Use the Power of Command Shells. 利用命令shell的力量。
- Use a Single Editor Well. 用好一種編輯器。
- Always Use Source Code Control. 總是使用源碼控制。
- Fix the Problem, Not the Blame. 要修正問題，而不是發出指責。
- Don't Panic. 不要恐慌。
- "Select" Isn't Broken. “Select”沒有問題。
- Don’t Assume it - Prove It. 不要假定，要證明。
- Learn a Text Manipulation Language. 學習一種文本操縱語言。
- Write Code That Writes Code. 編寫能編寫代碼的代碼。
- You Can't Write Perfect Software. 你不可能寫出完美的軟件
- Design with Contracts. 通過合約進行設計。
- Crash Early. 早崩潰。
- If It can't Happen, Use Assertions to Ensure That It Won't. 如果它不可能發生，用斷言確保它不會發生。
- Use Exceptions for Exceptional Problems. 將異常用於異常的問題。
- Finish What You Start. 要有始有終。
- Minimize Coupling Between Modules. 使模塊之間的耦合減至最少。
- Configure, Don't Integrate. 要配置，不要集成。
- Put Abstractions in Code, Details in Metadata. 將抽象放進代碼，細節放進元數據。
- Analyze Workflow to Improve Concurrency. 分析工作流，以改善併發性。
- Design Using Services. 用服務進行設計。
- Always Design for Concurrency. 總是爲併發設計。
- Separate Views from Models. 使視圖與模型分離。
- Use Blackboards to Coordinate Workflow. 用黑板協調工作流。
- Don't Program by Coincidence. 不要靠巧合編程。
- Estimate the Order of Your Algorithms. 估算你的算法的階。
- Test Your Estimates. 測試你的估算。
- Refactor Early, Refactor Often. 早重構，常重構。
- Design to Test. 爲測試而設計。
- Test Your Software, or Your Users Will. 測試你的軟件，否則你的用戶就得測試。
- Don't Use Wizard Code You Don't Understand. 不要使用你不理解的嚮導代碼。
- Don't Gather Requirements - Dig for Them. 不要蒐集需求——挖掘它們。
- Work with a User to Think Like a User. 與用戶一同工作，以像用戶一樣思考。
- Abstractions Live Longer than Details. 抽象比細節活的更長久。
- Use a Project Glossary. 使用項目詞彙表。
- Don't Think Outside the Box - Find the Box. 不要在盒子外面思考——要找到盒子。
- Listen to Nagging Doubts - Start When You're Ready. 傾聽反覆出現的疑慮——等你準備好再開始.。
- Some Things Are Better Done than Described. 對有些事情“做”勝於“描述”。
- Don't Be a Slave to Formal Methods. 不要做形式方法的奴隸。
- Expensive Tools Do Not Produce Better Designs. 昂貴的工具不一定能製作出更好的設計。
- Organize Around Functionality, Not Job Functions. 圍繞功能，而不是工作職務進行組織。
- Don't Use Manual Procedures. 不要使用手工流程。
- Test Early. Test Often. Test Automatically. 早測試，常測試，自動測試。
- Coding Ain't Done, Till All the Tests Run. 要到通過全部測試，編碼纔算完成。
- Use Saboteurs to Test Your Testing. 通過“蓄意破壞”測試你的測試。
- Test State Coverage. Not Code Coverage. 測試狀態覆蓋，而不是代碼覆蓋。
- Find Bugs Once. 一個bug只抓一次。
- Treat English as Just Another Programming Language. 把英語當作又一種編程語言。
- Build Documentation In, Don't Bolt It On. 把文檔建在裏面，不要栓在外面。
- Gently Exceed Your Users' Expectations. 溫和的超出用戶的期望。
- Sign Your Work. 在你的作品上簽名。