从卓越工程的角度看微软中国开发团队的成长 (二)

上篇我们讨论卓越工程系统中的人才因素，本篇探讨第二个重要因素——流程。

简捷有效的流程

    人是有思维的、有创造力的，可是在做一些具体事务时却容易出一些低级的错误。这时流程会帮助减少这样的错误来保证产品的质量。流程如果太繁琐会降低效率；没有流程，质量又没法保证。所以要有一个平衡，要建立一套对产品开发最合适的流程也就是简捷有效的流程。我想大家对软件产品开发的周期，例如市场调查、产品需求、计划、产品设计、产品实现、测试、调试、修补漏洞、质量过关、产品发布已有了解，在此不多谈了。我想以产品实现和测试的流程为例来说明这段流程对软件质量保证的重要性。

    我在雷德蒙工作时，曾有个兄弟团队的资深软件开发工程师干过这样一件事。产品开发进入修补漏洞的后期，在这个阶段只有重要的漏洞才能去修补，而且代码提交前要经过伙伴测试（Buddy Test），这样做的目的是要保持产品质量的稳定性，可他过于自信了，在没有经过伙伴测试就把代码提交了。结果他的提交使第二天的每日构建（Daily Build）通不过多个重要的测试用例，兄弟团队也没法儿用它进行其它测试，白白浪费了一天时间。这件事对这位仁兄来说肯定是个教训，也说明流程是有作用的，不按流程做会导致一些影响很坏的错误。

    在开发团队中会有很多软件开发工程师，他们都要提交代码，尽管他们会很认真的编写代码，有时也难免出错。我们常用代码评审（Code Review）这一流程中的重要步骤来保证代码的正确性。一个工程师写的代码会由另一个或几个工程师包括软件开发测试工程师来做复审。这样，代码经过多双眼睛的审核，正确性会较高。有些开发团队会要求软件开发工程师提交代码时，要先把提交放入提交排队系统，这个系统会对每个提交做必要的测试，测试通过后系统才会正式提交代码。经过这样一个流程，代码出错的可能性进一步降低。伙伴测试和提交排队系统有异曲同工之效，都是在代码进入源代码管理控制系统前对提交的代码进行必要的测试来保证代码的正确性。伙伴测试会花费软件开发测试工程师的时间，提交排队系统也需要工程师花时间来维护，各有千秋。我带领的CLR/Silverlight上海团队与相应的美国队伍共拥有七、八十位软件开发工程师，提交代码要通过一个提交排队系统，提交前要经过代码评审。

    另外，也可以采用伙伴构建（Buddy Build）或滚动构建（Rolling Build）。伙伴构建是指一个工程师提交代码前或后由另一工程师帮忙做构建来验证提交代码没有构建问题。滚动构建是由一个计算机系统自动完成的，它周期性地同步源代码管理控制系统中的当前源代码后进行构建验证，也可以自动做一些测试，有问题它会自动发邮件给相关人员。WinForms上海团队组建不久开始建立流程，因为只有几个软件开发工程师，所以正在考虑采用每日构建（Daily Build）和滚动构建（Rolling Build）。

    每日构建（Daily Build）出来后，软件开发测试工程师会针对它进行一系列的测试包括版本验证测试（Build Verification Test）和临时手动测试（Ad hoc manual Test），另外还会不同周期地做全面自动测试（Full Automation Test），压力测试（Stress Test），性能测试（Performance Test），安全测试（Security Test）等等。这些大多都是事先根据测试计划写好的自动测试，同时会把在测试中发现的问题记录下来，软件开发工程师会相应地进行调试解决，项目经理会对所有发现的问题做Triage（会审），Triage这个英文词的原意是一个根据伤员的伤病情况来决定先给谁后给谁处理伤病的流程，这个词在这里的意思也就很容易理解了。

    测试在产品开发中对质量把关起到至关重要的作用，在整个流程中是必不可少的环节。这也是为什么微软在甄选软件开发测试工程师时也会很严格，软件开发测试工程师能力并不会比软件开发工程师差，只是在软件开发中分工不同，侧重点不同。

   现在，我带领的CLR/Silverlight团队和WinForms团队各自有一套简捷的流程来进行开发测试，虽不完全一样，但都是很有效的。总之，流程是为了保证产品质量而设的，定然不能缺少，但也不能太过复杂，否则会降低效率，也会影响人的创造力和能动性。

部门经理 徐鹏阳

备注:近期将更新《从卓越工程的角度来看微软中国开发团队的成长 (三)》