读构建之法，打持久之战

（原文写于2016年5月14日，有删减）

“软件领域可以分为两个方面：一方面是技艺创新的大爆发；另一方面是坚持不懈的工程工作，包括软件的改善、维护和测试等，这一方面占了90% - 95%的比例。”

—瓦茨·汉弗雷 / 软件工程的奠基人之一

遇见《构建之法》，实属偶然。2015年初的某个上午，刚到公司，发现位置上多了一本书，说是公司发的。这本书的全称是《构建之法 — 现代软件工程》，封面设计得很朴素，但作者吸引了我。在念大学的时候就开始在微博上关注邹欣老师，他是微软Windows中国工程团队首席研发总监。

第一次翻开《构建之法》，真的是眼前一亮，这本书与国内高校常规的软件工程教材有本质的不同，这本书写得跟小说似的，而且语言幽默风趣，颠覆了传统软件工程教材刻板生硬、枯燥乏味的形象。相较之下，这本书显得清新脱俗。

01

—

其实这是一本小说

“阿超”、“小飞”、“果冻”、“小李”都是现实中典型的软件行业从业人员形象。每家公司都能见到这几类人，作者根据他们的特点而虚构的人物，很容易让读者产生强烈的代入感，很容易入戏。

当作者提出一个具有争议或让人困惑的观点时，会通过文中虚构的人物来提出读者可能的疑问，并通过对话的形式，给出作者自己的见解。

例如以下场景。

项目接近尾声时，要确保（修复）门槛越来越高。今天的“Must”必须比昨天及以前的“No”严重性高，这样才能不断提高系统的稳定性。

小飞：这个“Bug bar越来越高，事实上是说有更多的Bug会留在软件中，这是不是意味着在最后关头忽略质量。

作者随即借”阿超“之口，说出了自己的看法。这种自问自答的对话场景贯穿全书。

提升Bug bar是放走一些无伤大雅的Bug，换取项目能如期完成。其指导思想是抓大放小，既然没法全解决，就集中精力解决最重要的Bug。避免频繁地到处改动代码而引入新的Bug，是以谓之”稳定“。但是，我们还是会研究”为什么在产品后期才发现这样的Bug？早干什么去了”。这些问题会成为我们“事后诸葛亮”会议的议题。

在第10章中提到的如何定义典型用户和典型场景，以及从典型用户到场景，从场景到任务的过程。作者在写书的过程中，也恰恰使用了这套方法论。

有了典型用户之后，我们还得决定每一个典型用户的目标 — 他/她使用系统想要达到什么目的。对于每一个目标，列出达到目标所必须经历的过程，这就是场景，也可以叫故事。

“阿超”、“小飞”就是《构建之法》这本书的典型用户，他们之间的对话就是现实中许多工程师在工作中会遇到的场景，这是“从典型用户到场景”。

场景怎么写？首先针对每一个场景，设计一个场景入口（描述场景如何开始），接着描述典型用户在这个场景中所处的内部和外部环境（内部环境指心理因素等），然后给场景划分优先级，按优先级排序写场景。

作者借书中角色之口，说出了工程师们在遇到问题时的困惑，以及思维方式，并对他们在当前场景中的心理活动进行了幽默风趣的刻画。

小飞：超总，我想提一个和我职业发展有关的问题。我们接受的可都是科班的软件工程教育，我们当时的院领导说我们毕业后都是要朝CTO发展的，至少是软件金领，我当然知道这是遥远的将来的事，但是我总觉得我至少可以做一个软件白领吧，这些构建之类的事情，嘿嘿，是不是要由所谓的软件蓝领来做？

阿超：问题提得好......

他望着这位将来的CTO、软件金领，突然想抄起身边的塑料水桶，把水都从他的白领里灌进去。他喝了一大口水，退到窗边，勉强把这个念头压了下去。

阿超：我觉得大学的软件工程课，本来要教全面的技术，但是考试往往只考定点投篮和无防守情况下的配合......（以前面的篮球考试为例切入）。

我不禁感慨，不会写小说的程序员不是好编剧。然后，作者再给出他的看法以及一套解决方案，应该怎样解决这些问题，这是“从场景到任务”。

02

—

谁最适合看《构建之法》

