Pragmatic Software Development Tips
務實的軟件開發提示

Care About Your Craft
Why spend your life developing software unless you care about doing it well?

關心你的技藝
如果你不在乎能否漂亮地開發出軟件，你又為何要耗費生命去開發軟件呢？

Provide Options, Don’t Make Lame Excuses
Instead of excuses, provide options. Don’t say it can’t be done; explain what can be done.

提供各種選擇，不要找蹩腳的借口
提供各種選擇，不是找借口。不要說事情做不到；說明能夠做什麽。

Be a Catalyst for Change
You can’t force change on people. Instead, show them how the future might be and help them participate in creating it.

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

Make Quality a Requirements Issue
Involve your users in determining the project’s real quality requirements.

使質量成為需求問題
讓你的用戶參與確定項目真正的質量需求。

Critically Analyze What You Read and Hear
Don’t be swayed by vendors, media hype, or dogma. Analyze information in terms of you and your project.

批判分析你讀到的和聽到的
不要被供應商、媒體炒作、或教條左右。要依照你自己的看法和你的項目的情況去對信息進行分析。

DRY—Don’t Repeat Yourself
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

不要重復你自己
系統中的每一項知識都必須具有單一、無歧義、權威的表示。

Eliminate Effects Between Unrelated Things
Design components that are self-contained, independent, and have a single, well-defined purpose.

消除無關事物之間的影響
設計自足、獨立、並具有單一、良好定義的目的的組件。

Use Tracer Bullets to Find the Target
Tracer bullets let you home in on your target by trying things and seeing how close they land.

使用曳光彈找到目標
曳光彈能通過試驗各種事物並檢查它們距離目標有多遠來讓你追蹤目標。

Program Close to the Problem Domain
Design and code in your user’s language.

靠近問題領域編程
用你的用戶的語言進行設計和編碼。

Iterate the Schedule with the Code
Use experience you gain as you implement to refine the project time scales.

通過代碼對進度表進行叠代
用你在進行實現時獲得的經驗提煉項目的時間標度。

Use the Power of Command Shells
Use the shell when graphical user interfaces don’t cut it.

利用命令shell的力量
當圖形用戶界面無能為力時使用 shell 。

Always Use Source Code Control
Source code control is a time machine for your work—you can go back.

總是使用源碼控制
源碼控制是你的工作的時間機器 —— 你能夠回到過去。

Don’t Panic When Debugging
Take a deep breath and THINK! about what could be causing the bug.

調試時不要恐慌
做一次深呼吸，思考！什麽可能是 bug 的原因。

Don’t Assume It—Prove It
Prove your assumptions in the actual environment—with real data and boundary conditions.

不要假定，要證明
在實際環境中——使用真正的數據和邊界條件——證明你的假定。

Write Code That Writes Code
Code generators increase your productivity and help avoid duplication.

編寫能編寫代碼的代碼
代碼生成器能提高你的生產率，並有助於避免重復。

Design with Contracts
Use contracts to document and verify that code does no more and no less than it claims to do.

通過合約進行設計
使用合約建立文檔，並檢驗代碼所做的事情正好是它聲明要做的。

Use Assertions to Prevent the Impossible
Assertions validate your assumptions. Use them to protect your code from an uncertain world.

用斷言避免不可能發生的事情
斷言驗證你的各種假定。在一個不確定的世界裏，用斷言保護你的代碼。

Finish What You Start
Where possible, the routine or object that allocates a resource should be responsible for deallocating it.

要有始有終
只要可能，分配某資源的例程或對象也應該負責解除其分配。

Configure, Don’t Integrate
Implement technology choices for an application as configuration options, not through integration or engineering.

要配置，不要集成
要將應用的各種技術選擇實現為配置選項，而不是通過集成或工程的方法實現。

Analyze Workflow to Improve Concurrency
Exploit concurrency in your user’s workflow.

分析工作流，以改善並發性
利用你的用戶的工作流中的並發性。

