程式員個修練之道

快速參考列表
1.關心你的技藝
Care About Your Craft
如果你不在乎能否漂亮地開發出軟體，

你又為何要耗費生命去開發軟體呢？

2.思考！你的工作
Think! About Your Work
關掉自動駕駛儀，接管操作。不斷地批評和評估你的工作。

3.提供各種選擇，不要找蹩腳的借口
Provide Options, Don't Make Lame Excuses
要提供各種選擇，而不是借口。不要說事情做不到；說明能夠做什麼。

4.不要容忍破窗戶
Don't Live with Broken Windows
當你看到糟糕的設計、錯誤的決策和糟糕的代碼時，修正他們。

5.做變化的催化劑
Be a Catalyst for Change
你不能強迫人們改變。相反，要向他們展示未來可能會怎樣，並協助他們參與對未來的創造。

6.記住大圖景
Remember the Big Picture
不要太過專註於細節，以致忘了查看你周圍正在發生什麼。

7.使品質成為需求問題
Make Quality a Requirements Issue
讓你的使用者參與確定項目真正的需求。

8.定期為你的知識資產投資
Invest Regularly in Your Konwledge Portfolio
讓學習成為習慣

9.批判的分析你讀到的和聽到的
Critically Analyze What You Read and Hear
不要被供應商、媒體炒作、或教條左右。要依照你自己的看法和你的項目的情況去對資訊進行分析。

10.你說什麼和你怎麼說同樣重要
It's Both What You Say and the Way You Say It
如果你不能有效地向他人傳遞你的了不起的想法，這些想法就毫無用處。

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 When Debuging
做一次深呼吸，思考什麼可能是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 Impossisble
斷言驗證你的各種假定。在一個不確定的世界裡，用斷言保護你的代碼。

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 in Metadata
為一般情況編程，將細節放在被編譯的程式碼程式庫之外。

39.分析工作流程，以改善並發性
Analyze Workflow to Improve Concurrency
利用你的使用者的工作流程中的並發性。

40.用服務進行設計
Design Using Services
根據服務——獨立的、在良好定義、一致的介面之後的並發對象——進行設計。

41.總是為並發進行設計
Always Design for Concurrency
容許並發，你將會設計出更整潔、具有更少假定的介面。

42.視圖與模型分離
Separate Views form 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 Slave 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 didn’t Done Until 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
像你編寫代碼一樣編寫文檔：遵守DIY原則、使用原資料、MVC、自動產生，等等。

68.把文檔建在裡面，不要拴在外面
Build Documentation In, Don’t Bolt It On
與代碼分離的文檔不太可能被修整和更新。

69. 溫和地超出使用者的期望
Gently Exceed Your Users’ Expectations
要理解你的使用者的期望，然後給他們的東西要多那麼一點。

70.在你的作品上籤名
Sign Your Work
過去時代的手工藝人為能在他們的作品上籤名而自豪。一夜應該如此。

檢查清單

71.要學習的語言
厭倦了C、C++和JAVA?試試CLOS、Dylan、Eiffel、Objective C、Prolog、Smalltalk或TOM。他們每一種都有不同的能力和不同的“風味”。用其中的一種或多種語言在家裡開發一個小項目。

72.WISDOM離合詩
What do you want them to learn? 你想讓他們學到什嗎？
What is their interest in what you’ve got to 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? 你如何使他們聽你說話？

73.怎樣維持正交性
設計獨立、良好定義的組建。
使你的代碼保持解藕
避免使用全域資料
重構相似的函數

74.應製作原型的事物
構架
已有系統的新功能
外部資料的結構或內容
第三方工具或組建
效能問題
使用者介面設計

75.架構問題
責任是否得到了良好定義？
寫作是否得到了良好定義？
耦合是否得以最小化？
你能否確定潛在的重複？
介面定義和各項約束是否可以接受？
模組能否在需要時訪問所需資料？

76.調試檢查清單
正在報告的問題是底層bug的直接結果，還是只是癥狀？
Bug真的在編譯器裡？在OS裡?或者是在你的代碼裡？
如果你向同事詳細解釋這個問題，你會說什嗎？
如果可以代碼通過了單元測試，測試是否足夠完整？如果你用該資料單元測試，會發生什嗎？
造成這個bug的條件是否存在於系統的其他任何地方？

77.函數的得墨忒耳法則
某個對象的方法應該值調用屬於以下情形的方法：
它自身
傳入的任何參數
它建立的對象
組件對象

78.怎樣深思熟慮地編程
總是意識到你在做什麼
不要盲目地編程
按照計划行事
依靠可靠的事物
為你的假定建立文檔
不要只是測試你的代碼，還要測試你的假定
為你的工作劃分優先順序
不要做曆史的奴隸

79.何時進行重構
你發現了對DRY原則的違反
你發現事物可以更為正交
你的知識擴充了
需求演變了
你需要改善效能

80.劈開戈爾迪斯結
在解決不可能解決的問題時，問問自己：
有更容易的方法嗎？
我是在解決正確的問題嗎？
這件事情為什麼是一個問題？
是什麼使它如此難以解決？
它必須以這種方式完成嗎？
它真的必須完成嗎？

81.測試的各個方面
單元測試
整合測試
驗證和校正
資源耗盡、錯誤及恢複
效能測試
可用性測試