包子的配置管理（转帖）

Kingson

我家门口有个蒸功夫包子铺。我常去那儿买包子吃包子。有一次，老板跟我聊起来，问我是干什么工作的。我说，软件配置管理，就是一帮人一起编程序，我帮忙组织组织。老板说，哦，我就觉得我们这儿管理有点乱，要么你给出出主意？

      以下是我出的主意。

      “首先，先要考虑包子的原材料有哪些？做包子需要哪些炊具灶具？需要煤气罐还是柴火？所有的这些，都要登记造册。”

      我看到老板点了点头。于是继续往下说。

      “为了简化起见，我们拿做一笼包子来考虑：步骤一，标记一下各原料。比如，面一坨。我们就要填表，表上先给这坨面起个名字，比如 蒸功夫-北京-39-面-2007-03-19-18:01:22。表示蒸功夫北京第39号店，现在刚和好的一坨面。嗯嗯，这样不够专业，现在都兴用版本号，比如蒸功夫-北京-39-面-3.1.9.build3721。不过，如果是这样的话，需要对版本号有严格的规定，什么时候升第一位，什么时候升第二位，什么时候升第三位。第四位是Build Number，也就是构建号，此位只升不降，只要全国蒸功夫店新和出一坨面，这一位就要加1。也就是说，每次你和好面，需要给蒸功夫总部打个电话，申请一个新的构建号。这个很重要的，不然面和面之间就容易混了。全国唯一的号，这多清晰！”

      老板欲言又止。因为我用坚定的目光看着他。我接着说，

      “不仅面是这样，馅儿也是这样。油啊盐啊，要记录下是哪个牌子的，用的是哪一袋哪一包。这个比较容易，记下条形码就可以了。我 们要保持原料的可跟踪关系。里面放的猪肉馅儿也一样，要跟踪到是哪头猪的肉。厄，买猪肉的时候，您把猪的编号抄下来没有？现在猪有编号没有？”

      老板摇了摇头……

      “没关系，你买肉的时候，在每块儿肉上编一个号。再在一张表格里写上这块儿肉多重，从哪个摊位进的，几时几分进的。再让肉贩子签个字。这样，出了问题你就没责任了。是肉贩子没建好跟踪关系。不过，你一定要建好肉块儿和肉馅儿之间的跟踪关系，把肉馅按每个包子的分量分成小份，并记录下每小份对应于哪块肉。”

      “包子皮也一样，每个包子皮都要编号，不是那一坨面编了号就可以的。对了，刚才忘说了，刚才对包子皮的编号，还应该有个属性，可以取一些枚举值，比如，已和好，已醒好，已赶好，已包好，还有作废——对应于掉地下的情况。随着面的形态的变化和质量的变化，这个属性的值也在变化，专业的说法是，Promote Baseline！”

      “另外，还有一个复合基线的概念。每个包子皮有个编号，每个包子馅儿有个编号，那么，当它们包在一起之后，就应该有一个总体的新的编号，包子的编号。并且，这个编号与包子皮的编号和包子馅儿的编号之间，应该有明确的对应关系，也就是说，包子作为一个子系统，它的编号与它的组件之间的编号应该有一定的对应关系，这种关系应该被记录。在这里，包子的编号，就是复合基线……”
我刚开始说的时候，老板满脸疑惑，时不时问一两句。后来就不问了。瞠目结舌。老板的小儿子后来也凑过来听听。那小子是个愣头青，素质比较低。他听了一阵，回身抄起一把铁锹，骂骂咧咧的，向我扇过来。我夺路而逃…… 边逃边遗憾，刚谈了谈配置识别，我还有配置控制、状态统计和配置审核没有说呢…… 配置管理工作真是不好做啊……

=====
      上面是个黑色幽默，相信不少同行看了都会会心一笑。不过为了清楚起见，还是让我多说两句吧。
      软件配置管理，来不得教条，不是照搬某个标准就可以的。不同的开发背景、不同规模的团队、不同的协作方式等等，都会对施行哪些管理、具体的施行方法、以什么样的力度施行等等产生不小的影响。问题的关键在于，在你的组织里所进行的软件配置管理工作，是不是真正有价值？也就是说，投入和耗费是不是有很好的回报和收益？你是否经常考虑这一点？

[ 本帖最后由 Kingson 于 2007-6-7 15:11 编辑 ]

crystalpear

通过这个故事，大致也能了解到软件配置管理是做什么工作的。

fzh1013

很琐碎很烦人的一件事情...包子铺开成这样还不如关门算了,,呵呵