Always Design for Concurrency
Allow for concurrency, and you’ll design cleaner interfaces with fewer assumptions.

總是為並發進行設計
容許並發，你將會設計出更整潔、具有更少假定的接口。

Use Blackboards to Coordinate Workflow
Use blackboards to coordinate disparate facts and agents, while maintaining independence and isolation among participants.

使用黑板協調工作流
用黑板協調完全不同的事實和因素，同時又使各參與方保持獨立和隔離。

Estimate the Order of Your Algorithms
Get a feel for how long things are likely to take before you write code.

估算你的算法的階
在你編寫代碼之前，先大致估算事情需要多長時間。

Refactor Early, Refactor Often
Just as you might weed and rearrange a garden, rewrite, rework, and re-architect code when it needs it. Fix the root of the problem.

早重構，常重構
就和你會在花園裏除草、並重新布置一樣，在需要時對代碼進行重寫、重做和重新架構。要鏟除問題的根源。

Test Your Software, or Your Users Will
Test ruthlessly. Don’t make your users find bugs for you.

測試你的軟件，否則你的用戶就得測試
無情地測試。不要讓你的用戶為你尋找 bug 。

Don’t Gather Requirements—Dig for Them
Requirements rarely lie on the surface. They’re buried deep beneath layers of assumptions, misconceptions, and politics.

不要搜集需求 —— 挖掘它們
需求很少存在於表面上。它們深深地埋藏在層層假定、誤解和政治手段的下面。

Abstractions Live Longer than Details
Invest in the abstraction, not the implementation. Abstractions can survive the barrage of changes from different implementations and new technologies.

抽象比細節獲得更長久
“投資”於抽象，而不是實現。抽象能在來自不同的實現和新技術的變化的“攻擊”之下存活下去。

Don’t Think Outside the Box—Find the Box
When faced with an impossible problem, identify the real constraints. Ask yourself: “Does it have to be done this way? Does it have to be done at all?”

不要在盒子外面思考 —— 要找到盒子
在遇到不能解決的問題時，要確定真正的約束。問問自己：“它必須以這種方式完成嗎？它真的必須完成嗎？”

Some Things Are Better Done than Described
Don’t fall into the specification spiral—at some point you need to start coding.

對有些事情“做”勝於“描述”
不要掉進規範的螺旋 —— 在某時刻，你需要開始編碼。

Costly Tools Don’t Produce Better Designs
Beware of vendor hype, industry dogma, and the aura of the price tag. Judge tools on their merits.

昂貴的工具不一定能制作出更好的設計
小心供應商的炒作、行業教條、以及價格標簽的誘惑。要根據工具的價值判斷它們。

Don’t Use Manual Procedures
A shell script or batch file will execute the same instructions, in the same order, time after time.

不要使用手工流程
shell腳本或batch文件會一次次地以同一順序執行同樣的指令。

Coding Ain’t Done ‘Til All the Tests Run
‘Nuff said.

要到通過全部測試，編碼才算完成
就是這樣。

Test State Coverage, Not Code Coverage
Identify and test significant program states. Just testing lines of code isn’t enough.

測試狀態覆蓋，而不是代碼覆蓋
確定並測試重要的程序狀態。只是測試代碼行是不夠的。

English is Just a Programming Language
Write documents as you would write code: honor the DRY principle, use metadata, MVC, automatic generation, and so on.

英語就是一種編程語言
像你編寫代碼一樣編寫文檔：遵守DRY(Don’t Repeat Yourself)原則、使用元數據、MVC(Model–View–Controller)、自動生成，等等

Gently Exceed Your Users’ Expectations
Come to understand your users’ expectations, then deliver just that little bit more.

溫和超出用戶的期望
要理解你的用戶的期望，然後給他們的東西要多那麽一點。

Think! About Your Work
Turn off the autopilot and take control. Constantly critique and appraise your work.

