组织团队开发项目的方式

    一个项目通常分为表示层、业务逻辑层和持久层，这是最为常见的三层结构。在组织团队进行项目开发的时候，选择如何分工对版本控制有很大的影响。团队在做开发的时候一般有两种模式：按层开发和按功能开发。

按层开发（本人赞同的模式）

    在这种开发模式下，每个开发人员的目录结构相对固定和独立。对于CVS这类按文件夹来控制权限的版本控制服务器来说，比较容易实现对开发人员权限的划分，不易出现文件不同步而导致的版本混乱。

    另外，这种开发模式下，更能集中开发人员的注意力，不需要了解太多与本层无关的其他技术。将精神全部集中在如何实现本层的功能上，更有利于写出功能强大，运行稳定的代码。例如：开发业务逻辑层的开发人员，他不可避免的会写很多逻辑上基本上一致的代码，在写代码的过程中，就能从中找出一些相对的共性，将公共的代码进行抽象，从而避免了出现大量的重复代码。由于工作范围相对较小，能有更多的时间去学习相关方面的最新技术和解决方案，并应用到程序中，能使程序在实现方式上较为先进、优越。

    老天是公平的，万物有其好的一面也必然有其不好的一面，这种开发模式也不能例外。对于需求不明确，无法定义相对固定的对外接口时，这中按层开发的模式就有其无法避免的一个问题。各层开发人员需要在开发的过程中，反覆的修改接口，以便适应于变化了的需求。这必然就导致逻辑处理部分代码要做相应的修改。

按功能开发（本人持保留态度）

    这种开发模式下，开发人员的目录结构基本是项目的完整目录接口，他们需要到各层去编写对应他们所开发的模块的所有代码。对于CVS这类版本控制服务器来说，基本上是无法做到对开发人员权限的界定。很容易造成版本控制混乱，导致文件版本不同步，是在开发过程中使用了公共文件的开发人员不能保证同步。例如：一个文件为多个开发人员所共同维护，开发人员各自都需要在其中添加自己功能所需要部分的代码。这样很容易出现多个人同时修改一个文件的情况，导致文件不同步而造成的版本混乱。

    另外，这种开发模式对开发人员的技术要求相对较高，它要求开发人员掌握各层中所需要的技术。从界面显示到数据持久化，甚至到网络通信都需要一个开发人员去实现。在功能实现架构不是很确定的情况下，程序代码中将会出现大量的重复代码，因为每个人都有自己的实现机制，而逻辑处理相同或相近的情况在同一层中出现频率又比较高。导致程序的整体结构不统一，尽管层次结构相同。使得程序日后维护极度困难，大大的提高了维护成本。由于开发人员牵涉使用的技术过多，也很难保证程序实现方式的先进性和优越性。

非飞 2005-03-03 21:06