夜雨聆风
软件代码应何时受控?
当我们设计一个软件生命周期模型时，经常会要考虑一个问题：代码应当在何时受控。是在代码编写完成时？是在代码通过单元测试后？是在代码通过集成测试后？还是在代码通过配置项测试后？
基于我们对受控库的认知，凡是纳入受控库的工作产品都应当具备一定的质量水平，都是“可用”的。
在实操当中，我们使纳入受控为的工作产品是“可用”的做法通常是：对于文档产品来说，就是要通过评审；对于代码来说呢，就是要通过测试。
如果按照这个理论来说，代码受控应当在代码完成配置项测试，至少要完成单元测试才能入库受控。
但是，这个理论是有问题的。
因为使代码“可用”，并非只有测试一种方法。代码评审、构建都可以完成这一功能。
同样的，文档产品也并非只有评审一种途径来确保可用，如果使用形式化语言描述文档，那我们也可以通过形式化验证来确保文档可用。
在GJB5000A的配置管理过程域专用实践1.3中，是这样描述基线的：
基线是一组经过正式评审同意后，作为进一步开发或交付基础的规格说明或工作产品。
这里只是强调经过“正式评审”，并没有说需要经过“测试”。
这个专用实践中还有一句话，也能说明确保“可用”不需要进行测试：
随着产品的演进，可以使用多个基线控制其开发和测试。
既然入库的基线产品是用来控制开发和测试的，那它本身也就不是一定已经通过测试的产品。
所以，代码不需要通过测试后再入库受控。
那么，代码究竟应该何时受控呢？
其实，“三库”的概念只是存在于一个国家军用标准GJB 5716-2006《军用软件开发库、受控库和产品库通用要求》中，在CMMI或GJB5000A中并没有三库的概念，只有版本管理和基线的概念。我们讨论代码受控时机，实际上是讨论代码基线生成发布的时机。而软件的开发一般是编码完成后，要进行代码构建，再进行代码集成，集成后就可以给代码打上基线，以供后续软件开发和测试来使用。
这与GJB5000A配置管理过程域专用实践1.3中所描述的“使用多个基线控制开发和测试”的场景是一致的。
而代码的“可用”，是通过集成前各个部件构建成功，部件集成后也能成功构建，以此来实现的。这里的构建包括了编译、链接、添加资源文件（根据情况，有时也包含自动化测试）。所以构建的过程也是排队代码错误的过程，构建成功即意味着代码“可用”。
这个“可用”并不是交付给用户去用，而是作为新的开发和测试的基线。
如果项目资源充足，时间充裕，当然可以按部就班地完成单元测试、集成测试后再打基线（或者说受控），但如果正好相反，那么就需要将编码、构建、集成、测试这些活动并行起来进行，打基线（或者说受控）的时机就要适当提前。
软件代码应何时受控，归根结底还是取决于项目需要。
这正是：
代码受控不纠结，受控目的要了解
控制开发和测试，时机按需可调节
参考书目：《软件集成策略——如何有效率地提升质量》，董越，工业出版社
