SCM的前前后后

Part1:缘起（版本控制之兴）<o:p></o:p>

<o:p> </o:p>

       SCM——软件配置管理。什么叫做软件配置管理呢？

其实SCM这个词它本身的描述是不能自明其义的。我们可以理解为：用户在使用软件中对该软件的一些配置选项的管理。我们也可以理解为：在我们的工作中需要多个软件来协同完成工作，而这里管理的是这些软件。我们还可以理解为在软件的开发过程中，对整个变化进行管理。

而在实务中，我们把SCM理解为——对软件开发过程中发生的变化进行配置管理。

存在即是合理。为什么会衍生出SCM这样的概念呢？它的出现所满足的内在需求又是什么呢？或许我们只有从软件本身的制造过程中来寻找这些问题的答案。

首先，什么是软件？软件工作在硬件之上，而应用软件又工作在系统软件之上。更上层的软件可以使用下层软件提供的抽象资源，操作外部设备。故开发一个应用软件，我们需要底层的支持，这里底层可能是系统软件，可能是硬件设备。对于我们软件的开发人员来讲，我们常用的工具包括编译器、链接器、调试器等等，而现在一般这些工具都会被集成在IDE这样的集成开发环境中了。

从软件存在的意义上看，它操作各种抽象非抽象的资源其目的是为了满足某个业务领域的需求，如字处理软件——它就是使人们可以在电脑上进行文字编辑，排版等文字处理相关的操作。再另一个很流行的软件就是成千上万的Hello World，它的业务需求就是能够在屏幕或是别的终端显示设备上显示出“Hello World”。不同复杂度的业务需求，自然会对应不同复杂度的软件。

而不同复杂度的软件，自然会对应不同规模的实现人员。请注意，我这里“实现人员”的用词。当我们面对hello world这样的应用需求时，我们大可不必用上超过1人的人力去实现上。我们完全可以让一个人去完成它！从理解业务需求，到设计软件架构，到实现软件，再到测试软件功能，再到发布给客户进行部署。

<o:p> </o:p>

在我们经常写的hello world里面。我们自己是

<!---->Ø         <!---->客户

他提出了软件应当正确实现的业务需求！<o:p></o:p>

这里，我们的需求是在控制台上打印“hello world”。

<o:p> </o:p>

同时，我们自己也是

<!---->Ø         <!---->需求分析人员

他理解客户提出的或零散或有条理的业务需求，并进行整理，以提供给设计人员！<o:p></o:p>

这里，我们直接翻译即可，无需整理。

<o:p> </o:p>

再者，我们还是

<!---->Ø         <!---->设计人员

他根据整理后的需求，给出软件的系统设计！这里的设计包括抽象的逻辑设计、物理的实现设计、物理的部署设计等<o:p></o:p>

这里，在抽象的逻辑设计方面，我们先决定选择面向对象的开发方法，采用Java语言进行实现，在作了这些技术决策之后，我们决定针对需求，抽象出Greeting类这样的逻辑设计；在物理实现方面，因为采用Java语言，其物理实现和逻辑设计时很吻合的；在物理的部署设计方面，因为客户（我们自己）无需安装包，无需通过web访问。故我们可以选择做个桌面的控制台程序即可。

<o:p> </o:p>

对我们来说，无疑我们是

<!---->Ø         <!---->开发人员

他根据设计人员的设计文档进行编码实现相应的软件功能<o:p></o:p>

<o:p> </o:p>

此外，我们也是

<!---->Ø         <!---->测试人员

他的基本职责是根据需求分析人员整理后的需求对开发人员实现的软件进行正确性测试，此外他可能还要承担着软件性能测试的职责<o:p></o:p>

在我们这里，我们只需要检验软件运行后是否能在屏幕上显示出“hello world”即可。

<o:p> </o:p>

最后，我们是

<!---->Ø         <!---->发布部署人员、维护人员

他们分别负责给客户安装软件和在服务器内给客户解决软件使用中遇到的问题<o:p></o:p>

<o:p> </o:p>

补充一点的，也可能是最重要的，我们还是

<!---->Ø         <!---->决策人

在现实中扮演这个角色的人比如项目经理、负责人、老板等，他的一个关键特征是，在软件开发过程中有对关键问题解决方案的决策权<o:p></o:p>

<o:p> </o:p>

虽然是一个简单的Hello World的程序，但在整个的开发过程中，参与实现的这一个人其实扮演了很多很多的角色。那么当业务需求复杂之后，实在必行的就是实现“分工”，参与开发的人履行各自职责！分工在这里的主要意义在于：缩短工期；提升专业化从而提高效率。

