构建之法阅读笔记06

　　我的比喻可能不是很恰当，但是，假如把我们平时做的作业看作是一个软件项目的话。

那么，以前，我通常都会把一个作业一直做到对为止，甚至有的时候，如果我觉得我做的不对的话，我都不会去交作业。

但是，正常情况下，我们应该是适当的把握作业的重点，把重点先完成，提交出去，然后，

以后在稍作修改。我感觉这样是很好的。总不能为了达到自己的预想，而连作业都不交。

　　同理，运用于软件工程就是，当一个软件项目快接近尾声的时候，我们如果还没有完成预定的任务的话，那么，

我们是把项目交给用户，还是不交给用户呢？

　　在现实中，答案是当然的。

　　做软件的目的，不过就是完成用户的需求，提交给他们想要的软件。

　　也许有很多公司在规定时间到来的时候，仍然有很多的任务没有完成，那么，这个软件到底是发布还是不发布。

所以在探讨这个问题之前，我们需要首先介绍几个名词。

Alpha:集成了主要功能的第一个试用版本，多数在内部使用。

Beta:功能基本完备，稳定性相对Alpha来说有所提高，适合小范围使用

ZBB：某天的版本要把之前的Bug都解决掉

RC:发布候选版本

RTM：最终发布版本

通常情况下，软件团队的各个角色代表组成了会诊小组，处理每一个影响产品发布的问题。

　　对于每一个Bug,会诊小组要决定采取下面哪一种行动：修复：小组同意修复这一问题。

设计本来如此：用户或测试人员可能对功能有误解，或者功能的解释不完备。
不修复：这是一个问题，但是这个软件版本不打算修复
推迟：如果我们的软件是真正解决用户问题的，是有价值的，那它一定会有下一个版本。
　　

　　除了有会诊小组之外，对于复杂的项目，还有复杂项目的会诊。会诊会议也会有更高的要求，包括一下三个方面：
1.开发者提交参加会诊的Bug和修改方案
2.会议决定是否统一修改方案
3.执行
当发布Alpha/Beta之后，通常我们会收到很多用户的反馈，我们会发现，原来的设计也有不少要改进的地方。
于是乎，很多人会嚷嚷着DCR，那么DCR该怎么提出呢？说明：
1.问题在哪里，问题的影响；
2.如果不修改，会有什么后果
3.几种修改方案，各种方案的优缺点和成本。
作为一个软件团队，我们要有解决Bug的能力，其中有一个招数叫做ZBB，即这一版本的构建把所有已知的Bug都解决掉了。
在项目临近结束的时候，所有人员都要回归测试所有的Bug。每个人都要帮助团队确保这些Bug的确是被修复了，而且别的更改没有导致功能的“回归”。
当然，如果一个模块不能够实现预期的设计需求，时间快到了，怎么办？
一个字：砍！
随着程序功能的完善，我们要让程序的各个方面有次序地“冻结”，这样才能把稳定的软件交付给用户。
发布之后，我们要总结经验教训，我们需要对整个软件的开发过程进行解剖，这个过程叫做：事后诸葛亮会议