多人开发较大项目的一点总结

我有过自己一个人一条龙作完一个项目的经历（7万行代码），也试过在一个20多人的团队里参与一个更大的项目（40多万行代码）

总的说来，我觉得做大项目的难度要大一些。过程中也总结了一些想法，在此记录一下

首先，为什么说多人开发大型项目比较困难呢？我觉得主要有以下几个原因：

1、沟通的问题。如果是我自己一个人做，我对自己的想法和思路肯定是很清楚的，就不存在交流的成本和障碍

2、为了维持架构和设计的一致性，需要额外的努力

3、涉及到并发的问题，比如代码提交的冲突、依赖的冲突等，在单人开发，或者小团队开发时，比较不容易遇到

4、大项目本身就有比较高的复杂度。小项目可能一个工程就可以搞定，构建和部署都非常简单。但是大项目就需要拆分工程，构建、部署都会比单工程复杂非常多。即使是2个工程，也比1个工程复杂得多，是1和N的区别

对于大型项目的合作开发，我有以下的想法：

一、项目的总体架构和设计

应该由一个小团队，在开发启动之前，先完成项目整体的架构和设计。对于“架构”一词，每个人都有自己的理解。我个人的理解来自于POEAA，“架构是对系统最高层面的设计，及不能轻易改变的东西”

这个阶段需要输出很多东西，包括但不限于：逻辑架构图、部署图、开发者视图、模块依赖关系、代码框架（分层、公共组件、包结构等）、平台（权限、UI、日志、SSO等）

以下东西我认为不应该在这个阶段输出，包括但不限于：模块内详细设计、具体特性设计等

这个阶段，实际上规定了后续开发中的整体框架，也需要解决主要的技术风险

举个例子，某项目由多个子系统组成，几个子系统之间决定用JMS来集成。如果在开发阶段，才临时决定改用web service来集成，那对整个项目的进度和质量都必定会造成很大的冲击

又比如说，某项目在这个阶段决定使用OSGi，但是又没有完成原型开发，在开发到一半的时候，才说实现不了，那这个完全就是一种搞笑的行为

二、开发阶段的注意事项

1、构建工具

前面说到，拆分多工程之后，系统的构建和部署的复杂度就会成倍上升，因此选择合适的构建工具就非常重要（单工程的项目，直接用eclipse的export功能就可以了，修改的代码也可以即时生效）

目前我觉得maven是一个很不错的工具，除了比较好地处理了依赖管理之外，还可以比较容易地进行分模块地开发，与CI的集成也很不错

2、源码和构件的一致性

不过用了maven的话，开发过程中就同时存在源代码，和构件这2个东西。如果源码和构件不一致的话，就会发生很多问题。因此必须要想办法，保持源码和构件的一致性

3、CI

越大的项目越需要CI。如果是比较小的项目，我觉得CI倒未必是必须的，nightly build就挺好，或者每天手工构建一下问题也不是太大

4、提交冲突

如果多个开发人员修改同一个模块，甚至是同一个文件，就要想办法解决提交冲突的问题。或者2个开发人员负责的模块之间有依赖关系，也要避免提交后的编译问题

三、一种可行的开发流程

针对上面说的这些问题，我们在开发过程中总结出一套流程，还是比较有效的，用到了maven、svn、hudson、nexus

首先项目经理，和各组长的机器上应该有全套的代码，这样可以及时发现、定位问题。另外也可以在必要的时候手工执行完整的构建（先全量更新，再整体构建）

其他开发人员，只需要check out自己负责的工程（及总的parent工程），然后就只需要维护好这个工程就可以了

如果在本地构建（package）时发生错误（编译失败或者UT失败），则与所依赖的下层模块的开发人员沟通，共同定位问题。本地构建成功之后，则将代码提交到svn

此时hudson轮询发现svn代码有更新，则全量更新所有代码，然后执行一次整体构建。如果构建成功，则把代码deploy到私服上。如果构建失败，则发邮件通知相关代码的责任人，及项目经理

这样做的好处是，开发人员不需要关心周边的代码，可以把注意力集中在自己负责的模块上。研发过程也提倡“高内聚，低耦合”；另外可以保证源码和构件的一致性

四、集成环境与本地环境

CI系统在整体构建之后，会将系统部署到集成服务器上，因此在集成服务器上看到的是系统整体的最新状况

除此以外，开发人员自己的机器上，也应该都有本地环境，才能比较方便地调试，并验证本地构建的正确性

开发人员A环境上的系统，和开发人员B环境上的系统，肯定是不一致的。A做的修改，在B上是没有办法即时看见的，这个是正常现象。如果要看到完整的最新系统，需要在集成服务器上看

有一个问题是，开发人员修改代码后，需要手工替换到本地环境上验证。我们目前还没有想到更好的办法，把这个步骤也自动化。比如说，改动了abc.jsp，能够自动替换到本地环境里，看到修改后的效果。不知道大家有没有什么好办法

评论

2 楼 ganbo 2015-11-06  

写得太好了，最近正在学习maven构建项目，看了楼主的文章后，感觉受益颇多。

1 楼 key232323 2013-02-05  

前面写的8错——

最后一个自动化本地部署的问题，我目前也是做的手工，自己写一个简洁的build的脚本，不过做成自动化应该不麻烦吧，做一个定时，记录last modified time，有修改，就运行这个build对应的块就可以了

如果文件不多，整个运行都没问题，如果文件很多，可以分成块，根据修改的文件路径判断执行哪个快就可以了

定时效率估计不会高了