但随着分工的出现，我们必需解决一个因此而衍生出的新的问题：协作。如果按我们上面分析出的角色来划分人员，那么我们所面临的一个很棘手的问题就是如何让客户、需求分析人员、设计人员、开发人员、测试人员、部署人员、维护人员、决策人相互协同工作。

协作细分下来包括相同角色之间的协作和不同角色之间的协作。比如，对开发人员来讲，从易决策人管理（但并不易维护）的方式上，可以让他们按照功能模块来开发，但从复用（且易维护）的方式上，可以让他们按照系统架构来开发。

至此，我们只需要知道，SCM就是为了实现更加科学的分工和更加有效的协作！这就够了。但怎样实现呢？

我们现在把目光再转回我们的最终目的——可正确运行的软件（以及配套的使用帮助文档）！这是我们生产出来的最终工件（artifact）。为了得到这个工件，我们需要生成许多其他工件，而生成这些工件的责任分别系附在不同角色的人头上。如，需求人员编写的需求需求说明书，开发人员编写的源代码及生成的目标代码等。各个角色的人他们相互分工协作的基础和共同标的就是这些工件。

因此要探求更科学的分工和更有效的协作，我们必须从工件的审视开始。如上面我们所说，工件可以是文本文档、源代码、目标代码等。无论工件是何种格式，它都是以一种文件的形式存储在我们的文件系统上。即，工件的一个本质属性就是：它是一个文件！

现在我们可以把SCM看作对文件的管理。我们会不断对文件进行修改。

对单个文件本省来讲，我们会希望

<!---->Ø         <!---->保存修改以前的文件

<!---->Ø         <!---->知道谁修改的文件

<!---->Ø         <!---->知道什么时候修改的

<!---->Ø         <!---->知道为什么要修改

<o:p> </o:p>

因为修改的客观存在，激起的需求便是对文件的版本进行管理——版本控制。古老而朴素的思想就是——拷贝。然而这样的版本控制解决方案仅能解决我们上面提出的第一个需求。在这样的环境下，版本控制工具（VCS）应运而生，除了从SCCS这样的鼻祖，到SVC、CVS这样时下依然风靡的中坚力量，再到Subversion这样新兴翘楚之外，BitKepper（linux就是在其控制下完成）、StartTeam（Borland）、P4等等都是版本控制解决方案的实现。

至此，我们可以清晰的知道，在SCM中，版本控制是基础，是必不可少的组成部分。应当是其他任何活动的前提。

或许有人会有疑问，我们刚刚谈到的分工协作和版本控制有什么关系呢？我们前面谈到了分工和协作的基础就是工件。而将工件纳入版本控制，这样可以加强人员之间的协作，使之更加有效。这样可以保证大家都工作在工件正确的版本上！比如A修改了一个文件，他将其修改纳入版本控制。那么当B再想修改该文件时，他应当是工作在A修改之后的文件版本上，在这个时候版本控制可以帮助，而不至于使他手忙脚乱（特别是同时面对多个文件时）。这是同一角色下人员协作的例子。一个不同角色下人员协作因版本控制而收益的场景可能会是这样：当需求开发人员变更了需求文档纳入到版本控制，开发人员能够及时发现（如何发现的呢？），从而为使开发人员工作在最新的开发需求之下。

<o:p> </o:p>

<o:p> </o:p>

Part2:衍化（变更管理之起）<o:p></o:p>

<o:p> </o:p>

       我们现在知道版本控制是SCM的一个部分。但SCM自身还包含哪些东西呢？正如我们上面的例子可以看到，协作间人员需要一种方式来知道别人的变更。而这种方式就是我们所要探寻的这其他部分之一——不仅仅使工件具有基本的版本信息，还要使变更得到有效的管理，只有真正有效管理了变更，才能使协作真正富有高效率——变更管理。

      

例如：使用普通版本控制工具的开发人员之间可能会通过制定并遵守：

<!---->Ø         <!---->每天上班第一件事情是从版本控制服务器上签出最新的源代码；

<!---->Ø         <!---->下班前把代码签回服务器；

<!---->Ø         <!---->持有文件不要太久

等等这样的项目制度来保证协作间人员彼此及时知晓最近的变更。

这是在仅有版本控制的情况下，同一角色或者更准确说是开发人员间的朴素变更管理思想。但这样的粗糙制度，孱弱而毫无保证。

