作为一位从事软件配置管理工作的同志，我经常被亲朋好友问到的是，我有时候要向各级领导游说的是，啥叫软件配置管理？
我的经验是：

1. 如果想让他们从迷茫到更迷茫，那就跟他们背一段ISO/CMM里的定义。

2. 如果不想深谈，或者背景实在相差太远，那就跟他们说：
“当很多人在一起编写软件的时候，需要一些专门的管理和技术，让他们能够合作顺畅。
软件配置管理就是其中的一种。”

3. 如果大概讲一下，能有个概念，那就跟他们说：
“软件配置管理是围绕软件资产的管理。
啥叫软件资产呢，就是设计文档啦，源代码啦，可以跑的程序之类的。
那么，有什么要管理的呢？让我们把它和图书馆的图书管理做个对比。

它们有一些相似点。
首先，图书馆图书管理管的是图书资产，软件配置管理管的是软件资产，它们管的都是信息资产。

其次，图书管理，需要把图书进行分类，以便检索，需要图书存放在合适的地方，以便存取，还要防止虫吃鼠咬。
软件配置管理也类似，需要把软件资产——主要是源代码什么的，放在合适的目录结构里，放在合适的地方存储，防止丢失或者弄乱。

再次，在图书馆，要记录谁借出了哪本书，还没还。
而软件配置管理中也类似，需要记录谁借出了什么文件。
不过，跟图书管理不同的是，软件开发人员借出文件，常常是为了修改它。
软件配置管理要记录谁修改了什么文件，为什么修改，等等。

这里就引出了一系列事情要考虑：
比如，每个文件，不断修改，就产生了一个又一个的版本，需不需要存储呢？
一个产品的整个源代码树，也在总体上产生一个又一个的版本，需不需要存储呢？
怎么存储呢？

比如，可能两个人想要同时修改一个文件。这可能会导致一个人的工作丢失。
那么，是让他们一个改完了另一个再改呢，还是让他们同时改，将来合并呢？怎么保证呢？

再比如，有时候，一个公司会生产一系列相似的软件产品，它们之间是不是可以有某些共享呢？
在一个产品上的改动，是不是能比较方便的加到另外的产品上去呢？

所以说，软件配置管理是围绕软件资产的管理：
保证它们的存储；保证改动它们的时候，也就是进行软件开发的时候，不会产生混乱，有条有理，省时省力；等等。”


第3种解释，是我最喜欢的解释。
虽然还不完全（比如，没有说配置/关系），也不严谨（净是用劳动人民的大白话说的），
但是能给没怎么接触过SCM的同志一个比较正确、比较容易接受的第一印象了。
而且让人觉得，SCM确实有用~~~

Baseline（基线）是一个容易让人困惑的概念。为啥容易困惑呢？往深了说，有文化方面的因素…… Baseline是他们欧美人常用的一个概念，远不止在SCM领域……咱还是往浅了说吧……
即使在SCM领域，Baseline也有相互间略有区别的几种含义。
第一种，最常见，指源代码树的Snapshot（快照/断面）。当然，不是任意时刻的一个Snapshot都是Baseline。基线通常意味着，首先，被明确的标识出来，将来可以复现，比如用一个Label/Tag（标签）标识；其次，达到了一定的质量级别，比如，编译通过了，或者粗略测试通过了，或者系统测试通过了。这样，基线就好像脚印。只有踩实了这一步，才去迈下一步…… 如果项目不大，清清爽爽，一切尽在掌握中，你可以蹦蹦跳跳。但是，在上规模的项目中，在深浅未知泥潭里，还是稳一点吧……
第二种，指一份文档的某一个版本。这个版本，质量比较好，没啥错误或者前后矛盾的地方。相关的同志也都看过了，一致同意，都点了头。那么，这个版本就作为基线了。大家以后都要遵守。如果是需求文档，那就轻易不要变了，要根据它做设计。如果是设计文档，那就轻易不要变了，要根据它做实现…… 这里，基线有点儿像结婚…… 也就是说，真不成，也能离婚…… 轻易不要变，万不得已还是可以变的，只不过变起来比较麻烦，得先再次征得相关同志的一致同意（一般来说）……
第三种，不是一份文档了，而是一个项目的“所有的”文档和“所有的”源代码在一起的一个断面。这个断面，除了要保证有一定的质量外，更重要的是，1. 达到了某个阶段性目标，比如，系统设计完成，或某个重要功能实现。2. 基线内，各文档间，文档与源代码间，是一致的。文档上说，点一下按钮，蹦出三只红眼睛兔子，那源代码就要实现蹦出三只红眼睛兔子，四只是不行的，绿眼睛是不行的，耗子也是不行的…… 通常，这样的基线，就可以对应到项目的Milestone（里程碑）上了。
从频度上说。第一种基线通常比较频繁。可能一两周一个，也可能一两天一个。第二种基线，每个文档可能只有一个，也可能后来有修改，有又几个。第三种基线，数量有限的几个，通常是项目起始时就计划好了。
就写到这儿吧。原创。难免有偏颇的地方。还请大家多多指教，一起交流！

