计算机时代２０１２年第ｌＯ期　・　６７　・　行为优化提升软件配置管理　张薇　（北京工业大学软件学院，北京１００１２４）　摘要：软件配置管理包括对代码、文档、数据等的管理，其优劣受限于项目成员的实际操作。开发人员对于工作区如　何使用；成员之间的代码是不是可以及时更新与同步；怎样使用分支，如何进行变更合并，才能减少物理空间浪费和事件　延迟。这些问题在实际的项目开发中往往被忽视，亦或团队并没有对成员行为作细节的规范，因而许多软件项目出现了　工期推迟或代码质量不高等问题。为此提出了一系列管理措施，通过优化软件配置管理规范项目各成员的行为，以保证　高效的软件配置管理的实施。　关键词：软件配置管理；工作区；代码；分支与合并；过程及规范　中图分类号：ＴＰ３１　１．５　文献标志码：Ａ　文章编号：１　００６—８２２８（２０１　２）１　０—６７—０３　

Ｃｏｎｆｉｇｕｒａｔｉｏｎ　ｍａｎａｇｅｍｅｎｔ　ｏｆ　ｂｅｈａｖｉｏｒｓ　ｏｐｔｉｍｉｚｉｎｇ　ａｎｄ　ｐｒｏｍｏｔｉｎｇ　ｓｏｆｔｗａｒｅ　Ｚｈａｎｇ　Ｗｅｉ　（Ｂｅｉｊｉｎｇ￡，凡　ｅｒｓｉｔｙ　ｏｆ　Ｔｅｃｈｎｏｌｏｇｙ，Ｓｃｈｏｏｌ　ｏｆ　Ｓｏｆｔｗａｒｅ　ｅｎｇｉｎｅｅｒｉｎｇ，Ｂｅｉｊｉｎｇ　１００１２４　Ｃｈｉｎａ）　Ａｂｓｔｒａｃｔ：Ｃｏｄｅ，ｄｏｃｕｍｅｎｔａｔｉｏｎ　ａｎｄ　ｄａｔａ　ａｒｅ　ｍａｎａｇｅｄ　ｂｙ　Ｓｏｆｔｗａｒｅ　ｃｏｎｆｉｇｕｒａｔｉｏｎ　ｍａｎａｇｅｍｅｎｔ（ＳＣＭ）．Ｉｔｓ　ｒｅｓｕｌｔ　ｄｅｐｅＭｓ　ｏｎ　ｂｅｈａｖｉｏｒｓ　ｏｆ　ｐｒｏｊｅｃｔ　ｍｅｍｂｅｒｓ．Ｈｏｗ　ｄｅｖｅｌｏｐｅｒｓ　ｕｓｅ　ｗｏｒｋｓｐａｃｅ，ｗｈｅｔｈｅｒ　ｔｈｅ　ｕｐｄａｔｉｎｇ　ａｎｄ　ｓｙｎｃｈｒｏｎｉｚａ６０ｎ　ｏｆ　ｃｏｄｅ　ｌｉｎｅ　ｂｅｔｗｅｅｎ　ｍｅｍｂｅｒｓ　ａｒｅ　ｏｎ　ｔｉｍｅ，　ｈｏｗ　ｔｏ　ｕｓｅ　ｔｈｅ　ｂｒａｎｃｈ　ａｎｄ　ｍｅｒｇｅ　ｃｈａｎｇｅｓ　ｉｎ　ｏｒｄｅｒ　ｔｏ　ｒｅｄｕｃｅ　ｔｈｅ　ｗａｓｔｅ　ｏｆ　ｐｈｙｓｉｃａｌ　ｓｐａｃｅ　ａｎｄ　ｐｒｅｖｅｎｔ　ｅｖｅｎｔ　ｄｅｌａｙ，ａｌｌ　ｏｆ　ｔｈｅｓｅ　ｑｕｅｓｔｉｏｎｓ　ｏｆｔｅｎ　ｂｅ　ｉｇｎｏｍｄ　ｉｎ　ｓｏｆｔｗａｒｅ　ｐｒｏｊｅｃｔ，ｏｒ　ｓｏｍｅｔｉｍｅｓ　ｔｈｅ　ｔｅａｍ　ｄｏｅｓ　ｎｏｔ　ｒｅｇｕｌａｔｅ　ｔｈｅ　ｄｅｔａｉｌｓ　ｏｆ　ｂｅｈａｖｉｏｒｓ．Ｓｏ　ｓｏｍｅ　ｓｏｆｔｗａｒｅ　ｐｒｏｊｅｃｔｓ　ｃｏｎｆｒｏｎｔ　ｐｒｏｂｌｅｍｓ　ｏｆ　ｄｕｒａｔｉｏｎ　ｄｅｌａｙ　ａｎｄ　ｌｏｗ　ｃｏｄｅ　ｑｕａｌｉｔｙ．Ｉｎ　ｖｉｅｗ　ｏｆ　ｔｈｅ　ａｂｏｖｅ　ｐｒｏｂｌｅｍｓ，ｐｒｏｊｅｃｔ　ｔｅａｍ　ｓｈｏｕｌｄ　ａｌｌｏｃａｔｅ　ｍａｎａｇｅｒｓ　ｔｏ　ｓｕｐｅｒｖｉｓｅ　ｅａｃｈ　ｓｔａｇｅ　ｏｆ　ｃｏｎｆｉｇｕｒａｔｉｏｎ　ｍａｎａｇｅｍｅｎｔ，ｒｅｓｏｌｖｅ　ｃｏｎｆｌｉｃｔｓ，ｃｈｅｃｋ　ｂｒａｎｃｈ　ｃｏｎｓｏｌｉｄａｔｉｏｎ，ｅｔｃ．Ｍａｎａｇｅｒｓ　ｓｈｏｕｌｄ　ｒｅｃｏｒｄ　ｔｈｅ　ｄａｔａ　ｏｆ　ｐｒｏｂｌｅｍｓ　ａｎｄ　ｔｈｅ　ｅｘｐｅｒｉｅｎｃｅ　ｏｆ　ｒｅｓｏｌｖｉｎｇ　ｐｒｏｂｌｅｍｓ　ｉｎ　ｏｒｄｅｒ　ｔｏ　ｆｏｌｌｏｗ　ｕｐ．Ｔｈｅ　ｐｒｏｊｅｃｔ　ｐｒｉｎｃｉｐｌｅ　ｓｈｏｕｌｄ　ｓｐｅｃｉｆｙ　ｂｅｈａｖｉｏｒｓ　ｏｆ　ｄｅｖｅｌｏｐｅｒｓ　ａｎｄ　ｔｈｅ　ｍｅｍｂｅｒｓ　ｏｆ　ｔｅａｍ　ｓｈｏｕｌｄ　ｐｌａｙ　ｂｙ　ｔｈｅ　ｒｕｌｅｓ　ｓｏ　ｔｈａｔ　ｓｏｆｌｗａ￣ｃｏｎｆｉｇｕｒａｔｉｏｎ　ｍａｎａｇｅｍｅｎｔ　ｉｓ　ｉｍｐｌｅｍｅｎｔｅｄ　ｅｆｆｅｃｔｉｖｅｌｙ．　Ｋｅｙ　ｗｏｒｄｓ：ＳＣＭ；ｗｏｒｋｓｐａｃｅ；ｃｏｄｅ　ｌｉｎｅ；ｂｒａｎｃｈ　ａｎｄ　ｍｅ唱ｅ；ｐｒｏｃｅｓｓ　ａｎｄ　ｐｒｉｎｃｉｐｌｅ　

