《程序员修炼之道》- 注重实效的参考指南

终于读完了《程序员修炼之道》，全书围绕注重实效的程序员展开思考，逐步分析了开发中须要遵照的准则。本文记录其中一些指南。

原文

一、关心你的技艺

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过去时代的手艺人为能在他们的做品上签名而自豪。你也应该如此。