程序员修炼之道_从小工到专家_读书分享

最近央视给我们连续分享了《大国工匠》，很是羡慕，嫉妒，恨。要知道我们程序员也是一名工匠，哈哈。最近用两天多的时间读了一本和工匠有关的书籍《程序员修炼之道-从小工到专家》这本书，现在分享给大家，因本人能力有限，拙劣之处请包涵。

从这本书的名字说起，这本书现在的名字体现不出来书中的主题内容，书的原名为《The Pragmatic Programmer》翻译为《注重实效的程序员》，看到这个题目想必大家对书的主题有个大概印象。这本书在编码问题，软件架构和设计，项目管理等方面都有讲解。

本书总共分八章：

1. 1.      注重实效的哲学

2. 2.      注重实效的途径

3. 3.      基本工具

4. 4.      注重实效的偏执

5. 5.      弯曲，或折断

6. 6.      当你编码时

7. 7.      在项目编码之前

8. 8.      注重实效的项目

这本书的章节设置和一般书籍章节设置有非常大的不同，各个章节之间做到了既独立也相关，可以从头阅读，也可以随意翻页即读。这难道是没有明说的解耦思想，哈哈。

先说下第一章<<注重实效的哲学>>

首先大家不要被高大上的“哲学”二字迷惑，这里仅仅指的是一些基本思维方式方法。

1，             我的源码被猫吃了

我举个语境，要是哪天你的硬盘垮了，带走了你的源码，而你又没有备份，你告诉你的老板“我的源码被猫吃了”。这其实说的意思是，要对自己的工作负责。要提供选择，而不是找借口。要说明通过什么能挽回局面。

2，             软件的熵

想必程序员在维护槽糕的代码都有这样的经历，现在的代码都是垃圾，我照做就是了。

当我们发现自己所在的团队的代码非常优美时，我们会格外的保持干净。听起来是否似曾相识，其实这就是“破窗户理论”。其实我现在还没有弄清楚译者为什么会用“软件的熵”做标题。

3，             煮青蛙和石头汤

温水煮青蛙也可以用到项目管理当中，其实就是说，项目的腐烂都是从一次次脱离规范，一工时工时的拖延开始的。至于石头汤的故事在这里不展开，留给有心的同学们，提前说一下，石头汤的故事更有趣，参与的角色更多样，理解的角度更多样。

4，             足够好的软件

这一点引入一个书中的问题：

考察你使用的软件工具和操作系统的制造商。你能否发现证据，表明这些公司安于发布他们知道不完美的软件吗？作为用户，你是会（1）等着他们清除所有bug，（2）拥有复杂的软件，并接受某些bug，还是会（3）选择缺陷较少的更简单的软件？

这道题书中没有给出答案及分析。从作者角度出发，选项（3）是符合作者的“足够好的软件”。

但是我认为这本书出版在2004年前后，到现在已12年之久，加上互联网，移动互联网发展，互联网产品的涌现。作者对足够好的软件的定位还需商讨。

5，             你的知识资产

这一点我就不按照书本上讲解了，这里我从一个软件开发角度讲解一下知识。

第一类为基本理论类书籍，这些书籍的总量相对比较固定。基本上有140 左右。可以参考http://www.theithome.net/read-htm-tid-43460.html

第二类为技能书籍，包括各种流行技术，编程语言等。这种书籍广泛，数量多。

我认为读书的过程中最重要的就是要有批判精神。可以提高阅读转化率。

6，             交流

这部分我主要记住了两句话，一句话是，被打量要比被忽视更好。第二句话说的意思是说一个好的想法，如果没有有效的沟通就如同一个没有人关心的孤儿。

注意，在这里给人力资源部打个广告，人力资源部给员工的培养课程资料中的提供的《有效沟通技巧》讲的交流沟通内容是很丰富的。

第二章《注重实效的途径》

第一章讲的内容更多的是无招内功九阳神功理念。第二章咱们就进入干货，练习九阴白骨爪。

7，             重复的危害

   书中描述是这样子的，当你在一个系统中两处或者多处表达同一个事物，你要是改变其中一处，你必须记得改变其他各处。但是我要说这不是你能否记住的的问题，而是你何时忘记的问题。这就是重复危害的深刻表达。

   书中的作者在这一小节中对重复危害的产生原因讲的很透彻全面。但是到最后没有明确提炼出避免重复的措施，措施隐含分布在各处（难道是为了避免重复，这也是太快了吧），我整理如下:

