多人开发较大项目的一点总结
程序员文章站
2022-05-13 18:07:24
...
我有过自己一个人一条龙作完一个项目的经历（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，能够自动替换到本地环境里，看到修改后的效果。不知道大家有没有什么好办法
总的说来，我觉得做大项目的难度要大一些。过程中也总结了一些想法，在此记录一下
首先，为什么说多人开发大型项目比较困难呢？我觉得主要有以下几个原因：
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，能够自动替换到本地环境里，看到修改后的效果。不知道大家有没有什么好办法
推荐阅读