第28章 管理构建

本章重点讲述的是与构建相关的软件管理话题。

首先，在一起读这个章节之前，我们可以先来思考一些问题，作者在本书讨论与构建直接相关的管理话题，对于作为开发人员来说，会有些什么作用？那么对于管理者来说，又有什么样的作用呢？

术语阐明

构建活动表示开发中一系列活动，其中包括详细设计、编码、联调、单元测试。

构建管理属于软件管理中的一部分。

28.1 鼓励良好的编码实践

代码是构建活动中最主要的产出，因此，构建管理中一个关键的问题就是 “如何鼓励良好的编码实践”，也就是建立一套编程标准。
（问题2：标准由谁来制定会更容易让程序员们接受？）

鼓励良好的编码实践的技术

• 给项目的每一部分分派两个人：保证代码和可阅读性
• 逐行复查代码：相互review
• 要求代码签名
• 安排一些好的代码示例供人参考
• 强调代码是公有代码：方便别人代码复查和维护

• 奖励好代码

  28.2 配置管理

  什么是配置管理

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

  需求变更和设计变更

  在开发过程中，你一定会有很多关于如何改善系统的想法。如果每产生一个想法就实施相应的变更，那么就会走上软件开发的永无完结之路。
  为了控制，控制设计变更，可以根据以下指导原则：

• 遵循某种系统化的变更控制手续

• 成组地处理变更请求：记录所有想法与建议，然后整理，把最有益的部分变更加以实施
• 评估每项变更的成本
• 提防大量的变更请求
• 成立变更控制委员会或者类似的机构

• 警惕官僚主义，但也不要因为害怕官僚主义而排除有效的变更控制

  软件代码变更

  配置管理的另一项内容是源代码控制。如果你在修改代码后产生一个错误，但这个错误看上去并不是因为你说更改导致的，那为了寻找根源，可以通过使用版本控制软件对新老代码、或者更早的版本源代码进行对比，追溯错误根源。

  工具版本

  使用的工具也需要纳入版本控制之内。

  机器配置

  为公司的标准开发工作站生成一份磁盘映像，如果包含使用的软件、开发工具等。可以避免不同开发者存在开发软件版本不一致等造成的麻烦。

  备用计划

  备用计划指的是定期备用你的工作。这样可以避免一些黑天鹅事件（遭到盗窃、洪水等）发生时，导致资料丢失。做完一个项目后，对项目进行归档，把所有的东西保存下来，然后放到安全的位置。

  28.3 评估构建进度表

  评估项目需要的工作量是项目管理中最具有挑战的方面之一。设计到钱、时间与人。为了可以更加准确地对项目规模和工作量的评估。

  评估方法

  可以使用以下几种合适的方法来对项目规模和完成工作所需的工作量进行评估：

• 使用评估软件（问题3：有什么好的推荐）

• 使用算法方法
• 评估每部分的，然后加起来
• 让每个成员评估各自的任务，然后加起来
• 参考以往的项目经验

下面是一套评估项目的好方法：

• 建立目标：明确评估的目的
• 为评估留出时间，并且作出计划
• 清楚地说明软件需求
• 在底层细节层面进行评估：评估要建立在对项目各项活动做出详细考查的基础之上
• 使用若干个不同的评估方法，并且比较其结果
• 定期做重新评估：

评估构建的工作量

构建能给项目进度造成多大范围的影响，部分取决于“构建”在项目中所占的比例。我们在上一章也介绍过，所占的比例会随着项目以及组织机构的不同而不同，所以需要根据组织的项目经验记录下来，然后来评估未来的项目需要花费的时间。

对进度的影响

度量软件项目有很多种方法。对项目进度影响最大的是所开发的程序规模。但还有很多其他因素也会对软件开发进度造成影响，可以被量化的因素，比如表 28-1 所示：

不可被量化的因素：

• 需求开发者的经验与能力
• 程序员的经验与能力
• 团队的动力
• 管理的质量
• 人员的流动性
• 需求的变更
• 客户的关系质量
• …

以上每一个因素都有可能很重要。

评估与控制

一旦评估确认，随后为了完成进度而成功控制资源（控制人员和技术资源的开销）更重要。

如果落后了该怎么办

如果项目进度出现了滞后，增加时间又不可行怎么办，以下有几个解决方案：

• 希望自己能赶上
• 扩充团队

• 缩小项目范围：去掉一项特性，比如：设计、调试、编写文档工作

  28.4 度量

  对项目进行度量的两项根本原因：任何一项项目特征都是可以用某种方来度量的，而且总会比根本不度量好得多，度量结果也许会不完全精确，也许很难做，而且还需要持续改善结果，但它能使你对软件开发过程进行控制，而如果不度量就根本不可能控制。
  那么我们可以对软件开发过程中的任何环节进行度量。表 28-2 列出了一些其他从业者认为有用的量度。
  
  建议不要一开始就收集全部可能得到的度量数据 — 你将会置身于复杂数据的汪洋大海种，而无法领悟哪怕其中任何意向数据的含义。应当从一组简单的度量数据开始，比如缺陷数量、工作月数、代码总行数等。
  确认收集数据是有理由的。指定目标，确定为了实现这一项目需要问哪些问题，然后再做度量，以此回答这些问题。你问的信息必须是可以获得的，还要记住，项目最后的项目期限永远比收集数据更重要。

  28.5 把程序员当人看

  程序员和管理人员都是人，在把他们当人看的时候工作得最好。
  程序员并非只是于硅芯片打交道得有机物。

  程序员怎样花费时间

  程序员不仅在编程上花费时间，也会花时间去开会、培训、阅读邮件以及纯粹思考。

  性能差异与质量差异

  不同程序员咋天分和努力程度方面得差别十分巨大，这一点与其他所有领域都一样。

  信仰问题

  有一些编程问题与信仰有关。比如以下问题：
  

• 要清楚地知道你是在处理一个敏感得问题

• 对这些领域要使用“建议”或者“指导原则”
• 避免流露明显的意图

• 让程序员们制定他们自己的标准

  物理环境

  物理环境对生产率有着巨大的影响。在一场编程竞赛中，对最好和最差的参赛者所处的办公环境来的差异做出总结：
  
  以上数据线上，在生产力与工作尝试质量之间有着很强的相关性。前25%最优秀的程序员的生成力是后25%最差劲的程序员的2.6倍。

  28.6 管理你的管理者

  如果你的管理者是非技术出生或者有技术但落后于这个时代10年，那你应该怎么应对呢（问题4：你有遇到过这样的管理者吗，你是怎么应对的？）？以下有一些应对管理者的方法：

• 把你希望做什么的念头先藏起来，等着你的管理者组织一场有关你希望什么的头脑风暴/集体讨论。

• 把做事情的正确方法传授你的管理者。
• 关注你的管理者的兴趣，按照他的真正意图去做，而不要用一些不必要的实现细节来分散其注意力。
• 拒绝按照你的管理者所说的去做，坚持用正确的方法做自己的事。
• 换工作

  要点