软件开发的规模扩大并不是像“拿一个小项目来，然后增大它的每一部分”那样简单。如果要开发大型软件，就必须了解软件规模对构建的影响。此外，本文将记录与构建直接相关的一些特定管理问题。如果你是一名开发人员，本文将帮助你了解管理者需要考虑的一些问题；如果你是一名管理者，本文将帮助你了解开发人员是如何看待管理者的，以及如何才能有效地管理构建。

1. 程序规模对构建的影响

• 成员交流与项目规模的关系：交流路径越多，花在交流上的时间就越多（见下图），因交流而出错的机会也就越大，改善交流效率的常用方法是采用正式的文挡
  • 
• 项目规模对错误的影响：在小项目中，构建错误大约占所有被发现错误的75%，在更大的项目中，构建错误占错误总数的比例逐步下降到50%左右，而需求错误和架构错误则弥补了其中差额。缺陷密度（每1000行代码所包含的缺陷数量）会随项目规模增大而增加
• 顶目规模对生产率的影响：小项目的生产率会比大项目高出2至3倍，并且最小的项目和最大的项目的生产率差距可能达到5到10倍之巨
• 顶目规模对开发活动的影响：对小型项目，构建占差不多65%的开发实践，随着项目规模增大，构建的比重逐渐减小，架构、设计、集成和测试占更多时间

2. 管理构建

2.1 鼓励良好的编码实践

从管理的角度出发，强制采用一套严格的技术标准并不是个好主意。如果项目中有人要制定标准，那么应该由一位受人尊敬的架构师来做，而不应该由管理者来做。下面给出一些编码实践，这些实践比呆板的编码标准更容易实行：

• 给项目的每一部分分派两个人：结对编程，导师带学生等等
• 同行复查代码：包括程序员本人和至少两名评审员的复查，可以为改善代码质量提供压力
• 要求代码签名：在认定代码完成之前，高级技术人员要在代码清单上签字
• 安排一些好的代码示例供人参考
• 强调代码是公有财产
• 奖励好代码：给予程序员想要的奖励，只有非常出色的代码才应得到奖励

2.2 配置管理

配置管理即“变更控制”。如果你不对需求变更加以控制，那么就会为系统中某些最终会被去除的部件编写代码，也会去写出一些可能与系统中新的部件不兼容的代码；可能会修改某个别人也正在修改的子程序，把两个人的改动合并导致出现问题。总之，配置管理就是使用评估提交的更改、追踪更改、保留系统在不同时间点的历史版本等等技术来对软件项目的变化进行控制。

• 需求变更和设计变更
  • 遵循某种系统化的变更控制手续
  • 成组地处理变更请求：先记下所有的想法和建议，直到有时间再去整体处理它们，以防总是在中途突然变卦
  • 评估每项变更的成本：重新设计和编码，修改用户文档，评估代码复查，重新测试等等各种时间成本
  • 提防大量的变更请求：有时这可能是一个表明需求、架构或上层设计做的不够好导致无法支持变更的警报
  • 成立变更控制委员会或者类似机构
  • 警惕官僚主义，但也不要因为害怕官僚主义而排斥有效的变更控制
• 软件代码变更：使用合适的版本控制软件
• 工具版本：可能有些项目需要“重新构造出‘创建软件的各个特定版本’的原样环境”的能力，这时需要把编译器、链接器、代码库等也纳入版本控制中
• 机器配置：使用标准化的开发机器配置和操作系统映像，可以省掉许多开发前配置的麻烦
• 备份计划：项目过程中应定期备份代码、文档、图表以及保存介质；要测试备份过程，确保所需的全部数据能正确恢复；昨晚项目后及时归档

2.3 评估构建进度

对于项目预估进度和实际进度，有调查表明，开发人员的估计值比实际值要乐观20%~30%。评估项目规模的方法有很多种，例如使用评估软件，使用算法方法，聘请外界的评估专家，评估项目的每一部分并加起来等等。下面是一套评估项目的参考原则：

• 建立目标：理清评估的目的、内容、准确度、乐观评估和悲观评估结果等
• 为评估留出时间，并且做出计划
• 清楚地说明软件需求
• 在底层细节层面（划分为多个小块并分别）进行评估
• 使用若干不同的评估方法，并且比较其结果
• 在项目推进过程中定期做重新评估

为了按时完成软件项目而做的“计划”中，评估是很重要的组成部分。然而，最初评估的准确度的重要性远远比不上“随后为了完成进度而成功地控制资源”的重要性。如果项目进度落后了，人们经常会产生一些错觉：“我们后面一定会加班加点把时间补回来”，调查显示越接近项目后期，延误和超支的现象就越严重；“扩充团队来加速开发”，新手需要先花时间熟悉项目，占用现有人员的培训时间，然后才能发挥出生产率，而且仅仅增加人员数量，会导致项目交流的复杂度和数量增加，除非项目的任务是可分割的才能通过增加人手完成。

缩减项目范围是在进度落后时的有效手段。最初做产品计划的时候，要把产品的功能划分成“必须有”、“有了更好”和“可选择”三类。如果进度落后了，那么就调整“可选择”和“有了更好”的优先级，并扔掉那些最不重要的功能。

2.4 把程序员当人看

首先要了解程序员的时间分配。研究表明一个程序员大约有30%的时间花费在“对项目没有直接好处”的非技术活动之上：步行、个人事务等，学习和编写代码占约30%。

其次是了解程序员的信仰问题。这些信仰涉及编程语言、编码风格、编程工具、编程方法论等等。作为一个管理者，要清楚地知道信仰是一个敏感的问题，对这些领域要使用“建议”或者“指导原则”（避免僵硬的“规则”或“标准”），并让程序员们制定他们自己的标准。当然，如果有人因可读性差等影响整个项目的实践行为，为了提高代码质量，不要怕引发一些摩擦。

最后，要了解物理环境对程序员生产率有着巨大的影响。这些环境包括桌子、椅子、电脑、书籍、键盘，以及办公氛围、不经常被打扰的环境等等。如果你的工作环境属于最差的那25%，那么你有机会给生产率带来100%的提升，办法是把环境改善为最佳的那25%。

2.5 管理你的管理者

在软件开发中，如果你需要面对非技术出身的管理者，你可能要肩负起“管理你的管理者”的责任。其要点在于，你要表现得使你的管理者认为他仍然在管理你。有这么一些应对管理者的方法：把你希望做什么的念头先藏起来，等着你的管理者组织一场有关你希望什么的头脑风暴/集体讨论；把做事情的正确方法传授给你的管理者；关注你的管理者的兴趣，按照他的真正意图去做；拒绝按照你的管理者所说的去做，坚持用正确的方法做自己的事；换工作。

参考文献：电子工业出版社《代码大全（第2版）》第27、28章

上一篇：软件构建（十三）——代码集成

下一篇：软件构建（十一）——代码性能的调整