英文书评：Amazon

中文书评：Douban

国内购买：China-pub

首先，强烈谴责一下出版商的中英文对照版。对一些人来说这无疑是对纸张的浪费。

同时，感谢出版商的英明抉择，我有机会知道中文后的英文到底是什么。我体会到了什么是直译，译者不断的把story翻译成“故事”。让我感觉是在和一个新加坡人说汉语。

对XP编程这个概念的最初接触，是毕业后到了公司后的事情。项目最早的每日构建实施后，对之后到公司的人来说，每天早上获得一个凌晨构建版是天经地义的事情。如今，我们要么获得一个昨天的构建版，要么获得一封构建失败责任通报信。对于如此庞大的项目，每日构建突显的如此重要，以至于曾经有人想开发手机短信提示系统，如果凌晨的时候构建不过，会自动发一封短信到错误文件的最后一个commiter。可见项目成员对构建失败的担心已经不是在积分考核这一层面上，而是担心自己在团队中的被信任度下降。关于信任，在本书中也有提及。一个项目成员要树立起自己的可信形象，才能更容易被人接受。

与互信相对立的另一面的是自信，这里的自信不是指对自己能力的信任，而是对自己代码的信任，一行代码在没有被加入到实际系统之前，我一直忐忑不安，直到编译过，运行过，人工测试过…可是还是不安。局部的单元测试一直是我周围的人常提的理念，然而不幸的是，庞大项目中单元测试的部分太少。导致发布前大家惶惶不安。所谓测试先行有点夸张，有的时候很难做到，但是事后补全测试的做法还是可行的，至少是一个很好的过度阶段。书中说，要进入到一个水池里面有很多方法，快慢有别，对于一些有抵触心理的人来说，事后补全这是一个介入的好方法。

而单元测试这类的概念，如果只是强迫项目中的成员去做，效果一定不佳，如果让每人都从单元测试中得到好处，那么施行起来一定顺畅。最让我兴奋的是这样一句话，“我的BUG？不可能，单元测试全通过了！要么你错了，要么单元测试案例不足。”多么完美啊，谁会拒绝这样的好东西？

单元测试的最终目标是集成，而XP的观念中，集成是要持续的，每日构建已经在我所在的部门中成为了一个项目的必须，但是集成的范围还应该涉及自动化集成测试。如果说单元测试让项目组内的程序员放下了心理包袱，那么集成测试和持续集成便为项目经理找到了“甜区”。

团队中成员之间的交流与结果分享也是书中十分强调的，我最赞成的观点是对需求文档地位的变化，如果一篇文档不能随时保持更新，那么就别写它了。只保持最基本的就够了。需求文档或是其他文档的时效性低的原因是我们太重视最初设计了。XP的另一个重要观念是永久设计，永久设计并不是说我们可以不做设计就可以开始工作，而是只做最基本的设计后马上开始，在实现的过程中修正和填补设计。大多数人都会是第一次做一个领域中的项目，因此实践是学习和改进设计的最好方式。同时这也说明，事先预想的设计很大程度上是不实际的。

最后一个收获是关于结对编程，目前在整体项目功能分块上实现结对好象不很实际，因为要考虑人力因素和旧有思维的烙印。但是如果是一天或一周的某个时候，当自己思维僵化时，与人共同思考。又或是在模块集成的时候，由双方的人结对实现。效果连自己都会感到很惊讶。这就如同将头脑风暴从会议室搬到了代码前。这种被迫迅速思维的方式会让我觉得自己很聪明！结对编程的终极形式就是一台PC上两个键盘两个鼠标，当然显示器是共用的，越多越大越好。不过这只是形式而已。

每日构建、团队互信、单元测试、持续集成、集成测试、持续测试、永久设计、结队编程。看，我已经说的够多的了。

一本书汇聚成一篇书评或我这篇该叫做读后感是一件很费力的事情，也是对阅读的反省。这里我只是把这本书中学到的东西简单的写了一下，而实际应用中，我可以为我的小团队打60分，给我的大团队打70分。还有待改进，但我为我们的现状已经很自豪了。