《程序員修煉之道》- 注重實效的參考指南

終於讀完了《程序員修煉之道》，全書圍繞注重實效的程序員展開思考，逐步分析了開發中須要遵照的準則。本文記錄其中一些指南。

原文

一、關心你的技藝

Care About Your Work
若是你不在意可否漂亮地開發出軟件，你又爲什麼要耗費生命區開發軟件呢？

二、思考！你的工做

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 Requirement 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
系統中的每一項知識都必須具備單1、無歧義、權威的表示。

十二、讓複用變得容易

Make It Easy to Reuse
若是複用很容易，人們就回去複用。創造一個支持複用的環境。

1三、消除無關事物之間的影響

Eliminate Effects Between Unrelated Things
設計自足、獨立、並具備單1、良好定義的目的組件。

1四、不存在最終的決定

There Are No Final Decisions
沒有決策是澆鑄在石頭上的。相反，要把每項決策都視爲是寫在沙灘上的，併爲變化作好計劃。

1五、用曳光彈找到目標

Use Tracer Bullets to Find the Target
曳光彈能經過試驗各類事物並檢查它們離目標有多遠來讓你追蹤目標。

1六、爲了學習而製做原型

Prototype to Learn
原型製做是一種學習經驗。其價值並不在於所產生的代碼，而在於所學到的經驗教訓。

1七、靠近問題編程

Program Close to the Problem Domain
用你的用戶的語言進行設計和編碼。

1八、估算，以免發生意外

Estimate to Avoid Surprises
在着手以前先進行估量。你將提早發現潛在的問題。

1九、經過代碼對進度進行迭代

Iterate the Schedule with the Code
用你在進行實現時得到的經驗提煉項目的時間標度。

20、使用純文本保存知識

Keep Knowledge in Plain Text
純文本不會過期。它可以幫助你有效利用你的工做，並簡化調試和測試。

2一、利用命令shell的力量

Use the Power of Command Shells
當圖形用戶界面無能爲力時使用shell。

2二、用好一種編輯器

Use a single Editor well
編輯器應該是你的手的延伸；確保你的編輯器是可配置、可拓展和可編程的。

2三、老是使用源碼控制

Always Use Source Code Control
源碼控制是你的工做的時間機器————你可以回到過去。

2四、要修正問題，而不是發出指責

Fix the Problem,Not the Blame
bug是你的過錯仍是別人的過錯，並非真的頗有關係————它仍然是你的問題，它仍然須要修正。

2五、不要驚慌

Don't Panic When Debuging
作一次深呼吸，思考什麼多是bug的緣由。

2六、「Select」沒有問題

"Select"Isn't Broken
在OS或編譯器、甚或是第三方產品或庫中不多發現bug。bug極可能在應用中。

2七、不要假定，要證實

Don't Assume it - Prove it
在實際環境中————使用真正的數據和邊界條件————證實你的假定。

2八、學習一種文本操縱語言

Learn a Text Manipulation language
你用天天的很大一部分事件處理文本，爲何不讓計算機替你完成部分工做呢？

2九、編寫能編寫代碼的代碼

Write Code the Writes Code
代碼生成器能提升你的生產率，並有助於避免重複。

30、你不可能寫出完美的軟件

You Can't Write Perfect Software
軟件不可能完美。保護你的代碼和用戶，使他們免於可以預見的錯誤。

3一、經過合約進行設計

Design with Contracts
使用合約創建文檔，並檢驗代碼所作的事情正好是它聲明要作的。

3二、早崩潰

Crash Early
死程序形成的危害一般比有問題的程序要小得多。

3三、用斷言避免不可能發生的事情

Use Assertions to Prevent the Impossible
斷言驗證你的各類假定。在一個不肯定的世界裏，用斷言保護你的代碼。

3四、將異經常使用於異常的問題

Use Exceptions for Exceptional Problems
異常可能會遭受經典的意大利麪條式代碼的全部可讀性和可維護性爲題的折磨。將異常保留給異常的事物。

3五、要善始善終

Finish What You Start
只要可能，分配某資源的例程或對象也應該負責解除其分配。

3六、使模塊之間的耦合減至最少

Minimize Coupling Between Modules
經過編寫「羞怯的」代碼並應用得墨忒耳法則來避免耦合。

3七、要配置，不要集成

Configure, Don't Integrate
要將應用的各類技術選擇實現爲配置選項，而不是經過集成或工程方法實現。

3八、將抽象放進代碼，細節放進元數據

Put Abstractions in Code ,Details in Metadata
爲通常狀況編程，將細節放在被編譯的代碼庫以外。

3九、分析工做流，以改善併發性

Analyze Workflow to Improve Concurrency
利用你的用戶的工做流中的併發性。

40、用服務進行設計

Design Using Services
根據服務————獨立的、在良好定義、一致的接口以後的併發對象————進行設計。

4一、老是爲併發進行設計