本书作为软件工程课的教材很实用，可以让学生一开始就接受“正规军”的系统训练。但是，如果学生没有足够的代码量和工程经验，对里面所讲的很多问题并不会有太多的切身体会，可能很难深刻理解。

我认为《构建之法》最适合有一定代码量积累和经验的人阅读，尤其是在做项目过程中，时常感到困惑的一线工程师，或者是面对一个庞大的软件项目开发任务而感觉力不从心，无力掌控的负责人。此时，这本书就能帮助读者“理论结合实际”，发挥它最大的功效。

但这并不代表不适合缺乏软件经验的人看，这部分读者把它当成是一本趣味性强的“软件工程导论”也未尝不可，对相关的软件工程概念有个印象，先在心里“播下一颗种子”，未来在成长到一定阶段再来反复精读，在实践过程中慢慢体会，“做中学”，这颗种子便会生根发芽，开花结果。

比方说书中提到的一些估算工作量的方法，例如“Y=X±(X÷N)”。

对于刚接触这些估算方法的读者而言，觉得这公式很玄，不知道是否靠谱，只能先了解个大概，以后在自己的实际工作中去体会，去把握。第一次估算不准，多估算几次，从而形成自己的一套关于工作量估算的方法论。

对于书中第6章提到的敏捷开发也是一样。以下是敏捷开发的一种定义。

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用的状态。

什么时候该使用“敏捷开发”，还是“瀑布模型”？设计的时候是“自顶向下”呢，还是“自底向上”呢？这些都不是绝对的，需要根据实际的项目情况，去分析，去拿捏，更多时候是多种方式结合使用。

软件工程不是单一的学科，它是多学科交叉的一门综合学科。除了要具备工程能力外，还要有良好的基础知识，和一定的架构设计能力，以及必要的沟通能力，不然无法掌控一个大型的软件项目。

03

—

适用范围

在软件领域的各种角色其实都适合看这本书，例如软件工程师、硬件工程师、项目管理工程师、测试工程师、产品经理、研发经理等，每个人从自己的角度切入，可以让一个项目团队中的不同角色了解其他人的工作内容和职业特质，让大家在同一个“知识体系”内，或者说在同一个“话语体系”内，避免出现“鸡同鸭讲”的情况，减少不必要的沟通成本。

例如，第5章的“团队和流程”中，提到了足球团队。足球团队从一开始的一窝蜂抢球演变到后来有明确分工、阵型、战术的团队，软件团队也是如此。其他领域的团队是不是也有“主治医师模式”、“明星模式”、“社区模式”、“业余剧团模式”、“秘密团队”、“特工团队”、“交响乐团模式”、“爵士乐模式”、“功能团队模式”、“官僚模式”呢？

第10章的“典型用户和场景”、第12章的“用户体验”，这同样适合产品经理阅读。如何定义用户、如何定义场景、如何写功能说明书，这不就是互联网公司产品经理的日常吗？

第6章的“敏捷流程”、第7章的“MSF（微软解决方案框架）”，对其他工程领域也有一定的借鉴价值。

第17章的“人、绩效和职业道德”适合管理者阅读。

在项目开发过程中，由人组成的这个集合会慢慢演变出五类人。P = 。

中药组方的原则叫“君臣佐使”，“君主”、“臣僚”、“僚佐”、“使者”四种角色分别起着不同的作用。

针对病因或主症的主要药物为“君”，辅助主药发挥作用的药物为“臣”，治疗兼症或消除主药副作用的药物为“佐”，引药直达病所或起调和诸药作用的药物为“使”。

“君臣佐使”，让合适的人在合适的时机出现在合适的位置上。当然，“合适的人”和“合适的位置”也是在动态变化，P1/P2/P3/P4/P5并不会一成不变。

这一章节作者通过对一些常见绩效管理的反思，例如，比工作量/比资历/大锅饭/比效率/背靠背评比，介绍了一种二维的评价体系来区别对待。

这是一本探讨方法论的书，既然是方法论，那其适用范围就绝不仅限于软件工程。作者从其他方面去与软件工程中的相关知识作比较，看似说的是软件工程，但其探讨的方法论也是适用于其他领域的。其他行业也可根据书中提到的方法论，实现"1+1>2"的效果。