1，             通过清晰的设计，强有力的技术领导，进而在设计中进行充分理解的责任区域划分。可以规避一些问题

2，             但是模块层重复更隐蔽。不能划入明显的责任区域。解决这个问题就要用到第一章的第六条交流。鼓励开发者交换意见，进行提问，找到并复用已有的东西。

8，             正交性

这里的正交其实就是咱们熟悉的解耦。在这里你估计会想到标题为啥是正交，不是解耦。

我忘了告诉大家本书的作者同时也是一位木匠和音乐家。估计能在木匠和音乐领域找到答案。作者真的博学。

这里抛出去一道思考题：

C++支持多重继承，而java允许类实现多重接口，使用这些设施对正交性有和影响？使用多重继承和使用多重接口的影响是否有不同？。。。

9，             可撤销性

可撤销性我认为是对一个产品开发结果的一种度量。可撤销性就是拥抱变化，通过之前的建议，避免重复，解耦等的使用，制作灵活，有适应能力的软件。

举个很常见的例子，如果正在项目开发的过程当中提出需要更换数据库厂商，这时要是我们把数据库的概念抽象出来（数据库只是一种数据持久化），而不是把调用数据库的代码缠绕在各处。我们就可以说是soeasy。

10，        曳光弹

这个名词我是第一次听说，中间作者也花费了笔墨解释曳光弹的出处。这个名字估计估计要另外一个作者喜欢玩飞机有关系吧。

简单的说，曳光弹其实就是有可用代码的原型设计。原型一旦用户对界面同意，可以直接扔掉。但是曳光弹不同，他是一个能工作的东西。开发人员可以在里面添加新功能。

其实在这里追究曳光弹的概念边界我觉得不重要，重要的是我们能在合适的场合使用。

11，        原型与便签

这一节通篇再讲原型设计。看完之后基本就忘记了。

12，        领域语言

这一小节的内容作者是站在计算机语言的高度描述讲解的。现在这么多的语言，就是因为为了解决不同领域的问题产生的。例如咱们公司前一段事件招聘中提到的R语言，R语言我认为就是一种为了用于统计计算和统计制图的优秀领域语言。

再往近的说，相信大部分公司开发人员都熟悉java，熟悉非常流行的spring框架。Spring中有一个常用的措施，就是许多特定功能都可以通过XML描述语言进行描述。可以屏蔽实现细节。很简单的可以让开发人员处理特定领域问题（比如事务控制，日志等）。我认为spring通过利用xml描述语言，及其自己写的类似解释XMl的解释器来解决问题的思路从某种角度也有这个思想。

13，        估算

里面讲到的估算，印象是最深的是一个例子,如果你的奶奶问你何时到达，她也许只是想知道该给你准备午餐还是晚餐，而一个困在水下，空气就快用光的潜水员很可能需要你精确的回答。这告诉我们估算是有语境的。

这本书讲到的估算比较粗略。想要系统学习估算要找相关专业书籍啦。

第三章《基本工具》

第三章作者从木匠切入，系统阐述了工具的作用，工具是如何产生工作效益，最终工具可以放大你的才干。其中包括14，纯文本的威力，15，shell游戏，16，强力编辑，17，源码控制，18，调试，19，文本操作，20，代码生成器。

其中的shell游戏，纯文本的威力小节如果你是一个类unix系统用户会体会比较深刻，但是我不是。体会的不是很深刻。

对于调试书中有一句很难忘的话，如果你发现了他人的bug，请不用把精力放到职责肇事者。你应该修正问题。因为这现在是你的问题，责任。这或许可能当为工作环境中的一种文化引导。

代码生成器的便利性在公司的开发平台（在eclipse平台之上做了插件开发）之上体现的很具体可感知。

第四章《注重实效的偏执》

这一章看完我没有理解标题中的偏执。哎，毕竟是国外的东西拿来翻译的。

这一章主要讲的目的是如何编写健壮的代码，讲解的内容有21，按照合约设计，22，死程序不说谎，23，断言式编程，24，何时使用异常，25，怎么配平资源。

