本周读了本书的第六部分，此部分的主题为系统考虑。本部分分为四个章节，分别描述了程序规模对构建软件的影响，对构建的管理，系统的集成，以及相关的编程工具。

还是老样子，下面对每一章的内容进行简要的摘录。

第二十七章——程序规模对构建的影响

本章开始描述了交流与规模的关系，提出

(Page.650)…二者的关系并不是加性的而是乘性的。即交流路径的条数大致正比于人数的平方。

根据项目规模的不同，会对错误产生不同的影响。

(Page.651)项目的规模既会影响错误的数量，也会影响错误的类型。

坦白说，这句话中所说的项目规模会对错误数量产生影响很自然可以想到，但是说也会影响错误的类型，我之前是没有想到的。

书中谈到项目规模对生产率影响一节时，引用到这样一句话，我觉得对于移动互联网的开发也是蛮适合的。这句话是这样说的

(Page.653)…，完成项目的小型团队的生产率摇臂大型团队高出 39%，那么这些团队各有多少人呢？答案是，小项目两个人，大项目三个人(1984)。

之前看《打造Facebook》那本书的时候，作者提到在 Facebook 内部开发一个新项目，一般人数也很少。例如他自己主导开发的那个项目，一开始也只有三个人。

对于项目规模对开发活动的影响一节中，文中指出

(Page.655)规模相近的项目会执行相似的活动，但是随着项目规模不同，其所需要进行的活动的种类也会有明显的差异。

最后谈论了一下不同级别的规模与方法论之间的关系。其实，本章讲的都比较概括，不过中心思想很明确，主要就是描述了因为程序规模的不同对于构建软件不同方面的影响。

第二十八章——管理构建

本章主要讲了对于软件开发过程中的项目管理。

在编码方面，提出了一些建议，其中对于定制标准方面，书中给出了一条建议，我觉得可以直接用于实践，

(Page.662)如果项目中有人要制定标准，那么应该由一位受人尊敬的架构师来做，而不应该由管理者来做。在软件项目中，“专家层”起的作用至少与“管理层”相同。

其实，像这种直接面向技术层面的问题，管理者或许没有资深的技术人员更专业。对于良好的编码实践要比呆板的标准更容易实行。书中给出了几条建议(Page.662~Page.664)。

• 给项目的每一部分分派两个人
• 逐行复查代码
• 要求代码签名
• 安排一些好的代码示例供人参考
• 强调代码是公有财产
• 奖励好代码
• 一份简单的标准

上面的建议的好处也比较明显，就不展开说了。

接下来讲到配置管理，什么是配置管理？

(Page.664)配置管理是 “系统化地定义项目工件(project arifacts)和处理变化，以使项目一直保持其完整性” 的实践活动。它的另一种说法是“变更控制”。其中的技术包括评估所提交的更改、追踪更改、保留系统在不同时间点的各历史版本。

对于构建过程中需求的变更和设计的变更，书中给出了一种方法是，

(Page.666)…，记下所有的想法和建议，不管它实现起来有多容易。把它记录下来，直到你有时间去处理它们。到那时，把它当做整体(group)来看待，从中选中最有益的一些变更来加以实施。

即便如此，对于软件的变更也会是一大难题。估计很多朋友都在网上看到过一些有趣的漫画，内容大概是项目经理让程序员不停的改动需求，直到程序员崩溃…。书中对此现象的评价说

(Page.667)缺乏规范的变更控制是当今软件业面临的主要管理难题之一。

看来，变更是一个世界性的难题，呵呵。

对于软件代码变更的管理，书中提到了版本管理软件的使用。版本管理软件不但可以有效的管理代码变更，还可以对代码起到备份的作用，不会轻易丢失代码。

对于评估构建的进度方面，书中提到了一些评估项目的方法(Page.671~Page.672)。

• 建立目标
• 为评估留出时间，并且做出计划
• 清楚地说明软件需求
• 在底层细节层面进行评估
• 使用若干不同的评估方法，并且比较其结果
• 定期做重新评估

具体就不展开说了，都比较容易理解。

对于项目进度影响最大的原因是

(Page.674)…所开发的程序的规模。

这一点很容易理解，呵呵。

在度量这一节中，文中提出了对项目进行度量的两个根本原因。