开发人员各自的私有工作目录可能各不相同。经常会出现在你的机器上能够运行，而在别人的机器上确不行的情况。这种工作空间的缺乏一致性和稳定性会给进行中的项目带来极大的困扰。可见，对于开发人员来讲，简单的签入签出式的版本控制工具和一些不可彻底施行的制度是不够的！需要一种方式，把开发人员的私有工作目录也能管理起来，这样，在开发人员间也就能使变更得到更严密的跟踪和控制。而这方面则是工作空间管理的主题。

在开发人员之间因为分工而衍生出来的问题还包括后期集成构建的困难。在这方面则是构建管理的主题。

<o:p> </o:p>

那么不同角色间的人员如何实现富有效率的变更管理呢？比如客户有新的需求，那么他该和谁打交道？客户的新需求需要哪些角色的人员知晓？他们知晓的顺序应该是怎样？怎样获知完成该工作的情况？再比如测试人员在测试的时候发现了一个Bug，那么他又该向谁报告？面对这个Bug哪些人员应当参与修复？怎样修复的？怎样反馈修复的进展状况？针对前面一个例子，我们通常会在市面上看到一些需求管理的工具，它就是试图来解决这个问题。 而针对后面的例子，我们同样会在市面上看到不少的进行软件缺陷跟踪的工具，来试图回答那些问题。如Bugzilla等就是时下相当流行的免费bug跟踪工具。

分工促使了专业化生产和更高的效率，但它也增加了协作的成本。工作空间管理、构建管理使同时开发人员的人之间能够彼此更愉悦的合作。需求管理、缺陷跟踪的出现就是为了使不同角色的开发人员之间高效协作。

<o:p> </o:p>

正如我们所谈到，现在已经有很多工具都能够试图去解决某个子领域下面的问题。但我更愿意在这里把他们统统归于变更管理之下，它包含解决同为开发人员角色间协作的工作空间管理、构建管理和解决不同角色间协作的需求管理、缺陷跟踪。

<o:p> </o:p>

因为变更管理主要解决的是协作的问题。协作从其子领域看还包括一个流程控制的概念，故很多工具厂商在宣传他们的SCM工具的时候常常把流程控制作为一个售卖的亮点。而在这里，我把流程控制作为实现协作一个比不可少的步骤，而不是一个独立的方面来看待。就好像脊椎动物都要先有设计好后的一幅骨架，然后才是在上面附着血肉一样。工作空间管理、构建管理、需求管理、缺陷跟踪它们都需要一套自己的流程控制，再在各个环节进行具体的设置操作。因此流程控制和它们不是并行的概念！

<o:p> </o:p>

不知道，看到这里（或者能有耐心看到这里）的人被“**管理”、“**控制”搞昏了没有，容许我在这里多抛出一个“项目管理”，它对应于我们前面提到的“决策人”。版本控制（如普通的编程API，与应用环境无关）为变更管理（如解决特定领域的编程框架，与应用场景联系紧密）提供基础的支撑功能。除了面对变更管理，还有其他如人事变动等等SCM之外的外界变化，扮演“决策人”的项目管理者是总舵手，是船长，他需要稳健的处理所有这些更加模糊化、智能化的问题。

<o:p> </o:p>

Part3:本真（天然去雕饰）<o:p></o:p>

<o:p> </o:p>

       从最外层上纷繁复杂的“管理工具”，深刻到SCM的一般性概念。我们不禁在想，那么潜藏在SCM下面的又是什么呢？

       在我看来，SCM出现的目的是为了使软件生产的更快更好，参与期间的人也能感觉到更舒适。对软件开发商和雇员来讲，这是一个双赢的局面。

       为了达到这个目的，SCM去解决分工和因分工而衍生出的协作中遇到的各类问题。而所有这些问题，它们都有一些的共同点：

<!---->Ø         <!---->它们琐碎、机械、重复。可以通过制定制度来规范它们，解决它们。然而制度是那么脆弱，它需要专人来检查，而且因为是人在进行检查，那么变数和公正性之间的天平就很难保证了。因而，我们需要自动化！需要让计算机完成更多这样的工作

<!---->Ø         <!---->它们繁多，缺乏逻辑意义。引入SCM，我们就是要提升抽象级别，总结出更有抽象的概念，赋予它们内涵，把那些繁多的各类问题归类到这些概念下面。人更希望接触熟悉有意义的事物，这才是人的长处。

<o:p> </o:p>

归根结底的本质，或许就在于，人很懒！照Perl语言发明人Lary Wall的话说，“懒惰是程序员的最大美德”！我们人类始终在思考的就是怎样能够不劳而获，或者次之的一劳永逸。人总是在这样的动力下，有着许多的惊人的发明创造！人类发明了计算机，交付了一部分工作给它，实现了一些领域某种程度的自动化，那么作为开发软件的我们为什么还要刀耕火种呢？