最近开始阅读《人月神话》，读到“外科手术队”章节，我就明白了这本书能如此受青睐的原因。
人月理论是不能应用于项目计划的，人数和时间并不是成简单的反比：人数的增加，则意味着不同思维的增加和交流的增加，当这一切默默的纠缠在一起后，项目就渐渐沉入沼泽。
传统的项目计划和任务分配方式，是将一个系统分为多个子系统，将每一个子系统的设计和编码分配给其中的一个或者几个programer。这种模式下我看到的现象是，一个无比混乱的组合，没有一个人拥有这个组合的完整的概念，包括main-programer；每一个programer只是随机（虽然他们都经过认真的思考，并有可能选择了最佳的位置）的将子系统插入到这个组合之中，唯一的期望是子系统可以工作。
我想这一景象很多人会心有感触，这一传统的模式还是很普遍的，因为我就身在其中。
外科手术队是这样一种模式：一个或者两个主刀医师，main-programer或者framework-designer，负责定义整个系统的概念、约束和控制流，并将他们的工作成果交给programer去实现。就好比建筑师统一设计好了蓝图，然后由建筑队负责施工。试想如果建筑队里面的每一个家伙都兴趣盎然的给建筑的某一部分进行自己独有的设计和实现，并为了组合而相互妥协，那最终建成的东西将会是何物？
想必多数人对外科手术队模式的反映是：“所有的乐趣都被main-programer和framework-designer剥夺了”，“programer岂不是沦为coder，毫无前途可言”。但其实不是，外科手术队并没有外包那么夸张，主刀医师只是定义了整个系统的概念、约束和控制流，但是并不出设计文档之类有关实现的东西，并且任务仍旧以子系统（已经被定义和约束）的形式分配，因此programer能在指定的约束下进行创造和实现。
有关外科手术队模式，我有过类似的经验。一个little-demo，3人的合作，我提取了其中所需要的所有的类，并为每一个类指定了接口，以及安置位置，也就是概念、约束和控制流。我拥有整个系统的完整的概念，但是我没有任何实现，我可以把它的每个子系统交给任何人实现，因为我清楚一切都能工作，不能工作又是谁的责任。每个programer可以选择任何实现方式，并在实现方式上进行设计。
OK，有关《人月神话》的内容暂时先这么多吧。

PS：另一个考虑的事情，是重构。似乎没有多少项目组，会在自己的项目计划中为重构保留时间，理由多半是进度和成本···但问题的严重性在于，传统的项目计划模式（非外科手术队模式），所组合出来的系统，本身就缺陷冗杂，如果没有适时的重构，病情只会越来越严重。因此我期望的模式是，为项目计划保留重构的时间，当项目版本进行到一定程度，大多数组员都认为系统需要重构的时候，就给出一个重构的版本周期，全员投入到重构当中。
重构会影响进度和成本，却没有多少证据证明这个论断：因为人们在尝试有益的事情之前，都直觉上的拒绝在重构上浪费时间，这只是一种只能看到短期利益的目光罢了——设计和编码并不是系统开发的全部！

再PS：老久没有更新BLOG了，结果排名之类的反而又升了一点····无语