协作开发中的质量保证技术并行版本控制每日构建和交付工程Word下载.docx

协作开发中的质量保证技术并行版本控制每日构建和交付工程Word下载.docx

《协作开发中的质量保证技术并行版本控制每日构建和交付工程Word下载.docx》由会员分享，可在线阅读，更多相关《协作开发中的质量保证技术并行版本控制每日构建和交付工程Word下载.docx（12页珍藏版）》请在冰豆网上搜索。

而好的编码规范，则是协同开发的重要基石。

限于篇幅，对于前述两项内容本文将不会过多设计，我将着重介绍软件工程中编码与测试环节的一些经验，这些经验对于已经拥有优秀的软件设计师和编程、测试人员，而苦于由于连调、最终测试导致发布频频延期的开发团队来说是非常有益的。

并行版本控制——多人协作开发的有效保障

设想一个有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开发组所面临的绝大部分问题，例如：

由于能够同时修改代码，并获取对方的修改，Pat和Robert能够有效地、尽早地进行沟通

促进开发者之间的交流，每一个修改都必须给出原因，并记录提交者

测试和连调可以尽早开始，避免模块之间的不兼容在最后阶段被暴露出来而阻碍发布

不同开发者的修改能够及时合并，并避免由于版本不一致导致的冲突

代码复审可以针对某一代码分支进行，从而，允许一些开发者持续地开发下一个版本，而稳定的代码则可以交付给用户

更进一步，以管理者的角度，还有了一些额外的好处，如：

每日构建和测试能够让项目经理更好地把握工程的进度

谁作了多少工作，谁工作的更出色，可以在版本控制系统中清晰地体现

分工明确，通过访问控制，可以避免不了解整个代码体系的开发人员偶然的错误修改导致的全盘崩溃

更重要地，版本控制系统中将保持大量的开发经验，这对于一个开发团队来说是一笔无价的财富

我们可以看到，上述改进集中地体现了一个重要的思想，即：

及时沟通以预防问题的出现；

尽早发现、尽早解决问题；

明确奖惩制度，激发开发人员的积极性。

下面我们将以非常常见的版本控制系统——cvs[1]为例，介绍并行版本系统一些基本的使用原理。

代码提交和同步——从update和commit说起

每当我们开始一个新的修改之前，首先要做的是从代码库中提取出一份最新的副本（通过update操作完成）；

在本地修改、粗调之后，则应尽快将代码提交回代码库（通过commit操作完成）。

基本的update和commit操作流程如下图所示：

图1.cvsupdate和commit

这两项操作也解决了日常开发大约80%的问题。

绝大多数情况下，这部分的工作是相当简单的，除非出现两个开发者同时修改同一个文件的情况，例如，两个开发者同时地修改了同一个文件的同一个版本，这种情形称为冲突：

图2.cvs并行开发中的冲突

可能开发者B的动作比较快，或者，修改的东西比较简单，于是他首先提交。

在A、B从代码库中提取代码时，最新版本是1.1，于是，B提交的版本被版本控制系统命名为1.2。

但不久，A想要提交代码，版本控制系统将拒绝他的提交，因为他的修改基于代码的1.1版，而目前的最新版本已经是1.2了。

cvs提供了自动合并功能，允许在两个人修改的不是同一行代码的前提下，自动合并本地修改和最新的代码，当然，如果赶上两个人同时修改同一行代码的情况，cvs也会非常“聪明”地把两个“英雄所见略同”的地方合并。

但如果两个人恰好都修改了同一行代码，而且改的不一样怎么办？

cvs会告诉后一个提交的开发者发生了这样的情况，并且要求他解决问题。

代码中存在的差异将以<

<

和>

>

标记出来，以方便进行修改。

简单说来，当发生冲突时，我们通常约定由后一个提交者解决冲突——当然，他可以选择忽略这些冲突，但这些操作都会被记录，更何况，统计显示，同时将一行代码修改为两种不同的样子这样的情况在实际开发中很少出现。

于是，修改流程继续，如下图：

图3.开发者A解决冲突，并提交

极端情况下，可能出现多个开发者同时修改同一个文件的问题。

