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

我有过自己一个人一条龙作完一个项目的经历（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，能够自动替换到本地环境里，看到修改后的效果。不知道大家有没有什么好办法

用idea的热部署，可以解决你最后的问题

在系统测试使用时，这个热部署是个问题！有时候热部署会反应慢。

你都做到持续集成了，自动部署还是问题？
更新jsp一个脚本不就搞定了？本地的按git就用自己的代码库部署不就ok了？

关键脚本谁来执行，要手动执行的话还是不方便。你第2句话我没明白啥意思

写的非常好，既然已经把工程拆分成子模块了，那应该也加入单元测试吧。

由于参加开发的人员水平高低不能，开发的一些基础规范比如命名规范等都要强调给开发人员！
另外在一个部署含有多个系统时，各个系统必须保证其独立性，即一个系统就算崩溃，也不能影响到其他系统运行！

一个团队还停留在代码提交冲突的水平上还是趁早散伙吧

都用Hudson来搞持续集成了，自动部署不也可以搞吗？弄个部署脚本maven或者ant。Hudson不仅仅只能用来管理代码变更构建，很强大的！~

最近也在实验性的使用maven+svn+hudson+nexus。看到你的文章觉得我的选择还算靠普。。。可惜公司比较保守，不知道能不能在实际项目中使用。