０引言　软件配置管理（ＳＣＭ，Ｓｏｆｔｗａｒｅ　Ｃｏｎｆｉｇｕｒａｔｉｏｎ　Ｍａｎａｇｅ—　ｍｅｎｔ）是软件项目中一个非常重要的活动，存在于整个软件项　目周期当中，管理项目的所有代码、数据、文档等，以保证软件　项目过程的可控，变更历史可追溯。本文从六个基本角度：工　作区、开发线、分支、合并、编译以及过程规范，探讨软件配置管　理优化的方案。希望项目成员能够以优化自己的日常工作为　起点，与团队一起共同提高软件项目的配置管理水平。　

１工作区优化　工作区是开发者进行代码开发、测试、变异的特定分配区　域，几乎每种ＳＣＭ系统都存在“工作区”这个概念，它界定了开　发人员的工作领域，避免开发人员之间的工作相互影响。　１．１不共享工作区　为了便于管理，工作区应该遵循分离原则。工作区的共　享，实质上显示了开发人员工作空间的物理条件的共享性，这　样一来，某个开发人员的修改，就会导致共享此工作区的其他　人员工作的混乱。物理空间并非高价之物，不要为了节省磁盘　

空间而浪费时间，在软件项目中，分秒必争，时间不可浪费。　１．２禁止工作区外开发　背着ＳＣＭ进行暗地操作，其历史的追踪将成为不可能。　为了开发团队的交流，每个开发者的工作区内容，可以被其他　成员查看，而不允许其他成员修改。如果开发人员在工作区外　部进行开发，其工作不能与团队共享，且修改历史不能被跟踪，　这将没有办法在发生问题时回滚到之前正确的状态，造成工作　的徒劳。　１．３避免由外至内的影响　对于自己工作区内的文件，应该极力避免非意志性的文件　更改。主要是，不受ＳＣＭ系统管理的外部物理空间发生的活　动，引起了ＳＣＭ工作区内的文件的更改。例如，软件的编译行　为，可能会增加ＳＣＭ控制区内文件。为了保证项目受控工作区　域的文件稳定性，应避免工作区外部行为对内部文件的增删改。　１．４同步项目库代码　开发人员ｃｈｅｃｋ—ｉｎ代码时，需先将自己的工作区与版本库　进行同步，在没有冲突的情况下进行本地修改的ｃｈｅｃｋ—ｉｎ，当有　较大冲突时，需要配置管理者对冲突进行手动修正。如果可以　

