协作开发中的质量保证技术.docVIP

协作开发中的质量保证技术——并行版本控制、每日构建和交付工程 原创：司徒彦南 2003年10月29日 目录 ? 摘要 ? 问题的提出 ? 并行版本控制——多人协作开发的有效保障 ? 代码提交和同步 ? 编码过程中的沟通纽带——commit mail ? 日常测试——每日构建 ? 有效的版本控制——代码分支、版本标记 ? 特性冻结与代码冻结 ? 交付工程 ? 总结 ? 参考文献 ? 作者简介 摘要 本文以cvs为例，介绍了软件工程中，编码过程中对于版本控制的运用的一些技巧。在最后部分，还介绍了软件工程最后的“交付工程”。 问题的提出 编码过程是软件工程的重要一环。这一部分工作的好坏直接关系到软件产品的质量。高效率的多人协作开发，依赖于团队精神、设计师对于软件架构的整体把握、好的并行版本控制技术，以及制度化的每日构建和最后阶段的交付工程。 今年六月，我有幸在一家开发安全软件的公司观摩了他们的每日构建和交付工程中的活动。他们对于并行版本控制、每日构建技术熟练而深入的应用给我留下了非常深刻的印象。在此，我愿与读者一同分享我自己的学习体会，这其中的某些部分得益于在那家公司的实地观摩，另一些则来自于我自己参加的实际软件工程项目的体会。 毫无疑问地，一个软件工程项目最有价值的部分还是在它的设计阶段。良好的设计能够让实现环节变得更有效率，从而极大地提高劳动生产率；而好的编码规范，则是协同开发的重要基石。限于篇幅，对于前述两项内容本文将不会过多设计，我将着重介绍软件工程中编码与测试环节的一些经验，这些经验对于已经拥有优秀的软件设计师和编程、测试人员，而苦于由于连调、最终测试导致发布频频延期的开发团队来说是非常有益的。 并行版本控制——多人协作开发的有效保障 设想一个有4名编程人员的小型开发团队(以下简称“TJRP开发组”)，Tom、Jason、Robert和Pat分别负责4个模块，按照传统的软件开发模式，开发将经历编程-连调-测试-发布4个阶段。 如果最初的设计正确，并且，四个开发人员都是Guru级的程序员而且配合默契，那么这个模式将会运转良好。然而遗憾的是，Pat刚刚参加工作不久，对于设计师撰写的设计文档的理解不够透彻，而Robert则自作主张地对设计进行了一些修正，更糟糕的是，项目组会议的时候，这些问题没有及时地被暴露出来，导致Pat和Robert代码在设计上的“分歧”越来越大。结果，进入连调的阶段，Pat和Robert发生了激烈的争执，在吵得不可开交之后，项目经理终于让4个人坐到了一起来解决问题，最后，连调阶段整整多花了一倍的时间。 但倒霉的事情还没有结束。Jason在测试中发现，原本正常的代码的行为被改变了，并且，他惊讶地发现代码被某个“别人”改过，在翻箱倒柜地找出某份正常版本的副本之后，他又发现，“别人”修改中的某些地方是必要的。代码合并和重新测试使得测试阶段足足花掉了原先预想3倍的时间。 可怜的Tom运气更差，作为主要的代码复审人员，他不得不阅读所有的代码。Robert和Pat的争吵导致了大量的代码变动，他不得不重新审核代码，而Jason的代码合并引发的新问题又让他不得不分神去帮助Jason进行调整。 最后的结果是，软件开发的成本是预期的2.4倍，发布时间也拖后了不少。我并不是在开玩笑，上面所讲的是一个发生在那家安全软件公司的真实故事。他们的技术经理介绍，在施行了规范的开发制度，以及启用并行版本控制系统之后，他们认为开发达到了一个全新的水平。并行版本控制系统本身并没有产生任何代码，但由于使用这样的系统，开发的效率被大大地提高了。 所谓版本控制其实并不是什么复杂的概念。对于开发活动的绝大多数参与者来说，版本控制系统在某种意义上能够帮助他们做好开发过程中的记录工作，并且，通过保存文件在不同时期的版本，交付工程师和代码复审员能够很容易地缩小有哪些信誉好的足球投注网站问题代码的范围，而程序员则可以通过这样的系统更好地并行协作。一般来说，源代码的版本控制系统能够实现以下一些最基本的功能： 保存任意一个源代码文件的不同版本 记录修改者、修改原因 当两个用户同时修改一个文件时，尽可能地自动合并修改；在不能合并时，给出提示 比较不同版本之间，或与本地副本之间的差异 获取必威体育精装版版本的全部源代码供测试，并允许回退到所保存的源代码的任意版本 创建代码分支，便于软件发布和后期维护(后面将会提到)；新的代码可以合并到这些分支中。 对不同的源代码给出标记，方便日后审查 访问控制：阻止未经授权的修改和查阅 我们知道，技术不是解决一切问题的灵丹妙药，但是谁也不会否认大规模的机械化生产的效率高于人拉肩扛的手工业作坊，一旦运用得当，技术将极大地改善我们的工作和生活。我们可以看到，上面的功能有效地解决了TJRP开发组所面