思考！你的工作
關掉自動駕駛儀，接管操作。不斷地批評和評估你的工作。

Don’t Live with Broken Windows
Fix bad designs, wrong decisions, and poor code when you see them.

不要容忍破窗戶
當你看到糟糕的設計、錯誤的決策和糟糕的代碼時，修正它們。

Remember the Big Picture
Don’t get so engrossed in the details that you forget to check what’s happening around you.

記住大圖景
不要太過專註於細節，以至忘了查看你周圍正在發生什麽。

Invest Regularly in Your Knowledge Portfolio
Make learning a habit.

定期為你的知識資產投資
讓學習成為習慣。

It’s Both What You Say and the Way You Say It
There’s no point in having great ideas if you don’t communicate them effectively.

你說什麽和你怎麽說同樣重要
如果你不能有效地向他人傳達你的了不起的想法，這些想法就毫無用處。

Make It Easy to Reuse
If it’s easy to reuse, people will. Create an environment that supports reuse.

讓復用變得容易
如果復用很容易，人們就會去復用。創造一個支持復用的環境。

There Are No Final Decisions
No decision is cast in stone. Instead, consider each as being written in the sand at the beach, and plan for change.

不存在最終決定
沒有決定是澆鑄到石頭上的。相反，要把每項決策都視為是寫在沙灘上的，並為變化做好計劃。

Prototype to Learn
Prototyping is a learning experience. Its value lies not in the code you produce, but in the lessons you learn.

為了學習而制作模型
原型制作是一種學習經驗。其價值不在於所產生的代碼，而在於所學到的經驗教訓。

Estimate to Avoid Surprises
Estimate before you start. You’ll spot potential problems up front.

估算，以避免發生意外
在著手之前先進行估算。你將提前發現潛在的問題。

Keep Knowledge in Plain Text
Plain text won’t become obsolete. It helps leverage your work and simplifies debugging and testing.

用純文本保存知識
純文本不會過時。它能夠幫助你有效利用你的工作，並簡化調試和測試。

Use a Single Editor Well
The editor should be an extension of your hand; make sure your editor is configurable, extensible, and programmable.

用好一種編輯器
編輯器應該是你的手的延伸；確保你的編輯器是可配置、可擴展的和可編程的。

Fix the Problem, Not the Blame
It doesn’t really matter whether the bug is your fault or someone else’s—it is still your problem, and it still needs to be fixed.

要修正問題，而不是發出指責
bug是你的過錯還是別人的過錯，並不是真的很有關系 —— 它仍然是你的問題，它仍然需要修正。

“select” Isn’t Broken
It is rare to find a bug in the OS or the compiler, or even a third-party product or library. The bug is most likely in the application.

“select” 沒有問題
在OS或編譯器、甚或是第三方產品或庫中，很少發現bug。bug很可能在應用中。

Learn a Text Manipulation Language
You spend a large part of each day working with text. Why not have the computer do some of it for you?

學習一種文本操縱語言
你用每天的很大一部分時間處理文本，為什麽不讓計算機替你完成其中的部分工作呢？

You Can’t Write Perfect Software
Software can’t be perfect. Protect your code and users from the inevitable errors.

你不可能寫出完美的軟件
軟件不可能完美。保護你的代碼和用戶，使它（他）們免於能夠預見的錯誤。

Crash Early
A dead program normally does a lot less damage than a crippled one.

早崩潰
死程序造成的危害通常比有問題的程序要小得多。

Use Exceptions for Exceptional Problems
Exceptions can suffer from all the readability and maintainability problems of classic spaghetti code. Reserve exceptions for exceptional things.

將異常用於異常問題
異常可能會遭受經典的意大利面條式代碼的所有可讀性和可維護性問題的折磨。將異常保留給異常的事物。

Minimize Coupling Between Modules
Avoid coupling by writing “shy” code and applying the Law of Demeter.

使模塊之間的耦合減至最小
通過編寫“羞怯的”代碼並應用得墨忒耳法則來避免耦合。