Always Design for Concurrency
允許併發，你將會設計出更整潔、具備更少假定的接口。

4二、使視圖與模型分離

Separate Views from Models
要根據模型和視圖設計你的應用，從而以低廉的代碼獲取靈活性。

4三、用黑板協調工做流

Use BlackBoards to Coordinate Workflow
用黑板協調完成不一樣的事實和因素，同時又使各參與方保持獨立和隔離。

4四、不要靠巧合編程

Don't Program by Coincidence
只依靠可靠的事物。注意偶發的複雜性，不要把幸運的巧合與有目的的計劃混爲一談。

4五、估算你的算法的階

Estimate the Order of Your Algorithms
在你編寫代碼以前，先大體估算事情須要多長時間。

4六、測試你的估算

Test Your Estimates
對算法的數學分析並不會告訴你每一件事情。在你的代碼的目標環境中測定它的速度。

4七、早重構，常重構

Refactor Early,Refactor Often
就和你會在花園裏除草】並從新佈置同樣，在須要時對代碼進行重寫、重作和從新架構。要剷除問題的根源。

4八、爲測試而設計

Design to Test
在你尚未編寫代碼時就開始思考測試問題。

4九、測試你的軟件，不然你的用戶就得測試

Test Your Software,ou Your Users Will
無情地測試。不要讓你的用戶爲你查找bug。

50、不要使用你不理解的嚮導代碼

Don't Use Wizard Code You Don't Understand
嚮導能夠生成大量代碼。在你把它們合併進你的項目以前，確保你理解所有這些代碼。

5一、不要蒐集需求——挖掘它們

Don't Gather Requirements - Dig for Them
需求不多存在於表面上。它們深深地埋藏在層層假定、誤解和政治手段的下面。

5二、與用戶一同工做，以像用戶同樣思考

Work with a User to Think Like a User
要了解系統實際上將如何被使用，這是最好的方法。

5三、抽象比細節活得更長久

Abstractions Live Longer than Details
「投資」於抽象，而不是實現。抽象能在來自不一樣的實現和新技術的變化的「攻擊」之下存活下去。

5四、使用項目詞彙表

Use a Project Glossary
建立並維護項目中使用的專用術語和詞彙的單一信息源。

5五、不要在盒子外思考——要找到盒子

Don't Think Outside the Box-Find the Box
在遇到不可能解決的問題時，要肯定真正的約束。問問你本身：「它必須以這種方式完成嗎？它真的必須完成嗎？」

5六、等你準備好再開始

Start What You're Ready
你的一輩子都在積累經驗。不要忽視反覆出現的疑慮。

5七、對有些事情"作"勝於"描述"

Same Things Are better Done than Described
不要掉進規範的螺旋————在某個時刻，你須要開始編碼。

5八、不要作形象方式的奴隸

Don't be Slave to Formal Methods
若是你沒有把某項技術放進你的開發實踐和能力的語境中，不要盲目地採用它。

5九、昂貴的工具不必定能製做出更好的設計

Costly Tools Dont't Produce Better Designs
當心供應商的炒做，行業教條、以及價格標籤的誘惑。要根據工具的價值判斷它們。

60、圍繞功能組織團隊

Organize Teams Around Functionality
不要吧設計師與編碼員分開，也不要把測試員與數據建模員分開。按照你構建代碼的方式構建團隊。

6一、不要使用手工流程

Don't Use Manual Procedures
shell腳本或批文件會一次次地以同一順序執行一樣的指令。

6二、早測試，常測試，自動測試

Test Early.Test Often.Test Automatically
與呆在書架上的測試計劃相比，每次構建時運行的測試要有效得多。

6三、要到經過所有測試，編碼纔算完成

Coding Ain't Done 'Til All the Tests Run
就是這樣。

6四、經過「蓄意破壞」測試你的測試

Use Saboteurs to Test Your Testing
在單獨的軟件副本上故意引入bug，以檢驗測試可以抓住它們。

6五、測試狀態覆蓋，而不是代碼覆蓋

Test State Coverage,Not Code Coverage
肯定並測試重要的程序狀態。只是測試代碼行是不夠的。

6六、一個bug只爪一次

Find Bugs Once
一旦測試員找到一個bug，這應該是測試員最後一次找到它。此後自動測試應該對其進行檢查。

6七、把英語當成又一種編程語言

English is Just a Programming Language
像你編寫代碼同樣編寫文檔：遵照DRY原則、使用元數據、MVC、自動生成，等等。

6八、把文檔建在裏面，不要栓在外面

Build Documentation In ,Don't Bolt It On
與代碼分離的文檔不太可能被修正和更新。

6九、溫和地超出用戶的指望

Gently Exceed Your User's Expectations要理解你的用戶的指望，而後給他們的東西要多那麼一點。70、在你的做品上簽名Sign Your Work過去時代的手藝人爲能在他們的做品上簽名而自豪。你也應該如此。