从《程序员修炼之道》看如何成为注重实效的程序员

抽空读这本书也是慕名而来，这本书还有一个副标题叫从小工到专家。我个人认为副标题翻译的挺好。本书的英文版全名是《The Pragmatic Programmer：From Journeyman to Master》，主标题翻译成“注重实效的程序员”可能更加贴近英文的原意。这本书详细讲了一个注重实效的程序员的练功心法。事实上编程是一种技艺，一种需要用心学习的技艺，而程序员也是一种匠人，在现在强调匠人精神的今天，如果不励志做个好匠人，视乎有点说不过去，那我们看看本书是怎样教你成为一个合格的匠人的。

接下来将是书中经典的提示总结，每一句都值得深思。

1.关心你的技艺。

如果你不在乎能否漂亮滴开发出软件，你又为何要耗费生命去开发软件呢？一个注重实效的程序员是会不断打磨自己写高质量代码的水平的，就如匠人不断提高自己的手艺一样，如果你讨厌这样做，可能你来错了行业。

2.思考！你的工作。

在你做某件事情的时候，思考你在做什么。不间断的思考，实时地批判你的工作，是否还有更好的方法解决现在的问题。

3.提供各种选择，不要找撇脚的借口 。

在所有的弱点中，最大的弱点就是害怕暴露弱点。所以遇到问题，重要的不是找借口，不是说做不到，而是要说明能够做什么来挽回局面。

4.不要容忍破窗户（低劣的设计、错误决策、糟糕的代码）。

当你看到糟糕的设计、错误的决策和糟糕的代码时，修正它们。如果不马上修正，你会发现越来越多的“破窗户”开始出现，而一个月前，还只有一个这样的“破窗户”。

5.使质量成为需求问题。

做需求的时候就要明确好，系统要考虑哪些异常情况，系统要承受的性能压力是多少，合作方的数据如果不正确，我们会如何处理等。总之把质量要求放到需求里说清楚，而不是到出了问题，再抱怨说这个情况我们当时没有考虑。明确的要求，会让大家在编码时更容易想到。

6.定期为你的知识资产投资，让学习成为习惯。

这个观点很有意思，往常我们认为投资都是用钱去做，很少有人去站在投资的角度来看待学习知识这件事情。本杰明富兰克林说，知识上的投资总能得到最好的回报。书中给每个想成为注重实效的程序员提供了一个小目标。
a.每年至少学习一种新语言。
b.每季度阅读一本技术书籍。
c.也要阅读非技术书籍。
d.上课（mooc是一个不错的选择）。
e.参加本地用户组织。
f.试验不同的环境。
g.跟上潮流（订阅商务杂志和其他期刊）。
h.上网（好吧，我被这条雷到了，现在还有谁不这样做呢）。
最后，批判性地分析你读到的和听到的任何信息。

7.你说什么和你怎么说同样重要。

对于不善言辞的大部分程序员这可能是一个不小的挑战。不过如果你不能有效地向他人传达你的了不起的想法，这些想法就毫无用处，不是吗？

8.DRY（干，原则 Don't Repeat Yourself). 不要重复你自己，让复用变得容易。

重复是怎样产生的，强加的重复（imposed duplication）。开发者觉得他们无可选择——环境似乎要求重复（比如c语言中的.h文件）。
无意的重复（inadvertent duplication）。开发者没有意识到他们在重复信息。
无耐性的重复（impatient duplication）。开发者偷懒，他们重复，因为那样似乎更容易。
开发者之间的重复（interdeveloper duplication）。同一团队（或不同团队）的几个人重复了同样的信息。
对一个注重实效的程序员，后两种重复要想尽一切办法避免。

9.消除无关事务之间的影响。

设计自足、独立、并具有单一、良好定义的目的的组件。也就是我们常说的单一任务原则，让程序更加的内聚，减少不必要的耦合。

10.不存在最终决策。

没有决策是浇筑在石头上的。相反，要把每项决策都视为是写在沙滩上的，并为变化做好计划。不要轻易相信产品给出需求时信誓旦旦的保证，这个需求细节一定不变，也许商务合作的细节修改亦或者是用户的抱怨，就会让你重新设计。所以与其杜绝变化（这是不可能的）、憎恨变化（对自己身体不利,怒火伤肝），不如拥抱变化（可能会提高你的编程技艺）。

11.利用命令shell的力量。

当图形用户界面无能为力时使用shell。你如果现在还没有熟练使用一种脚本语言，现在就开始学习吧，毕竟种树只有两个时间点是不晚的，十年前和现在。

12.用好一种编辑器。

编辑器应该是你的手的延伸，确保你的编辑器是可配置、可扩展和可编程的。怎么衡量你是否已经比较好的使用你的编辑器了呢，如果很多时候你都需要使用鼠标，说明你还没有用好它。

13.总是使用源码控制。

这个是一定的，现在公司内应该没有不使用源码控制的系统，当然书中建议即使是你自己一个人开发代码也要使用源码控制，各种git免费仓库都是你的不错选择。

14.要修正问题，而不是发出指责。

bug是你的过错，还是别人的过错，并不是真的有关系。当你遇到它的时候，它就是你的问题，它仍然需要修正。

15.你不可能写出完美的软件。

这刺痛了你？不应该。把它视为生活的公理，接受它，拥抱它，庆祝它。因为完美的软件不存在。在计算技术简短的历史中，没有一个人曾经写出过一个完美的软件。你也不大可能成为第一个。除非你把这作为事实接受下来，否则你最终会把时间和精力浪费在追逐不可能实现的梦想上。那是不是没有补救措施了，最起码你可以尽可能的编写高质量的代码，为你的代码，加上测试代码会是一个不错的选择。

16.早重构，常重构。

就和你会在花园里除草、从重新布置一样，在需要时对代码进行重写、重做和重新架构，要铲除问题的根源。

17.为测试而设计。

考虑你编写代码的可测性，甚至在你还没有编写代码时就开始思考测试问题。并且，要对你的软件进行无情的测试，不要让你的用户为你找bug。

18.不要使用手工流程。

shell脚本或者批文件会一次次地以同一顺序执行同样的命令。所以能把工作流自动化，就都自动化。

19.早测试，常测试，自动测试。

与呆在书架上的测试计划相比，每次构建时运行的单元测试要有效的多，它可以节省你大部分的程序调试时间，想一想，你在编写代码时花在调试的时间占到你编写代码总时间的多少，也许你就会下决心，开始学习使用单测来帮助你调试程序了。

20.一个bug只抓一次。

一旦测试员找到一个bug，这应该是测试员最后一次找到它，此后自动化测试（单元测试，或者接口测试）应该对其进行检查。

以上只是我找了自己认为的比较关键的一些点写了下来，希望对大家有所启发，这本书值得每个想成为注重实效的程序员阅读，再次推荐给大家，祝大家都能成为注重实效的程序员。