这一问题基本上可以按照上述的方法解决。

当然，为了避免发生这样的情形，在设计的时候就应该让每个人工作的代码尽可能地不重叠。

下面是非常基本的cvsupdate/commit操作规范：

简单的cvs操作约定

修改文件之前首先update。

这意味着修改时的版本尽可能新，一旦发生冲突，解决它的工作量会比较小。

及时commit。

本地代码与代码库中的代码差异越小，别人合并的难度也就越小（他们有比较大的概率能够拿到新的版本）

将不同的功能单元修改分开commit。

一方面，这样做能够尽早地commit，减少别人合并的难度；

另一方面，由于cvs提供了回退到先前版本的能力，一旦由于某项功能修改造成问题，也很容易将那次修改的内容，而不是整个修改回退到正常的代码。

同一功能涉及的所有代码一次commit。

不希望将涉及同一功能修改的代码分开commit，因为这会给日后的追踪带来麻烦。

先调试后提交。

这将减少别人不会因为同步了中间结果引发问题，甚至发生提交冲突的可能。

写清commitlog（提交日志）。

cvs中允许保存commitlog，在这里可以写为什么进行代码的修改，以及进行了什么样的修改，清楚的commitlog能够帮助其他开发者在不仔细阅读代码的情况下了解修改的内容，从而极大地提高开发效率；

另一方面，这些日志对于开发者自己，以及整个开发团队，都是非常宝贵的财富。

同步代码（update）和提交代码（commit）占到了cvs日常操作的80%以上。

从上面的介绍我们可以看出，仅仅依靠这两项非常简单的功能，cvs就能极大地改善开发流程，并提高软件工程的可控性。

简单地说：

全体开发者使用同一个中央代码库，从而消除了由于来回复制文件导致的不一致。

发生冲突时，后提交的开发者必须解决它。

这名开发者能够知道是谁引入了冲突，他可以自己解决冲突，也可以与引入冲突的开发者商量如何解决冲突。

测试可以贯穿编码过程的始终，任何时候引入的新问题都能够被及时追踪、快速定位，从而更有效地解决。

由于存在中央代码库，代码审核人员和每日构建人员能够及时地了解代码是否存在问题，并帮助项目经理保证开发进度。

有助于帮助开发人员养成严谨的工作习惯——规则要求他们将尽可能地提交正确的代码，并且每个修改必须写commitlog进行说明。

有助于建立更公平的工作质量评估机制。

cvs能够记录每个人完成的实际工作量，包括他们因为修正问题等等所作的劳动，以及他们完成代码的质量情况。

这样，管理者能够为优秀的开发人员提供更好的工作机会、报酬，等等，这对于鼓舞整个团队的士气、提高开发人员的工作积极性都是非常有益的。

促进开发人员之间的交流。

尽管cvs本身无法代替交流，但commitlog，以及cvs系统获取任意版本之间差异的能力，能够帮助开发人员了解对方的想法，并促进他们共同提高。

降低程序开发人员的门槛。

由于提供了许多非常方便的协同开发手段，使用cvs能够减少协同开发所需要的磨合期，同时，不同层次的开发者之间由于能够进行经常性的沟通，从而把编码过程从技能型工作向熟练性工作又推进了一步。

这意味着高层次的开发人员能够去进行更能发挥他们特长的工作，而新手则可以很快地融入到日常的开发活动中来，从而提高劳动生产率，降低开发成本。

编码过程中的沟通纽带——commitmail

cvs是一项开放性很强的工具，它可以被非常容易地订制。

一般来说，cvs服务器会架设在一台Unix主机上（我们推荐使用FreeBSD），通过使用脚本语言（例如，Perl），cvs能够完成一些额外的功能。

commitmail是commitlog在邮件系统上的延伸。

下面是一封典型的commitmail，它来自FreeBSD开发团队：

phk2003/10/2123:

32:

20PDT

FreeBSDsrcrepository

Modifiedfiles:

sys/geomgeom_io.c

Log:

Forgottencommit:

Ifaproviderhaszerosectorsize,itisan

indicationoflackofmedia.

Trippedup:

peter

RevisionChangesPath

1.50 

+3-6