《构建之法》稳定和发布阶段
从代码完成到发布
一个团队经历了计划/设计/开发等阶段，达成代码完成（Code Complete）这一目标，似乎后面的事情就水到渠成了。其实不然，软件生命周期的最后阶段往往是最考验团队的，不但考验团队项目管理水平、应变能力，也考验团队的“血型”。原计划的软件发布时间快到了，但是软件还是有各种问题，怎么办？
软件团队的血型
优秀的软件团队会发布有已知缺陷的软件么？在我看来，与人类的血型类似，软件团队也有“血型”，也可以分4种。
A型：他们知道优秀的软件公司会发布有已知缺陷的软件
B型：他们不相信这一点
O型：他们不知道这一点，因此嘴巴惊讶成O型
AB型：他们对于自己开发的软件是A型，对于别人开发的软件是B型
说到“质量”，我们不提“全面质量管理”，因为大家都讲“全面质量管理”，往往意味着我们的质量管理没有抓到点子上。而且有些庸人往往会以“高质量”为由，阻碍正常的工作进程。而那些口口声声要求“高质量”的人士，往往是出于下列情况。
缺乏对用户、行业、软件开发的洞察力，对于“高质量”并没有具体的定义
没有具体的招数让软件达到所谓的“高质量”
害怕真实世界的反馈，因此不发布软件，能拖一天是一天
那么，从软件的代码完成（Code Complete）到最后发布，我们要经历哪些步骤，有哪些招数让我们能以比较大的共识、比较小的痛苦走完这“血腥”的流程，需要什么样血型的团队才能按时推出优秀软件？我们先来看看一些常用的名词。
Alpha：指集成了主要功能的第一个试用版本。在这个版本中有些小功能并未实现。事实上很多软件的Alpha版本只是在内部使用。给外部用户使用的Alpha版本会起一个比较美妙的名字，例如，技术预览版（Tech-nical Preview），等等
Beta： 功能基本完备，稳定性较Alpha版本高，用户可以在实际工作中小范围使用，可以有Beta1、Beta2、Beta3……
ZBB（Zero Bug Build）：某天的版本要把在之前（例如48小时前）记录的Bug都解决掉
RC（Release Candidate）：发布候选版本，RC1、RC2……直到RTM为止，版本间隔时间较短
RTM（Release To Manufacturer）：最终发布版本。如果某一个RC版本没有很大的问题，那么这一RC就会成为最终的版本，通常情况下，软件公司会把最终的版本和相关的文件及其他资料交给另一个团队（Manu-facturer）去包装、刻制光盘。在AppStore/Marketplace的年代，我们有相应的RTM（Release To Market）
RTW（Release To Web）：和RTM类似，对于网络应用来说，我们无须依赖“Manufacturer/Market”制作软件的光盘或者管理软件的发布渠道，但是要依赖“Web”来发布我们的最终版本。如果软件产品是一个网站服务，则一般会交给网站运营团队（Opera-tion Team）去管理，这样的发布也可以叫做RTO（Release To Operation），运营团队和研发团队一起决定什么时候系统上线（Go Live）。把软件提交到各个应用商店则可以称为Release To Store
会诊小组（Triage Team）
软件团队的各个角色代表（PM/Dev/Test/UX等）组成了会诊小组，处理每一个影响产品发布的问题。打个比方，就像医院的门诊或急诊室（TriageRoom），一下子涌入很多病人，但是医院里人手和设备有限，值班的医生护士要根据病人的情况安排不同的处理方法。另一个场景类似但更为紧急，在战地医院里，两次战斗的间隙，医护人员冲上硝烟尚未散尽的战场搜救伤员，有些做简单包扎即可，有些要抬担架，有些伤情太重的，只好放下不管了。大家的血型和勇气在这一次次的会诊中得到了展现。下面的招数都是在会诊小组的领导下进行的。对于每一个Bug，会诊小组要决定采取下面哪一种行动：
修复
设计本来如此（As Designed）//用户或测试人员可能对功能有误解，或者功能的解释不完备
不修复（Won’t Fix）//这是一个问题，但是这个软件版本不打算修复
推迟（Postpone）//如果我们的软件是真正解决用户问题的，是有价值的，那它一定会有下一个版本
在大型复杂项目中，软件团队还会进行更为复杂的会诊工作。
当临近发布时，我们需要对项目整体进行规划，这时，可以用用这几招！
招数：最后回归测试
项目临近结束时，所有人员（开发、管理、测试）都要回归测试所有的Bug。每个人都要帮助团队确保这些Bug的确是被修复了，而且别的更改没有导致功能的“回归”。为便于管理，我们可以考虑新增一个字段，标记某个Bug已做过回归测试。
招数：砍掉功能
有一个模块看来不能实现预期的设计需求，时间快到了，怎么办？砍！这是因为“沉没成本”（Sunk Cost）
如果类似的功能需要N个单位时间才能最终完成，那么我们没有理由相信新功能会花少于N个单位时间。我们再回顾一下以前看过的功能/资源/时间的平衡图，我们要不断保持这些因素的平衡：
招数：修复Bug的门槛逐渐提高
在Beta期间，修复Bug的门槛要逐渐提高，昨天修复了同类的Bug，今天如果还找到了类似的问题，团队未必要修复。在RC阶段，只有影响巨大的Bug才能修复。其他优先级较低的Bug就只好在一边等着。如果有严重的Bug要修复，那么这些不严重的Bug也许有机会跟着一起修复。
在Alpha阶段，如果开发人员拿到一个Bug，那他/她就可以马上去修复，只是在签入之后告诉大家做了什么样的修改。
在Beta阶段，在新代码签入之前，就要告诉会诊小组这个修改潜在的风险是什么，如何应对，等等。
在RC阶段，开发人员在拿到Bug进行修复工作之前，就要和会诊小组沟通，看看这个Bug是否值得花时间。
招数：逐步冻结
随着程序功能的完善，我们要让程序的各个方面有次序地“冻结”，这样才能把稳定的软件交付给用户。一般来说，程序的人机交互界面最先开始“冻结”，不能再随意修改，因为很多项目的文字信息要被本地化成多种语言，只有人机界面所用的文字和布局固定后，我们才能把这些文字交给负责本地化的部门。随着时间的推移，一些功能也可以“冻结”，这些功能都经过全面测试，所有的Bug都解决了，功能进入稳定状态，在下一个版本前不要再碰与此功能相关的代码。如果有新的功能要加怎么办？那就在当前源代码的基础上创建分支，让当前版本和将来版本的工作分开进行。