[英中双语] Pragmatic Software Development Tips 务实的软件开发提示

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