我个人不认为断言式编程能提高工作效率，至少现在，调试的设施很多。

对于书中的“在生产代码中可以让重要的断言开启”这个观点同时有待商讨。

25小节中提到的配平资源其实就是如何管理资源（内存等），这里的原则就是谁分配的，谁就负责解除其分配。对于java而言，垃圾回收机制已经帮我们做了大部分的工作。

第五章《弯曲，或折断》

这一章主要介绍了如何创建可以拥抱变化的代码，讲解的内容有26，解耦与得默忒耳法则，27，元程序设计，28，时间耦合，29，它只是试图，30，黑板

其中的元程序设计，它只是试图（主要是对MVC做了扩展），时间耦合的运用都是为了达到解耦，解耦的目的就是穿件可以拥抱变化的代码。

这里重点说明一下时间耦合，时间耦合中的时间有两个方面对我们很重要：并发（事情在同一时间发生），次序（事情在时间中的相对位置）。对于可以同时进行的任务我们可以并发进行，利用一个任务的可能等待去执行另一个任务，这样就可以在时间上进行解耦。对于有约束的并发，就是并发中次序。就需要有具体分析来改进并发。不知道是译者的问题，还是我理解的问题，在时间耦合这块我感觉我没有很清晰的把握中原作者的所有意图。

第六章《当你编码时》

这一章主要介绍了当你编码时应该思考的问题。讲解的内容有: 31，靠巧合编程，32，算法速率，33，重构，34，易于测试的代码，35，邪恶的向导。

如何避免靠巧合编程书中提到了很多条，其中不要依靠假定写代码，不但要测试你的代码，同时也要测试你的假定。

算法速率的估算书中主要是把时间复杂度，空间复杂度的具体计算方法，同时也对时间和空间取舍做了说明。

重构需要记住的是，不要说开发时间不够，记住上面的破窗户理论。早重构，长重构。

在测试这块我想说下，开发人员要重视自测，因为某一类问题（逻辑情况比较多）单靠测试人员有可能会遗漏。

邪恶的向导说法有点太过了，向导本省是好的，就是我们要对代码生成器或者向导产生的代码要保留百分之一的怀疑。

第七章《在项目开始之前》

这一章主要讲述的对象从个体的哲学和编码问题转换为了项目。讲解的内容有: 36，需求之坑，37，解开不可能解开的谜题，38，等你准备好，39，规范陷阱，40，圆圈与箭头。

其中主要澄清一下需求之坑，这里的坑不是需求人员故意埋的坑，这里的坑指的是隐藏在坑底的需求，不是简单搜索，而是深层次的挖掘。当开发人员发现了需求的坑，请不要抱怨需求人员，这不是需求人员造的坑，反而需求人员在我们不知道的情况下已帮助我们填补了许多坑，感谢需求人员。

这一章同时也讲述了解决问题的意思思路，还有项目之前有限准备，防止错失良机，适度规范，不要陷入规范陷阱。最后也讲述了项目中的工具。我重点提醒不要被工具束缚住。

第八章《注重实效的项目》

这一章主要讨论使项目失败和成功的关键区域。讲解的内容有：41，注重实效的团队，42，无处不在的自动化，43，无情的测试，44，全部都是写，45，极大的期望，46，傲慢与偏见。

在团队的论述当中，印象最深刻的是杜绝一个老鼠害了一锅汤，不要让一个消极，一个不完美的东西存在，相信这个东西会蔓延开来，恶化整个团队。这也和前文提到的“破窗户理论”呼应。努力提高自动化程度，因为有人参与就有产生错误的机会。无情的测试里面讲到了很大范围的测试方法。当你交付的产品能稍微超出客户的预期时相信你的商业信誉就提高了。最后提到傲慢与偏见其实就指的一件事，就是对你的代码签名，对于队友可以方便的找到你。

读书分享总结:
这本书中整体内容前后逻辑相关性不强，但是不能说这是缺点。这本书更多讲的是一些观点，方法，原则，建议，大概有46个。在这46个当中，我们要辩证统一地认识，在具体工作当中根据具体情况要有取有舍，避免一个人同时带了多块不同时间的手表，让人忙乱于原则教条本身，无形之中忽视了项目，忽视了提高生产力这一重要目的。