• (Page.677)任何一种项目特征(attribute)都是可以用某种方法来度量的，而且总会比根本不度量好得多。
• (Page.678)反对度量就是认为最好不要去了解项目中到底在发生什么。

其实，关于度量，我自己的理解是，需要有一个大致的标尺来丈量项目的进度，但也不应该过于依赖这种度量，要张弛有度，保证项目不偏离大方向。

本章后面部分讲述了一些管理方面的经验。例如如何和你的管理者沟通等等。其中有很多建议实践性很强，并且针对性也很强，需要有相应的环境为基础，所以在此就不罗列了，没太大意义。

第二十九章——集成

本章讲述了几种软件集成的方式，但各有利弊，无银弹。

对于集成的方式，分为两种：阶段式集成和增量集成。

首先从阶段式集成开始介绍。阶段式集成的另一个名称是“大爆炸集成”。阶段式集成面临的问题，摘用书中的一句话描述，

(Page.691)阶段式集成的一个问题是，当第一次把系统中的类放到一起时，新的问题会不可避免地大量浮现，而问题的成因可能是方方面面的。

书中说，对于

(Page.692)…，对微型程序——而言，阶段式集成或许是最佳方式。

其实也可以看出，阶段式集成非常的不常用。下面介绍增量集成。

在增量集成中，可以一次一块地将程序模块拼接起来。对于增量集成的好处，书中列出了几条(Page.693~Page.694)：

• 易于定位错误
• 及早在项目里取得系统级的成果
• 改善进度的监控
• 改善客户关系
• 更加充分地测试系统中的各个单元
• 能在更短的开发进度计划内建造出整个系统

其实，我感觉这些条条框框基本上也记不太准确，可以作为参考吧。对于增量集成的策略，书中提到了几种，下面一一说明。

自顶向下集成

故名思义，在自顶向下的集成中，首先编写并集成位于层次体系(hierachy)顶部的类。此种策略，除了具有增量集成的一般优点以外，能相对较早地测试系统的控制逻辑，能够在项目早期完成一个能部分工作的系统。

但是除了优点以外，当然还有缺点，在纯粹的自顶向下集成将棘手的系统接口的演练留到最后才进行。书中给出的最终意见是

(Page.696)实现纯粹的自顶向下集成也是近乎不可能的。

自底向上集成

在自底向上的集成中，需要先编写集成位于hierarchy底部的类。关于这种方法的优缺点，书中说

(Page.697)它能讲错误的可能来源限制到“正在被集成的那一个类”上，因此容易定位错误。

但同样，缺点是

(Page.697)它将重要的高层系统接口集成工作留到最后才进行。

三明治集成

关于这种方法，

(Page.698)首先是集成层次体系(hierachy)顶部的高层业务对象(business-object)类。然后集成底部的与设备接口的类和广泛使用的工具类。这些高层类和底层类是三明治的那两片面包。

这种集成方法避免了纯粹的自底向上或自顶向下集成的僵化做法。先集成通常比较棘手的类，降低了后期的风险。

风险导向的集成

风险导向的集成也称为“困难部件优先集成”。它和三明治集成类似，也是趋向于先集成顶层类和底层类，讲中间层类留后处理，但是它们的出发点不同。其实不同点主要就在于，风险导向的集成偏向与先把风险高的部件进行集成。

功能导向的集成

顾名思义，也就是一次集成一项功能。

(Page.701)纯碎的功能导向的集成和纯碎的自顶向下或自底向上集成一样苦难。通常需要先集成某些底层的代码，之后才能集成某些重要的功能。

T—型集成

对于这种集成方法，是选中某个特定的“竖直块/vertical slice”，对它及早开发并进行集成。对于这个功能模块，是从头到尾的进行完成，而且过程中应该能找出系统设计所做的假设中的全部主要问题。这种方法，通常和“风险导向的集成”或“功能导向的集成”结合使用。

本章最后，还提到了两种方法，一种是daily build，另一种是冒烟测试。对于这两种方法就不展开说了。

第三十章——编程工具

从标题也可以看出，本章主要围绕着工具展开，其中包括设计工具、代码管理工具、编程工具等。整个章节大概翻了一下，基本都是介绍性的说明了一下功能，或者是作用等，这里就不多说了，没有太大的意义，因为每个人的工作习惯都不一样，而且随着时间的推移，很多工程上的方法也都在不断的变化，所以感觉这部分没有太大的参考价值。