關於正交性：如果兩個或多個事物中的一個發生變化，不會影響到其他事物，這些實物就是正交的。必須要消除無關事物之間的影響。正交還能促進複用，組件如果有具體、良好的定義的責任，就易於與新組件組合在一起，且得到的結果往往不是M+N，而是M×N。 從初期就要做好規範,不要因爲是poc這樣的前提而放鬆對代碼的規範,現在的項目就
有這種問題,初期的時候有人認爲(自己也有這種想法)等到以後正式開發的時候再規範
,而往往還未到正式開發,到處出現不規範的東西.加上拷貝粘貼的大法,亡羊補牢都晚
了.這就是所謂破窗戶理論.
1. 關心你的技藝
Care About Your Craft
如果你不在乎能否溧亮地開發出軟件，你又爲何要耗費生命去開發軟件呢？
2. 思考！你的工作
Think! About Your Work
關掉自動架駛儀，接管操作，不斷地批評和評估你的工作
3. 提供各種選擇，不要找蹩腳的藉口
Provide Options, Don't Make Lame Excuses
要提供各種選擇，而不是找藉口不要說事情做不到；說明能夠做什麼
4. 不要容忍破窗戶
Don’t Live with BrokenWindows
當你看到糟糕的設計、錯誤的決策和糟糕的代碼時.修正它們
5. 做變化的催化劑
Be a Catalyst for Change
你不能強迫人們改變相反，要向他們展示未來可能會怎柞，並-幫助他們參與對來來的創造
6. 記住大圖景
Remember the Big Picture
不要人過專注於細節,以致忘了查看你周圍正在發生什麼
7. 使質量成爲需求問題
Make Quality a Requirements Issue
讓你的用戶參與確定項目真正的質量需求
8. 定期爲你的知識資產投資
Invest Regularly in Your Knowledge Portfolio
讓學習成爲習慣
9. 批判地分析你讀到的和聽到的
Critically Analyze What You Read and Hear
不要被供應商、媒體炒作、或教條左右要依照你自己的看法和你的項目的情況去對信息進行分析
10. 你說什麼和你怎麼說同樣重要
It’s Both What You Say and the Way You SayIt
如過你不能有效地向他人傳達你的了不起的想法，這些想法就毫無用處
11. 不要重複你自己
DRY – Don’t Repeat Yourself
系統中的每一項知識都必須具有單一、無歧義，權威的表示
12. 讓複用變得容易
Make It Easy to Reuse
如果複用很容易，人們就會去複用創造一個個支持複用的外境
13. 消除無關事物之間的影響
Eliminate Effects Between Unrelated Things
設計自足，獨立，並且巨湧單一、良好定義的組件
14. 不存在最終決策
There Are No Final Decisions
沒有決策是澆築在石頭上的相反，要把每項決策都視爲是寫在沙灘上的，併爲變化做好計劃。
15. 用曳光彈找到目標
Use Tracer Bullets to Find the Target
曳光彈能通過實驗各種事物並檢杳它們離目標有多遠來讓你追蹤目標
16. 爲了學習而製作原型
Prototype to Learn
原型製作是一種學習經驗其價值並不在於所產生的代碼，而在於所學到的經驗教訓
17. 靠近問題領域編程
Program Close to the Problem domain
用你的用戶的語言進行設計和編碼
18. 估算，以避免發生意外
Estimate to Avoid Surprises
在着手之前先進行估算你將提前發現潛在的問題
19. 通過代碼對進度表進行迭代
Iterate the Schedule with the Code
用你在進行實現時獲得的經驗提煉項目的時間標度
20. 用純文本保存知識
Keep Knowledge in Plain Text
純文木不會過時它能夠幫助你有效利用你的工作.並簡化調試和測試。
21. 利用命令shell的力量
Use the Power of Command Shells
當圖形用戶界面無能爲力時使用shell
22. 用好一種編輯器
Use a Single Editor Well
編輯器應該是你的手的延伸；確保你的編輯器是可配置、可擴展和可編程的
23. 總是使用源碼控制
Always Use Source Code Control
源碼控制是你的工作的時間機器——你能夠回到過去
24. 要修正問題，而不是發出指責
Fix the Problem, Not the Blame
bug是你的過錯還是別人的過錯，並不是真的很有關係—它仍然是你的問題.它仍然耑要修正
25. 調試時不要恐慌
Don’t Panic WhenDebuging
做一次深呼吸，思考什麼可能是bug的原因
26. “Select” 沒有問題
"Select" Isn’t Broken
在OS或編澤器、甚或是第三方產品或庫中很少發觀bug bug很可能在應用中
27. 不要假定，要證明
Don't Assume It - Prove It
在實際環境屮——使用真的數據和邊界條件——證明你的假定
28. 學習一種文本操縱語言
Learn a Text Manipulation Language
你用每日按的的很大一郃分時間來處理本.爲什麼不讓計算機替你完成部分工作?
29. 編寫能編寫代碼的代碼
Write Code That Writes Code
代碼生成器能提高你的生產率.並有助於避免重複
30. 你不可能寫出完美的軟件
You Can’t Write Perfect Software
軟件不可能完美保護你的代碼和用戶.使它(他）們免於能夠預見的錯誤。
31. 通過合約進行設計
Design with Contracts
使用合約建立文檔. 並檢驗代碼所做的事情正好是它聲明要做的。
32. 早崩潰
Crash Early
死程序造成的危害通常比有問題的程序要小得多
33. 用斷言避免不可能發生的事情
Use Assertions to Prevent the Impossible
斷言驗證你的各種假定，在一個不確定的世界裏，用斷言保護你的代碼。
34. 將異常用於異常的問題
Use Exceptions for Exceptional Problems
異常可能會遭受涇典的意大利麪條式代碼的所有可讀性和可維護性問題的折磨。將異常保留給異常的事物
35. 要有始有終
Finish What You Start
只要可能，分配某資源的例程或對象也應該負責解除分配
36. 使模塊之間的耦合減至最少
Minimize Coupling Between Modules
通過編寫“羞怯的”代碼並應用用得墨忒耳法則來避免稱合
37. 要配置，不要集成
Configure, Don't Integrate
要將應用的各種技術選擇實現爲配置選項，而不是通過集成或工程方法實現
38. 將抽象放進代碼，細節放進元數據
Put Abstractions in Code, Details inMetadata
爲一般情況編程.將細節放在被編譯的代碼庫之外
39. 分析工作流，以改善併發性
Analyze Workflow to Improve Concurrency
利用你的用戶的工作流中的併發性
40. 用服務進行設計
Design Using Services
根據服務——獨立的、在良好定義，一致的接口之後的併發對象——進行設計
41. 總是爲併發進行設計
Always Design for Concurrency
容許併發，你將會設計出更整潔、具有更少假定的接口。
42. 使視圖與模型分離
Separate Views from Models
要根據模型和視圖設計你的應用，從而以低廉的代碼獲取靈活性
43. 用黑板協調工作流
Use Blackboards to Coordinate Workflow
用黑板協調完全不同的事實和因素，同時又使各參與方保持獨立和隔離
44. 不要靠巧合編程
Don't Program by Coincidence
只依靠可靠的事物注意偶發的複雜性，不要把幸運的巧合與有目的的計劃混爲一談
45. 估算你的算法的階
Estimate the Order of Your Algorithms
在你編寫代碼之前，先大致估算事情需要多長時間
46. 測試你的估算
Test Your Estimates
對算法的數學分析許不會告訴你每一件事情在你的代碼的目標環境中測記它的速度
47. 早重構，常重構
Refactor Early, Refactor Often
就和你會在花園裏除草、並重新佈置一樣.在需要時對代碼進行重寫、重做和重新架構要剷除問題的根源。
48. 爲測試而設計
Design to Test
在你還沒行編寫代媽時就開始思考測試問題
49. 測試你的軟件，否則你的用戶就得測試
Test Your Software, or Your Users Will
無情地測試不要讓你的用戶爲你查找bug
50. 不要使用你不理解的嚮導代碼
Don't Use Wizard Code You Don’t Understand
嚮導可以生成代碼在你把它們合併進你的項目之前，確保你理解全部這些代碼
51. 不要蒐集需求一一挖掘它們
Don't Gather Requirements - Dig for Them
需求很少存在於表面上它們深深地埋藏在層層假定.誤解和政治手段的下面
52. 與用戶一同工作，以像用戶一樣思考
Work with a User to Think Like a User
要了解系統實際上將如何被使用，這是最好的方法
53. 抽象比細節活得更長久
Abstractions Live Longer than Details
“投資”於抽象，而不適實現拙象能在來自自不同的實現和新技術的變化的“攻出”之下存活下去
54. 使用項目詞彙表
Use a Project Glossary
創建並維護項目中使用的專用術語和詞彙的單一信息源
55. 不要在盒子外面思考——要找到盒子
Don’t Think Outside the Box – Find the Box
在遇到不可能解決的問題時，要確定真正的約束問問你自己：必須以這種方式完成嗎？它真的必須完成嗎？”
56. 等你準備好再開始
Start When You're Ready
你的一生都在積累經驗、不要忽視反覆出現的疑慮
57. 對有些事情“做”勝於“描述”
Some Things Are Better Done than Described
不要掉進規範的螺旋——在某個吋刻,你需要開始編碼.
58. 不要做形式方法的奴隸
Don't Be a Stave to Formal Methods
如果你沒有把某項技術放進你的開發實踐和能力的語境中，不要盲目地採用它.
59. 昂貴的工具不一定能製作出更好的設計
Costly Tools Don't Produce Better Designs
小心供應商的炒作.行業教條、以及價格標籤的誘惑。要根據工具的價值判斷它們，
60. 圍繞功能組織團隊
Organize Teams Around Functionality
不要把設計師與編碼員分開.也不要把測試員與數據建模分開按照你構建代碼
的方式構建團隊.
61. 不要使用手工流程
Don’t Use Manual Procedures
shell腳本或批文件會一次次地以同一順序執行同樣的指令
62. 早測試，常測試，自動測試。
Test Early. Test Often. Test Automatically
與呆在暑假上的的測試計劃相比，每次構建時運行的測試要有效得多
63. 要到通過全部測試，編碼纔算完成
Coding Ain’t Done ‘Til All the Tests Run
就是這樣
64. 通過“蓄意破壞”測試你的測試
Use Saboteurs to Test Your Testing
在單獨的軟件副本上故意引入bug，以檢驗測試能夠抓住它們
65. 測試狀態覆蓋，而不是代碼覆蓋
Test State Coverage, Not Code Coverage
確定並測試重要的程序狀態，只是測試代碼行是不夠的，
66. 一個bug只抓一次
Find Bugs Once
一曰測試員找到一個bug,這應該是測試員最後一次找到它。此後自動測試應該對其進行檢查
67. 英語就是一種編程語言
English is Just a Programming Language
像你編寫代碼一樣編寫文檔：遵守原則、使用元數據、MVC、自動生成，等等
68. 把文檔建在裏面，不要拴在外面
Build Documentation In, Don’t Bolt It On
與代碼分離的文檔不太可能被修正和更新。
69. 溫和地超出用戶的期望
Gently Exceed Your Users' Expectations
要解你的用戶的期望，然後給他們的東西要多那麼一點
在你的作品上簽名
Sign Your Work
過去時代的手藝人爲能在他們的作品上簽名而自豪、你也成該如此
檢査清單
要學習的語言
厭倦了C ,C++和 JAVA？試試 CLOS、Dylan、Eiffel .Objective C, Prolog .Smalltalk
或TOM它們每一種都有不同的能力和不同的“風味”。用其中的一種或多種語言在
家裏開發一個小項目
71. WISDOM離合詩
What do you want them to learn?
What is their interest in what you've gotto say?
How sophisticated are they?
How much detail do they want?
Whom do you want to own the information?
How can you motivate them to listen to you?
你想讓他們學到什麼？
他們對你講的什麼感興趣?
他們有多富有經驗？
他們想要多少細節_?
你想要讓誰擁有這些信息?
你如何促使他們聽你說話?
72. 怎樣維持正交性 34頁
•設計獨立良好定義的組件…
•便你的代碼保持解藕
避免使用全局數據
•重構相似的函數，
73. 應制作原型的事物 53頁
•架構
•已有系統中的新功能
332
•外部數據的結構或內容
第三方工具或組件
性能問題
用戶界面設計
74. 架構問題 55頁
•責任是否得到了良好定義？
協作是否得到了良好定義
耦合是否得以最小化？
•你能否確定潛在的重複？
•接口定義和各項約束是否可接受？
•模塊能否在耑要時訪問所需數據？
75. 調試檢查清單 98頁
•正在報告的問題是底層bug的直接結果，還是隻是症狀？
•bug真的在編譯器裏？在OS裏？或者是在你的代碼裏？
•如果你向同事詳細解釋這個問題，你會說什麼？
•如果可疑代碼通過了單元測試，測試是否足夠完整？
如果你用該數據運行單元測試，會發生什麼?
*造成這個bug的條件是否存在子系統中的其他仟何地力？
76. 函數的得墨忒耳法則 141頁
某個對象的方法應該只調用屬於以下情形的方法：
•它自身
•傳人的任何參數
•它創建的對象
•組件對象
77. 怎樣深思熟慮地編程 172頁
*總是意識到你在做什麼
•不要盲目地編程
•按照計劃行事
•依靠可靠的事物
•爲你的假定建立檔
•不要只是測試你的代碼，還要測試你的假定
•爲你的計作劃分優先級，
•不要做歷史的奴隸
78. 何時進行重構 185頁
*你發現看對DRY原則的違反
你發現事物可以更爲正交
*你的知識擴展了
•需求演變了
•你需要改善件能
79. 劈開戈爾迪斯結 212頁
在解決不可能解決的問題時，問問你自己：
•有更容易的方法叫？
•我是在解決正確的問題嗎？
•這件事情爲什麼是一個問題？
•是什麼使它如此難以解決？
•它必須以這種方式完成嗎？
•它真的必須完成嗎？
80. 測試的各個方面 237頁
•但願測試
•集成測試
•驗證和校驗
•資源耗盡、錯誤及恢復
•性能測試
•可用性測試
•對測試自身進行測試