请不要误会，这个不是在将面向对象发展史。只是说说我和几位同事在聊各自学习面向对象的过程。感觉很有意思。特意拿出来与大家分享。

我最近在思考写一个系列的面向对象的文章。找不到思路，于是请了几位同事，请教他们在学习面向对象过程中的想法。下面是他们的说法。

J君:

1. 在大学里学的C语言，C++和java是自学的。
2. 开始是理论派，视面向对象为神圣不可侵犯。
3. 进入公司后学习Delphi，有些地方不是很习惯，比如接口
4. 主要工作是做业务模块，经过大量开发过程后，开始感悟面向对象不是一切。
5. 接触动态语言（python,ruby）和函数式语言(lisp,haskell），开始批判的眼光看面向对象。
6. 不能为了对象而对象，不是所有原则都是对的，关键在于你能得到什么？

H君: 

1. 动态:先从继承的概念理解
2. 静态:慢慢开始用类来组织代码，可以认为是封装的概念 
3. 关系:和数据库中的表的关系一样，慢慢理解系统是有对象及之间的关系组成的。 
4. 变化:从设计模式学习开始，慢慢理解系统是变化的，而对象的设计也是针对变化的。 
5. 思想:面向对象的根本思想，是使用对象这种思维模式去理解整个系统。面向对象，其实是对象面向系统，从而设计对象的独立接口。

S君: 

1. 大二开始学习面向对象语言C++，对于概念死记硬背 
2. 理解封装的概念 
3. 认为对象是IT行业中，用来描述系统的元素，就像几何中的点线面一样。都是一些概念。
4. 深入Delphi的VCL，对对象的理解深入
5. 感觉对象关系比较简单，程序员看的世界都这么简单，其实有坏处。最好从其他系统中介入。

L君: 

1. 大学时候没有学习面向对象语言
2. 所有思想都是从Delphi开始接受，其实就是进入公司后开始学习的。 
3. 由于没有面向过程语言的困扰，所有的面向对象思想，都顺其自然地接受，认为天然如此而已。

一开始的时候，我还给我的系列，命名为《Inside Object》，我发现，其实大家很多时候都是从一个Outer到另一个Outer。开玩笑地讲，说不定以后又会想写《Out Of Object》系列了。不过，那是后话了。

观察上面的，有一个共同的情况，那就是面向对象并不是一开始就能接受的。往往需要通过好几年的反复才能深入理解。在S君刚上面向对象课程的时候，他的老师就非常明智地指出，你们一开始不可能理解得了面向对象，现在你们所需要着的是，记住他们！

另外，我们也应该关注到，我们在和人沟通面向对象思想的时候，需要注意到理解的层次。而如果我们愿意帮助别人在这方面成长，是否也要关注学习的阶梯呢？

说是学习史，其实更是想和大家一起讨论一下如何来学习面向对象思想。欢迎大家反馈，说说你们的学习心得。