收稿日期：２０１２—８—２７　作者简介：张薇（１９８８一），女，北京人，硕士，主要研究方向：软件工程，信息服务。　・　６８　・　Ｃｏｍｐｕｔｅｒ　Ｅｒａ　Ｎｏ．１０　２０１２　减少这样的冲突，及时将工作区本地版本与服务器同步，保持　ＳＣＭ管理下的代码最新，可以减少代码最终提交时的尚待解决　的冲突，避免延迟工期。　１．５及时ｃｈｅｃｋ—ｉｎ　当多名开发人员协同开发时，开发告一段落，开发人员需　要通过ｃｈｅｃｋ—ｉｎ代码去告知其他开发者自己的变更，而及时的　ｃｈｅｃｋ—ｉｎ可以保证其他人员能够及时得到库内的新版本，减少　冲突的出现。当然配置管理组，也需要建立支持频繁变更的机　制，避免对代码变更过于复杂保守的评价。变更审查的时问越　久，就会造成越大的项目时间的浪费。　２代码行为优化　代码在配置管理的过程中会分成不同的版本，不断更新完　善，最后发布。代码的管理是软件项目配置管理的重要工作部分。　２．１制定代码策略　代码策略指对于代码正确使用的方法、如何审定ｃｈｅｃｋ—ｉｎ　的代码，而确立的规则，这些策略将是代码部分管理的重要手　册。代码变更如何进行书面化描述，怎样进行编译、测试，　ｃｈｅｃｋ—ｉｎ后的代码安定性预期值等，都需要在规则中进行明确　规定。没有规则化的代码开发，从软件配置管理的角度而言，　可以说等同于失去可控性。　２．２设立开发控制责任人　有了代码策略，也不能排除规则不适用或者含糊不清的特　殊情况，为了解决这些特殊情况，开发者可以通过控制人员得　到统一的解决方法。设定开发控制责任者，使其承担特定部分　代码的责任以及规则把握，避免开发者遇到问题时擅自解决，　并将遇到的特殊情况书面化，以便项目组积累经验，为后续开　发奠定基础。　２．３使用主线开发模式　图１基于主线的开发模型　如图ｌ所示的基于主线的开发模型，可以看到从主线分出　了几条发布线（”ｖｅｒｌ”、”ｖｅｒ２”、”ｖｅｒ３”）与开发线（”ｐｒｏｊＡ”、　”ｐｒｏｊＢ”、”ｐｒｏｊＣ”）。开发者在主线与开发线上进行开发活动，发　布线用于测试以及ｂｕｇ修正。发布线与开发线上进行的变更，　最终需合并到主线中。主线开发，支持并行开发，大大减少软　件产品在其生存周期成熟之前的管理开销，并且主线模型可以　避免代码冻结，使项目顺利进行。　３分支优化方案探讨　分支功能是软件配置管理下最容易产生问题的部分。不　同的软件配置管理方案，对分支进行不同方式的支持，或者可　以说，根据不同的规则，分支机能也得到不同程度的活用。　３．１需用才用　所有分支的变动几乎都会引起项目人员的工作量的增加　（编译工作、代码的变更传达，分支合并等）。增加分支同时，　需要充分意识到对项目工作量的增加，减少不必要的分支的　增加，并尽可能避免在分支上再建分支，以降低对项目进度的　影响。　３．２传递靠分支不靠备份　当开发线全部或者一部分需要转交时，不要进行复制传　递。复制传递需要将一条生产线上的全部文件都复制到新位　置，作为新的文件在新的开发分支上进行使用。由于复制之后　文件的增加，不仅增加了物理空间的负担，同时对于相同的文　件，ＳＣＭ系统仍需要管理这些新分支的“新”实体以及他们的历　史记录，这将增大配置管理的复杂度。　３．３不同原则不同分支　如果开发人员遵循着不同的检入，检出原则，则应该在不同　分支上进行开发。例如：负责软件发布的小组，要求进行严密　的测试之后才可以进行ｃｈｅｃｋ—ｉｎ；而开发组需要及时同步代码　版本，只要进行简单的测试就可以ｃｈｅｃｋ—ｉｎ。像这样依据完全　不同的工作原则时，分支开发是必须的。　３．４不到必要时不创建分支　不谈建立分支的物理消耗，为了最小化分支之间变更传递　的复杂性，应将分支建立尽可能向后推延。例如，过早为新功　能建立发布分支，该分支上新功能的测试以及ｂｕｇ修正不得不　同时向主线上合并，这是时间和工作量上的浪费。发布分支建　立前，在开发主线上进行测试与ｂｕｇ修正的话，分支之间传递的　变更信息将会大大减少，可以节省时间与精力。　３．５以分支缓和冻结　有时，项目需要对代码进行冻结以便进行测试工作，而这　对于开发者而言，在测试完成之前，开发产生的变更无法与项　目代码进行整合。这种情况下，为了使开发人员的工作得以正　常进行，应该在代码冻结之前尽可能早地建立新分支。　

４合并优化方案探讨　合并指的是某一分支的变更向目的分支的更新整合操　作。这是我们不得不直面的ＳＣＭ中的一个重要且普遍的问　题，而这并不是一个简单的工作。　４．１变更合并相似分支　分支时间越长，冲突就越多，合并开销就越大。对于一次　变更，与其与经过较多修改的分支进行合并，不如与变化不大　的分支合并来的容易。例如，主线模型中，应该在发布分支上　进行ｂｕｇ修正等操作，功能稳定后合并到开发主干上。若在主　线上进行ｂｕｇ修正，合并时原本不需要的修改可能也会传给发　布分支，而这些无关变更可能造成开发人员工作混乱。　４．２勤于合并　要尽量频繁地进行合并。及时合并处于稳定点的分支，让　自己的修改尽快被其他相关开发人员得知，这可以有效地减少　开发成员之间的代码冲突。同时变更的合并，赶早不赶晚，及　早进行合并，以减少延迟合并可能产生的冲突。