不知道我会不会是唯一一个对这本书持不满态度的读者，但我知道我会怎么想就怎么说。
首先从书名来看，应该是“沉思”的内容，应该是“思想领袖”的经验心得，但我看着却觉得很别扭，有几篇文章并没有达到启发思想的高度，更像是总结经验。有些文章推崇的方式并不够敏捷，例如迭代经理；更有一些文章颇有点互相冲突，第12章的“一键发布”里面认为测试分为单元测试和接受性测试，而随后的第13章“企业Web应用中的敏捷测试和瀑布测试”则将测试分类划分得和瀑布模型一样细致入微；而既然是思想级别的文章，就不应该将目光仅仅盯在自己的产品，如今的持续集成世界里已经有很多的开源软件可以使用，由于ThoughtWorks转向专注商业产品Cruise，其开源的CruiseControl已经是鸡肋，文章中却只字不提例如Hudson之类的其他工具，似乎缺少一点思想级别的气度。
其次，不过得怪我自己的能力有限。第3章的Ruby我看不明白，主要没有用Ruby编程过；第4章的“语言的盛景”，我搞不懂为啥Python没能被收录进文章中讨论；第5章的“多语言开发”还算可以，能够理解到它的思想，也即是因材施教，根据不同的应用场景选择更合适的工具，不过不太明白这些语言的具体函数、语法，总觉得离领悟其精髓差那么一两步；第6章“对象健身操”，也包括其他有详细讲到编程语言的章节都一样，有些术语，作为测试背景的家伙，直接看那些翻译过来的中文词汇，真的是不得其解，或许换成英文我还能多少领会个大概；第7章的“迭代经理”，我觉得真是啼笑皆非，怎么会有这么个不敏捷不瀑布的不上不下的角色，一部分的职责和Scrum里的Scrum Master相似，一部分职责和传统的Project Manager相似，估摸着应该是更适合外包业务形态的一个角色吧；第8章“项目生命体征”其实还是不错的，强调着要清晰地了解自己项目当下的情况，在有危险的时刻及时采取补救措施，只不过，在敏捷的世界里，到底还有没有“项目”啊？第9章“消费者驱动契约：服务演化模式”对我来说简直就是天书，看了一部分我就放弃了不准备继续阅读，不过这是因为我自己没有相关的经验，也不理解SOA这个东东。
个人比较喜欢第3、5、11章，觉得第2、8、12章本可以做得更好。
“第三章 一个巢穴，二十种Ruby DSL” —— Martin Fowler
Martin利用一个具体的例子给出多种多样的Ruby DSL实现，让人可以直观地比较各种方法的不同之处，以展示给读者“Dave Thomas在他的博客中提及‘代码拆招’（code katas）”的概念。由于我对Ruby有限的了解、理解能力，无法从这篇文章中领悟它的精髓，但却是可以感觉到大师的风范，另一个深刻印象就是Ruby真的是可以写出很简洁很优雅的代码，很是佩服。
“第五章 多语言开发” —— Neal Ford
部分的因为我的测试背景，我对任何一种语言都没有偏好，所以每当看到那些在论坛上为了某种语言争得面红耳赤的同学们，都觉得有些不理解。在我看来，语言不过是一种武器，而武器自身有它的发展和进化。如果武器不好使，那么就换一种，你觉得不好用，不意味着别人就不好用，没有必要把它踩在脚底下践踏。Neal的文章其核心思想也大致如此，在Java平台可以使用不限于Java语言的多种语言编程，也就可以摆脱Java语言的束缚，在一些场景下选择更适合的其他语言，从而更快更好更简洁地开发代码，实现需求。例如里面提到的Groovy、JRuby和Jaskell。
“第十一章 重构Ant构建文件” —— Julian Simpson
在以前经历过的一次产品开发里，我们有使用CruiseControl来搭建持续集成系统，和Ant有过接触。恰恰也经历过文中所提到的这些维护问题，尤其是多个版本或是分支在运行的时候，每一次添加一些处理或是代码仓库的信息，都是一次艰苦的旅程。虽然我们也把build.xml放入代码库维护，却从未想过把它当做代码一样的对待。文章中的这些经验可以切切实实地改善Ant文件的可维护性，还分享有些许高端的使用技巧。
个人感到有点点疑惑的就是，Hudson的网页配置界面真的是很好使用，人们还有没有必要去学习Ant的这些使用。至少我用过Hudson之后有这样的感觉，而且我们的大型项目都已经从CruiseControl转向了使用Hudson。
