《软件开发沉思录》书评

图灵试读的作业...

的确是认真看了两遍才起笔的，总想写很多，但是，又都是不成体系的，就吐点槽好了＞...同时发布在:ZqreadThoughtWorksAnthology - openbookproject - 图灵:样书申请~软件开发沉思录 -Project Hosting on Google Codehttp://code.google.com/p/openbookproject/wiki/ZqreadThoughtWorksAnthology应图灵俱乐部列表的倡议,申请了样书 "软件开发沉思录" 想就此进一步整理 敏捷中国2009 中的见闻;= Thought Works 文集 =整体上是本包罗万象的薄书;167页的容量包含了14篇,由 Thought Works 成员在日常工作中总结出来的真实体验,非常不寻常;也非常真诚;由于本人涉及软件开发时间不长,经验也比较狹窄,并没有对所有章节有所共鸣,特此评论其中非常有触动的:== "最后一英里" ==这是Thought Works创始人的,果然只说问题域,不给答案的;-)这是所有高层在输出文字时的通病,不过,这也正是现实世界的真实一面,"没有银弹"回想俺在过往所有公司项目中的糟糕体验,对比所有自由软件社区项目中的自在体验;也逐渐明白,掺合了利益的项目,都无法轻灵起来的,这是不可能的;但是,我们可以选择自个儿的"态度";正如,这篇短文中最后给出的对策:* 深刻理解了问题本质后* 勇敢的给出自个儿的应对,并坚持下去,坚信可以成功就好,就好 ...== 对象健身操 ==Jeff Bay 的这篇短文,则是标准的技术成员风格:* 给出解决方案* 给出案例操作/自我训练流程* 给出现实应用案例统计完全的分享即学即用技巧的格局;非常习惯,也非常受用,而且非常认同;这些在使用 OOP 语言时,精练出来的原则,其实在各个公司,各种技术框架上都多少有些;但是,可以总结到这种程度,以及可以内部推广坚持到的地步,实在叹为观止;准备内部也精简结合相关静态代码检测工具,进行推广!-)* PS: 这篇和"重构Ant脚本" 那篇都是非常非常地道的技巧分享,只是俺没有什么机会用 Ant 就没有共鸣了>..== 迭代经理 ==这是 Thought Works 自创的一种角色吧,非常有启发性,这其实是给所有项目中的热心大妈正了名,给了一个"*经理"的名头;* 不过,的确这样将以前多个人自觉配合完成事儿,定一专人统一进行效率要高很多;* 但是,这真的有非常苛刻的先决条件的哪！1. 团队是 敏捷的!1. 项目是 敏捷的!1. 文化是 敏捷的!否则,迭代经理在开发/技术/项目/产品经理之间,纯粹是个概念>..== 项目生命体征 ==咳!这篇就是一位成功的迭代经理的经验分享!当然也同样适用其它各种经理 ;-)给出了5种核心实用体征,以及图表的建立和使用方法;嗯嗯嗯,对俺感触最大的就是"团队感觉", 在我的团队中也在部分使用,只是:* 这东西真的要坚持才可用!* 真的要习惯才管用!* 真的要诚实才能用!* 真的要认同才要用!真的是是真的用才可以的....看过太多各种 KIP/PPC 等等对程序员的绩效考核,都考不到点儿上,但是"团队感觉" 非常容易作到是真实的,但是,非常难以和真实的绩效结合起来...这也只能是在有足够空闲的情况下的一种参考...== 一键发布 ==果然是位技术主管的文章,这种全流程的自动化,没有高层的支持是绝对作不下来的;每次看各种自动化全流程的方案时,都在流口水,其实我的团队主要是 Python 为主进行开发的,和 Thought Works 的核心开发语言Ruby 是同类的动态脚本语言,照理,这种没有编译过程的动态脚本系统,应该非常好进行"一键发布"的;但是,真正的作了才发现很难要很大的决心和毅力:1. 先建立配置管理规范1. 再建立测试主机环境1. 再确立版本发布策略1. 然后明确一切都是理解并执行的1. 最后才是"一键发布"的配置而已...前提条件的各种团队建设的事儿,只要超过3人,就非常容易进入中国的江湖状态,难以理清楚了...* 羡慕从一开始就竖立规范的团队,* 或是有大神力,大法力的技术主管,可以整合所有人的思想和行为,快速打造出这一流程>..= 小结 =书名翻译的好:* Thought Works 文集* 被翻译为 "软件开发沉思录"* 的确,所有文章没有真实的项目经验支撑的话,是写不出来的* 而且 Wought Works 作为专业的敏捷文化推广者和受益者,可以说一直处在对自我和项目的不断反省中只是,这么小的书这么贵有点难以下决心买...

上下班地鐵上看看不錯

覆蓋各階段的論文集，可能不是每一章都適合讀者，我比較喜歡關於領域標註的那篇文章，理論實際相結合，Ruby和Ant的基本跳過了，那篇消費者驅動看了但是沒有看懂，就儅提供一種思路吧。最後幾章比較系統的介紹了各種測試方法，不過這種理論的東西看過估計記住的不多。 InfoQ上有下載精簡版，挑選文章都是方法論的。 http://www.infoq.com/cn/minibooks/thoughtworks-anthology

软件开发沉思录

从编程技术到项目管理，Roy Singham、Martin Fowler、Rebecca Parsons等来自ThoughtWorks的思想领袖通过本书中的13篇美文，将自己多年沉思和实践所得倾囊相授，引领你走向敏捷软件开发的成功之路。本书内容丰富，涵盖了软件开发的各个阶段，既包含DSL、SOA、多语言开发和领域驱动设计等热门主题，也有对象设计、一键发布、性能测试和项目管理等方面的经验之谈和独到见解。不论你是开发人员还是项目管理人员，都将从本书中获益匪浅。

读过之后，我没有沉思

这本书我一共读了三遍。不过说实话，我没看出太大的营养，也许是我的水平所限吧。在我看来，本书不是每一章都适合于读者的，我在读这本书的时候跳过了Ant和一键发布的部分，而关于消费者契约和领域标注，我承认我没有读懂，因此打算等过段时间学了SOA和领域驱动设计的书之后再来看这两章。但是从这本书其他部分来说，我认为很多话都是类似于废话，很多东西明明是软件工程中很基础的理论，还有一些就像<反模式>那本书一样，提到的都是我们大家都能想到的办法。最后，还是那句话，我不质疑，也没有权利，没有能力去质疑这些我所尊敬的大牛们的看法和文章，也许是我水平所限。等到过段时间我再回来读下吧，希望会有新的收获。

思考尚可，沉思不必

首先承认我读得比较快。在一个炎热的午后，等着钟点工阿姨帮我把家里打扫干净的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)，大笑一声，不予置评。；）

很薄的一本文集

这本书非常薄, 里面的作者却不少, 来自thoughtworks的各个层面, 其中心就是围绕敏捷这个东西在说事儿, 没有必要从头看到尾, 各取所需吧. 比如对我来说, 只有"对象健身操"这一章勉强是看完了的.

评《软件开发沉思录Thought Works文集》

全部评论的地址：http://blog.sina.com.cn/s/blog_58f26c070100glhn.html推荐给做软件的朋友们。这是一本技术比较强的书，涉及了许多软件方面的术语和知识，甚至需要读懂程序代码，才能看明白某些章节。建议看此书之前，先对软件项目的敏捷开发有一定的了解。……