试读《未雨绸缪——理解软件配置管理》

提起软件配置管理，我想目前为止是我最最头疼的问题。希望这本书试读的部分可以让我基本了解或者说理解软件配置管理。解决我的头疼问题。:-)

机器是由零部件组成的。例如，汽车一般由底盘、发动机、车身和电气设备四大部分组成。其中，汽车底盘一般包括传动系、转向系、制动系和行驶系。传动系主要由离合器、变速器、传动轴和减速器等部件组成。再往下分析，基本就是零件了。

机器由正确型号的零部件配置而成。每个零件都有型号、编号，零件组成的部件也有，一直到整个机器，一辆汽车。要保证制造出来的机器是好用的，就要保证选取的零部件型号正确。那么，容易想到——应该有某种列表或文档，标明各零部件型号和组成关系，也就是说，要标明配置信息。而当配置有变动的时候，就要更新这样的列表或者文档。并且，这种变动不能随随便便，是否应该先让总工程师批准？是否应该做相应的测试？这些都属于对配置的管理。

从软件配置管理的视角看，软件也是这么配置出来的。往小了说，各个源代码文件的正确版本配置在一起，编译产生了正确的可运行的程序。往大了说，若干软件组件的特定版本，配置构成了特定的软件产品。而有这些软件组件，可能参与了不止一个软件产品的配置构成。而当某个软件组件参与不止一个软件产品的配置 构成的时候，可能是这个软件组件的同一个版本，也可能是不同版本。看，问题有多复杂，不管理怎么行！

配置管理，管理系统的配置：硬件配置管理，管理硬件系统的配置；软件配置管理，管理软件系统的配置。注意这里的“系统”这个词。配置管理要管理每个零件，每个源代码文件，但是管理的根本目的是保证他们能够组成一个可运行的系统。说的专业一点，那就是，配置管理关注系统的集成，或者说，关注系统的完整性。这是配置管理的一个重要特点。

此外，如何复用开发成果，让不同的版本、相似的产品之间共同的部分只开发一次，让众多项目能够多快好省的完成，也是配置管理关注的重点。这常常需要综合运用分支、设置、组件组合等方法。除了软件复用，多地点协同开发、与第三方的合作等，也都需要配置管理的支持。

做好软件配置管理，与做好硬件的配置管理相比，要更难一些。这是因为软件配置管理的特殊性。

第一，软件更容易发生改变，版本更多。一个开发人员，修改一个bug，可能半个小时就搞定了。于是，半个小时前与半个小时后，已经是不同的版本了。更何况，不止一个开发人员在工作。如可快速的，众多的变化，如果靠一个书记员手工记录相关信息，那恐怕比较累，所以需要某种自动化工具，以提供这方面的支持。另一方面，在如此快速的、众多的变化中，还要保湿系统的完整性，显然它的挑战也更大。

第二，软件的耦合性更高。当开发人员为了某个任务改动源代码的时候，经常要改动不止一个文件。在目录结构上，这些文件可能相距遥远。组件/模块间的接口，往往并不像把鼠标线插到USB接口那么简单。某个模块的变化，常会影响到相关的模块。这个特点，使得在软件领域，需要格外关心系统的完整性。要尽早、尽可能频繁的集成，保证产品作为整体是可以运行的。另一个放米娜，一个模块、一个源文件可能被几个开发人员改动，他们可能处于不同的目的，改动不同的位置，甚至相同的位置。因此，版本更容易混乱活相互覆盖。

做好软件配置管理不容易。软件配置管理相关的工具，比如源代码版本控制工具等，可以提供支持，提供便利，同时避免出现问题。引入工具很重要，而用好工具，配合合适的流程和策略，以支持特定研发组织的具体研发场景，则更为重要。

这本书的这个章节还是很清晰明了的介绍了软件配置管理，对于像我这用一提软件配置就头疼的人有很大的帮助……