《高效程序员的45个习惯--敏捷开发修炼之道》读后总结

一片论文瘦八斤，瘦下来的东西，希望交换成了知识存在脑袋里。

论文写完，离下一个项目的开始还有一周的时间，利用这个时间差，读完了借来的题目中的书。就像序里面说的，其实这就是一本关于敏捷的书，只不过说的比较委婉。

刚翻开书的时候，发现里面确实有很多好的编程习惯可以借鉴，读着读着，发现这更是一本将团队高效配合的书。不过我们现在做的东西大多是和导师交流，所以团队高效合作方面的技巧暂时能用上的还比较少，有什么体会也没资格说，不过关于书中的另一个方面，也就是题目中的“习惯”——尤其是编程习惯，还是有一些收获的。这就将书中较好的摘抄下来。

1.对事不对人，敏捷的团队中排在首位的应该是解决问题

当Lee先生在做一个新方案介绍的时候，下面有人会说：“那样很蠢！”（这也暗示着Lee先生也很蠢。）如果把这句话推敲一下，也许会好一点：“那样很蠢，你忘记考虑它要线程安全。”事实上最合适并且最有效的表达方式应该是：“谢谢，Lee先生。但是我想知道，如果两个用户同时登陆会发生什么情况？”

看出其中的不同了吧！下面来看一看对一个明显的错误有哪些常见的反应：

1.否定个人能力。

2.指出明显的缺点，并否认其观点。

3.询问你的队友，并提出你的顾虑。

第三种方法没有谴责，没有评判，只是简单的表达自己的观点。让Lee意识到这个问题，而不是让扫他的面子。由此可以开始一次交谈，而不是争辩。

让我们骄傲的应该是解决了问题，而不是比较谁出的主意更好

如果你没有犯过任何错误，就说明你可能没有努力去工作

开发者和质量工程师（QA）争论某个问题是系统本身的缺陷还是系统增强功能导致的，通常没有多大的意义。一起如此不如赶紧去修复他。

2.欲速则不达，防微杜渐

Andy（本书作者之一）以前的一个客户遇到了一个问题。没有一个开发者或者架构师知道他们业务领域的底层数据模型。而且，通过几年的积累，代码里有着成千上万的+1和-1修正。再这样脏乱的代码中添加新功能或者修复bug，就难逃脱发的的噩运。

不要急于修复一段没能真正理解的代码。这种+1/-1的病症始于无形，但是很快就会让代码一团糟。要解决真正的问题，不要治标不治本。

孤立的编程非常危险，代码复审是发现bug最有效的方法之一。

项目中，代码应该是很亮堂的，不应该有黑暗死角。

评：表示被导师亲自Review的人感触很深，代码亮趟是个艺术活，需要下功夫。

3.跟踪变化

了解最新行情，如饥似渴的阅读，跟上新技术，学习新技术就不再是大问题，你不需要一口气爬上10层楼，而需要一直在攀登，所以最后看起来就像只要再上一二层。如果对所有技术都一无所知，想要马上登上10楼，肯定会让你喘过气来！

迭代和增量式的学习。每天计划用一段时间来学习新技术，当你听到一些不熟悉的属于或者短语时，简要地记录下来。然后在计划的时间中深入研究它。

你不需要精通所有技术，但需要清楚知道行业的动向，从而规划你的项目和职业生涯。

评：我们有个老师，感觉很多技术他都知道，都会用，估计就是这种增量学习的成果吧。

4.打破砂锅问到底

不停的文为什么。不能只满足于别人告诉你的表面现象。要不停地提问知道你明白问题的根源。

5.保持简单

“简单性”这个词汇被人们大大误解了。他并不是以为着简陋、业余或者能力不足。恰恰相反，相比一个过分复杂、拙劣的解决放啊，简单的方案通常更难获得。

怎样才算优雅？优雅的代码第一眼看上去，就知道它的用处，而且很简洁。但是这样的解决方案不是那么容易就想出来的。这就是说，优雅是易于理解和便是的，但是要想创建出来就困难多了。

开发可以工作的、最简单的解决方案。除非有不可辩驳的原因，否则不要使用设计模式、原则和高难度技术之类的东西。

当你觉得所编写的代码中没有一行是多余的，并且仍能交付全部的功能时，这种感觉就对了。这样的代码容易理解和改正。

评：个人感觉这一条和奥坎姆剃刀有着很相近的意思。尤其是代码中，简洁，优美，反倒是出问题的几率较少，维护容易。

6.记录问题解决日志

面对问题（并解决掉）是开发人员的一种生活方式。通过web寻找答案是个好方法，但是是非常耗时间的过程。有时可以找到需要的答案，有时除了找到一大堆意见和建议之外，发现不了实质性的解决方案。看到有多少人员遇到同样的问题，也许会感觉不错，但是我们需要的是一个解决方案。想得到更好的效果，不妨维护一个保存曾经遇到过的问题以及解决方案的日志。这样当问题放生是，就不必说：”嘿，我曾碰到过这个问题，但是不记得是怎么解决的了。“可以快速搜索以前用过的方法。工程师们已经使用这种方式很多年了，他们称之为每日日志（daylog）。下面的条目可能会用得上：

1.问题发生的日期

2.问题简述

3.解决方案详细描述

4.引用文章或网址，以提供更多细节或相关信息。

5.任何代码片段、设置或对话框的截屏，只要他们是解决方案的一部分，或者可以帮助更深入地理解相关细节。

要将日志保存为可供计算机搜索的格式，就可以进行相关字搜索的格式，就可以进行关键字搜索以快速查找细节了。（怎么做到？javadoc?）

这个文件还可以创建一个Wiki，大家一起来维护。

总结

以上就是书中的内容，大多是原话摘抄，小部分是笔（键）者（人）的评论。

读完了之后，常驻于心的就是：敏捷就是要解决问题，而不是指责别人。抱着这样的话，就有理由相信别人也是这样想的，竟然就提高了自己的交流效率。