本书每章节后的参考文献链接也可作为继续深入学习的“索引”，帮助读者完成“主题阅读”。这些参考文献链接可以帮助读者强化对各章节的理解能力，而且参考文献涵盖的面儿比较广，并不全是深奥的理论，也包括技术博客、相关话题的新闻、软件发展史或行业史上的奇闻轶事等。

这本书有些链接是作者自己的技术博客，里面有作者在北航教授软件工程课程的讲义，成书过程绝非一蹴而就，作者从09年开始在北航开设《现代软件工程》这门课，清楚国内软件工程教学的现状，因为有长期的教学实践经验，能够抓住学生们的“痛点”，并结合了自己多年的研发经验，让这本书更接地气。

《构建之法》读后感

（原文写于2015年2月1日）

之前一直有在微博上关注邹老师，最近有幸拜读了《构建之法》，自知水平不足，不能对这本书提出有见地的意见，只能结合自身的工作经历，写点读后感，聊聊自己在工作中的一些感受。不算是书评，以后再更详细地评论这本书。

我是网络工程专业毕业的，业余时间喜欢研究Linux内核中的面向对象思想和设计模式，喜欢玩硬件，还有不能自拔的“工匠情怀”，所以毕业后，工作在嵌入式领域，希望“软硬兼施”。

一．背景差异

该领域的一线工程师与互联网行业有很大的不同。嵌入式领域的工程师主要是电子类专业毕业的，例如，电子信息科学与技术，电子信息工程，通信工程等专业。在本科期间，在校课程并不一定开设软件工程这门课，即使开设，也不会受到重视（勤奋好学，目标明确的同学不在此讨论范围内），而且很多嵌入式设备的代码量并不大。因此，很多电类学生在写程序的时候，其实是没有“框架”这个概念的，很多程序可能就是封装几个寄存器操作函数，然后开始写程序，写到哪儿算哪儿，软件“腐烂”得很快，接手这种代码的第一感觉就是必须重构了它。于是，吃了很多亏，才开始琢磨是否可以“复用”一些代码，开始注意“功能”复用，接着“框架”复用，“模型”复用。

这些意识上的转变对于电类的学生来说，需要很长的时间，而且他们的代码量不够，没有吃过足够的亏，但是，这不能成为不重视软件思想的理由。任何涉及到软件开发的岗位，都必须有软件思想去指导实际工作。

二．“设计文档没可能写得那么细的”

这句话在很多小型的电子公司中，经常能听见。不少软件项目负责人并不重视项目初始阶段的软件详细设计文档，只是写个大概，更像是为了证明自己是“正规军”，而走走过场。很多主导一款嵌入式设备软件开发项目的负责人，其本人并不是一个优秀的程序员，无法真正把需求转换成相应的软件模型，无法很好地进行抽象。

在一个项目的开发过程中，需求分析，把需求抽象成相应的软件模型，思考使用哪种设计模式，框架代码如何拥抱变化。软件工程师不能阻止需求的改变，只能最大限度地拥抱它。软件应做到在只修改配置文件的基础上自由地扩展和裁剪功能。这些是需要在团队动手之前想好的，否则后期会很难受，尤其在项目进度压力大的情况下，一个需求的扩展可能就搞得整个团队紧张兮兮。

三．在战争中学习战争

我最近在主导一个功率计的软件开发，时间非常紧。有点像书中关于“团队”模式中所提到的“主治医师模式”，我通过与非软件的同事反复确认需求说明书中的条款，避免因表述不清而出现歧义，并转换成软件设计文档，文档中包括对需求的解读，如何用软件抽象该需求，软件模型是怎样的，框架设计细节。最终，使用C语言写了个MVC模型（C语言也是面向对象的，好不好），采用“分而治之”的思路，并把繁琐的逻辑拆分成独立的“插件”，逐个击破，通过配置文件决定是否调用某个“插件”的构造函数，实现“插件”的可插拔。

软件工程中的团队模式与足球中的战术体系，在本质上是一样的，谁动不动就强调他的个人能力，那么他一定不懂得配合队友，这是意识的问题。为了不断提高自己的水平，突破自身的瓶颈，我采用“做中学”的态度，结合《构建之法》中的原理，指导自己的开发工作，效率提升得很快。《构建之法》之于现在的我，就像《论持久战》之于抗战初期的中共，具有绝对的指导意义。