Put Abstractions in Code, Details in Metadata
Program for the general case, and put the specifics outside the compiled code base.

將抽象放進代碼，細節放進元數據
為一般情況編程，將細節放在被編譯的代碼庫之外。

Design Using Services
Design in terms of services—independent, concurrent objects behind well-defined, consistent interfaces.

用服務進行設計
根據服務（良好定義的、一致的接口之後的獨立的並發對象）進行設計。

Separate Views from Models
Gain flexibility at low cost by designing your application in terms of models and views.

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

Don’t Program by Coincidence
Rely only on reliable things. Beware of accidental complexity, and don’t confuse a happy coincidence with a purposeful plan.

不要靠巧合編程
只依靠可靠的事物。註意偶發的復雜性，不要把幸運的巧合與有目的計劃混為一談。

Test Your Estimates
Mathematical analysis of algorithms doesn’t tell you everything. Try timing your code in its target environment.

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

Design to Test
Start thinking about testing before you write a line of code.

為測試而設計
在你還沒有編寫代碼時就開始思考測試問題。

Don’t Use Wizard Code You Don’t Understand
Wizards can generate reams of code. Make sure you understand all of it before you incorporate it into your project.

不要使用你不理解的向導代碼
向導可以生成大量代碼。在你把它們合並到你的項目，確保你理解全部這些代碼。

Work with a User to Think Like a User
It’s the best way to gain insight into how the system will really be used.

與用戶一起工作，以像用戶一樣思考
要了解系統實際上將如何被使用，這是最好的方法。

Use a Project Glossary
Create and maintain a single source of all the specific terms and vocabulary for a project.

使用項目詞匯表
創建並維護包含項目中所有專用術語和詞匯的單一信息源。

Start When You’re Ready
You’ve been building experience all your life. Don’t ignore niggling doubts.

等你準備好再開始
你的一生都在積累經驗。不要忽視反復出現的疑慮。

Don’t Be a Slave to Formal Methods
Don’t blindly adopt any technique without putting it into the context of your development practices and capabilities.

不要做形式方法的奴隸
如果你沒有把某項技術放進你的開發實踐和能力的語境中，不要盲目地采用它。

Organize Teams Around Functionality
Don’t separate designers from coders, testers from data modelers. Build teams the way you build code.

圍繞功能組織團隊
不要把設計師和編碼員分開，也不要把測試員和數據建模員分開。按照你構建代碼的方式構建團隊。

Test Early. Test Often. Test Automatically.
Tests that run with every build are much more effective than test plans that sit on a shelf.

早測試。常測試。自動測試。
與呆在書架上的測試計劃相比，每次構建時運行的測試要有效地多。

Use Saboteurs to Test Your Testing
Introduce bugs on purpose in a separate copy of the source to verify that testing will catch them.

通過“蓄意破壞”測試你的測試
在單獨的軟件副本上故意引入bug，以檢驗測試能夠抓住它們。

Find Bugs Once
Once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tests should check for it from then on.

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

Build Documentation In, Don’t Bolt It On
Documentation created separately from code is less likely to be correct and up to date.

把文檔建在裏面，不要栓在外面
與代碼分離的文檔不太可能被修正和更新。

Sign Your Work
Craftsmen of an earlier age were proud to sign their work. You should be, too.

在你的作品上簽名
過去時代的手藝人為能在他們的作品上簽名而自豪。你也應該如此。

參考資料

[1] 馬維達（譯）（2004）. 程序員修煉之道：從小工到專家. 北京：電子工業出版社. (Andrew Hunt, David Thomas. The Pragmatic Programmer: From Journeyman to Master. 2000)

[2] Andrew Hunt, David Thomas. Pragmatic Software Development Tips [OL]. https://pragprog.com/the-pragmatic-programmer/extracts/tips

[英中雙語] Pragmatic Software Development Tips 務實的軟件開發提示