思考尚可，沉思不必

首先承认我读得比较快。在一个炎热的午后，等着钟点工阿姨帮我把家里打扫干净的4个小时里，我把这本167页的小册子读完了。
收获不大。
个人认为，在这本小册子里，除了比较大而宽泛的方法论叙述外，稍微有些营养的主要集中在：第7章：迭代经理是什么角色；第8章：项目生命体征；第11章：重构Ant构建文件；第12章：一键发布；第13章：企业Web应用中的敏捷测试和瀑布测试；以及第14章：实用主义的性能测试。6/14，大概是50%不到的有效内容。
而我对第5、6章尤其不敢苟同。
在第5章中，作者提出可以在统一的JVM平台上利用多语言优势，如JRuby, Groovy等共同开发。殊不知，在公司规模较大，代码拥有数量较多(>1M行)的条件下，降低维护开销的最佳实践之一就是减少使用语言的数量。每引入一种语言，就意味着: 1) 公司内要形成一个语言的使用者社区，不然有问题无法共同探讨，而唯一的几个工程师离开后就会形成无人能懂，无人可维护的“死代码”，2) 要建立与之对应的一套构造工具和自动化测试系统，3) 公司的公共架构，比如存储、消息传递、缓存、RPC等，都要为每种语言纂写一套client。这些都是非常大的开销。事实上，对于绝大多数公司而言，有Java/C++，Python，PHP/Ruby，JavaScript/ActionScript，就足够应付日常的工作了。Google的前端是Java做的，Facebook是PHP，豆瓣是Python。这些都是很好的例子。
在第6章中，作者非常推崇“极小”，即将类和方法的逻辑和代码行数控制在最小的范围内。这原是一个good practice，无可厚非，因为它可以将代码读者对于上下文和程序逻辑限制在可理解的范围内。然而作者对它的热爱到达了偏执的地步：方法只适用一级缩进、拒绝使用Else关键字、类的长度不超过50行、类中实例变量不超过2个。这样除了把代码变得支离破碎外我看不出有任何的好处。观点可商榷，原教旨主义的实践我着实不敢恭维。
瑕不掩瑜，全书中我认为比较出彩的是最后三章，值得一读。
最后对于全书定价(￥39)，大笑一声，不予置评。；）