Build To Win

很早以前就想写篇长书评来致敬邹欣老师、周筠老师的编辑团队以及这本书。今日又翻开构建之法，忽觉自己亏欠这本书一个公正的评价，做事情不能虎头蛇尾，所以特地赶来写这豆瓣上的第一篇书评。

我想我是有必要来写这篇书评的，不仅是为了让更多人认识到构建之法本身的价值，更深层次的原因是：我是这本书所探讨的软工改革模式下的一位体验者，也是一名大大的受益者。我希望通过我上这门课的切身体会，打消那些还在犹豫是否要改革软工教学的老师们的顾虑。【我是北航计算机学院的学生，个人博客主页：http://cnblogs.com/SivilTaram，团队博客主页：http://cnblogs.com/buaase，这些都是软件工程课及构建之法带来的收获与成长】

首先对这本书给一个自己的评分，如果满分是10分的话，我给这本书9.5分。

我读这本书的历程和大多数人不同，我是通过`软件工程课`认识这本书的。开课第一周，老师要求略读一遍构建之法。当时自己偷懒，其实没读完，大致翻了翻。翻看粗读后，感受就像部分书评里说的：
1. 这不是一本传统的教材，没那么多晦涩的概念
2. 排版挺好看的，文章穿插图表，很精致

其他感受？当时并没有细致去读，其实感受不是很深刻。只是觉得为什么软件工程里还会有这么多方法，软件工程不就是一些人合作做个项目就好了嘛？但现实远远没有想象的那么简单。团队项目刚开始时，老师要求进行典型用户的场景分析。为了做好用户的需求分析，作为项目PM的我仔细读了《构建之法》的第8章（需求分析）和第10章（典型用户和场景）。

第10章提出的典型用户和典型场景，尤其是关于典型用户的分析那一部分，讲得非常精彩！规格说明书(Spec)绝不是用来摆放的花瓶，它督促着一个团队对一个产品、一个项目的全方位思考。比如我们第一轮迭代启程会议时大家提出的若干个需求，在场景分析后删删改改成为了两个真正的刚需，后面产品的上线与使用的人数也映证了当初需求的化繁为简是多么明智。场景分析的过程是一次产品典型用户的反思过程，能让开发者真正从用户的角度思考一个产品的价值，这是以往的软件工程理论所不曾强调的。

与本书提倡的实践理念形成鲜明对比的是，传统的软件工程课只写需求文档，不做实践项目，不做产品运营和推广。但是，一个项目连用户都没有，又何来用户需求之说？而构建之法所提倡的实践软件工程的模式，文档是实实在在地发挥了作用。以前做过的课程设计大作业，都是先写代码，再写文档，居然是实验指导文档（笑）。而在构建之法中，第一次体会到团队项目中设计与架构的重要性——文档就是设计的蓝图啊！横向对比其他团队项目，在文档中投入的精力越多，整个团队项目的配合就越好，最终在"市场"上的赢面就越大。

起初为了做好项目经理，仔细翻阅了第9章的内容。完整地体验过项目的两轮迭代后，书中提到的“PM和风险管理”一节引起了我深深的共鸣。风险是一定会有的，如何缓和、预估甚至是将风险转换为机遇，在书中都有具体例子佐证。项目经理就是那划船的舵手，虽然他不“赤膊上阵”，但他是团队节奏的核心。是一盘散沙还是一只拳头？PM是关键。

构建之法跟代码大全的结构很像，每一章都是独立的子章节，并且涵盖了测试、项目经理、开发人员、用户体验等多个方面。个人来说比较喜欢这种风格，可以在合适的时候随时温习自己想看的一部分。即使本书涵盖软件工程很多领域，但每一章都值得精读，配合实际项目中的实际角色扮演效果更佳。

相比其他章节而言，个人最喜欢9、10、17章。同时，每个章节最后的练习与讨论是一堂丰富的扩展课，有非常好的资源。【唯一略感缺憾的是实体书每章最后所附的链接略显多余。如果可以按照较好的排版，将参考链接单独取出，排版好置于统一的网页上，再给出一个总链接，那样更方便读者浏览：）】。另外，如果能针对每一次的讨论和练习，让大家在网上有一个专门讨论探讨的地方是不是更好呢？

总而言之，构建之法是一本产生于实践（邹老师的多年工程经验与教学方式的结合）并应用于实践（结合书上课的人都会有很多的软工实践）的书，比现在很多只讲框架不讲细节，只讲理论的软件工程理论书棒得多。可作床头书常读，常读常收获 ：） 期待第三版！