多子系统集成项目的总结

这次做的项目，涉及到6个子系统的集成，其中有2个是遗留系统，4个是新开发的系统。我负责其中一个新系统

前期还是比较顺利，提前完成了开发计划，并进行了比较充分的代码检视、单元测试和内部测试。但是在进入接口联调和系统集成以后，就变得非常痛苦，这2周平均每天工作时间超过16个小时。但是整个系统还是没有稳定下来，还是有非常多的问题，而且每天的效率非常低，大部分的时间都是花在等待中

为什么这次在开发这么顺利的情况下，在项目后期却会陷入这么糟糕的局面？怎么样才可能比较顺利地完成一个较大的系统？我从项目启动的第一个环节开始，对每个过程进行反思

1、做好需求

现状：我认为这次的需求做得不到位。一方面猜想了比较多的需求，与客户却没有充分地沟通过，这就造成工作量的浪费。更糟糕的是为了满足太多的需求，也影响了系统的架构，造成系统架构的臃肿，这个在后面会详细说明。另一方面，或许有一些客户真正关注的需求，我们却没有实现，这个可能会给后期系统的推广造成困难。

原因分析：会出现上述的2方面问题，我觉得本质的原因就是和客户的沟通太少。需求基本都是凭空猜想，或者根据部门内业务专家的经验推断。虽然业务专家确实有比较高的业务水平，但是毕竟不能完全代表真正客户的想法。所以与客户的沟通太少，也没有积极地邀请客户参与到系统的每一轮阶段性展示活动中。这使得我们系统的需求做得比较糟糕。

总结：应该采用敏捷开发的方式，在尽量小的迭代周期内拿出系统的小版本给客户演示，按照先核心需求，再逐步丰满的方式，不断地调整需求。与客户充分沟通，既保证满足核心需求，又避免工作量的浪费

2、宁可没有架构师，也不要找一个扯淡的

现状：或许大公司都会有这样那样的政治因素，这次项目的所谓“架构师”就是一个大忽悠。

这个系统，估算是200左右的并发规模，可以认为相当于不存在并发问题；然后数据量的规模也不大。如果简单处理的话，可以是一个逻辑架构和物理架构都非常清晰明了的系统。我个人认为，就一个应用服务器+一个数据库服务器，就绰绰有余了。即使以后数据库压力大了，再上数据库集群不就行了。毕竟这是一个业务系统，不是一个互联网应用，根本就不存在并发和海量数据的问题。这样简单处理，我认为是合适的

但是这个“架构师”，整上的东西就很多了：

要先上2个数据库，一个存放业务数据，一个存放资源数据。这样2个数据库就要同步来同步去。这周另外1个小组，就为了这个同步的问题熬了一周的通宵

子系统之间要走所谓“服务框架”，其实就是对CXF的一个封装，没任何意义，纯粹引入复杂性。其实每个子系统开放一个Servlet都可以了。这个服务框架带来的问题，伴随6个子系统整个开发流程，开发时间至少增加1/4，没带来任何价值

然后来个日志框架，其实花半小时自定义一个Appender的扩展就可以解决问题

业务可能有变化的地方，整个OSGi。不好意思，开发已经延期2周了，现在大家都还没做出来。我说真有新功能，再发布一个升级的PATCH不行？何况这个系统就没热部署的需求，业务也很稳定，强行上个OSGi，这不是有病？

本来还要上分布式，幸好大领导终于意识到风险太大，制止了。。

关键是这位“架构师”，提出了上述种种方案之后，人没了？你找他谈实现，他就给你说原则。如是再三之后，我得出一个准确判断，这些方案，他自己就听说过名词。是干什么的？知道一点。怎么实现？不好意思

总结：架构要保持简单，一个数据库能解决的问题，就不要弄多个数据源同步。不准备开放给外系统调用的接口，就不要上web service。什么扯淡的分布式，OSGi，我就不评论了。当然我不是说这些技术不好，其实我对这些技术也非常感兴趣，但是毕竟是做系统，不是在玩过家家。用在合适的地方的技术，解决实际问题带来价值的技术，才是好技术。过度架构，就是200个兄弟的累死累活，就是系统的延期，就是项目跑不起来

3、其实做好上面的2项：分析清楚需求，不瞎做。保持适当架构，不折腾。一个系统到后期就不会像这次这么痛苦了，我认为上述2项是最重要的。后面的都是比较细节的问题

4、越早对齐数据库越好

服务端有2个数据库（Oracle），终端有1个数据库（SQLite），所以存在数据库字段不统一的问题。前期我们自己跑服务桩，啥问题没有，到了集成的时候，各种数据库字段对不齐，有的是类型不匹配，有的是长度限制不匹配，有的是非空约束不匹配，等等。大家都知道，到应用稳定以后，再去改数据库模型是相当痛苦的，因为从数据库字段，到模型对象，到DAO，都要改，不仅开发有工作量，测试也有工作量，越到后期，这个代价越大，所以应该尽早地对齐数据库

这个责任在我，是我系统集成经验不足造成的。这个教训我记住了

5、仅仅在文档层面对齐接口没用，对于涉及到多个子系统集成的项目，可以“接口驱动开发”

前期所有6个子系统，都是自己玩自己的。单元测试都不可谓不充分。也都模拟了实际场景，终端为了模拟测试业务场景，我还亲自写了一个完整的服务端桩。但是即使这样，到了集成的阶段，系统还是各种跑不起来。

其实前期领导就很重视对齐接口，每个子系统的负责人，花了一个星期来写接口文档，各子系统互相评审，并签字确认。到头来，没有用。因为实际运行的不是文档，是代码。文档虽然已经描述清楚了交互协议，每个字段也都对过了。但是接口太多，有的接口也相当复杂，在没有实际测试的情况下，谁也不能保证100%是按照文档来操作的，何况文档也不能保证是100%正确的，毕竟在开发过程中，变更是绝对会发生的，但是未必文档就能及时刷新并知会对方系统。

所以这种涉及到多个子系统集成的项目，我强烈认为应该以接口来驱动开发。每个子系统，首先实现接口。当然在开发早期，每个子系统内部的业务逻辑肯定没实现，不可能有真实业务数据，但是这种时候，可以先传递符合格式的假数据，照样可以让接口跑起来。这样到系统集成阶段，就节省了非常多的工作量。我敢保证效果绝对比这次好。

6、早点集成，不能拖到最后一起集成

这条其实和上一条强相关。这次项目基本做到了每天SVN上的代码是可运行的小迭代。但是都是每个子系统自己玩自己的。应该缩短集成的周期

当然由于每个子系统的开发进度不同，很难做到像单个子系统内部一样每日集成（我怀疑是根本不可能）。但是至少也应该可以做到半个星期或者一周集成一次。把集成的工作放到前面，可以更早的暴露问题，更早的调整。效果一定也比这次强

以上是本次项目过程中个人的一点总结。此外在代码层面，也有一些心得。包括Android应用的分发模式，Android应用的简单ORM框架，Android日志规范，接口设计，Android服务管理等。待系统集成完之后，再总结一下

LZ是腾讯的？

楼主写的很好 ，感觉说的很有道理。
但是第一点我不得不说，客户的需求是无止境的

支持，这种情况深有感触。

正常的需求变更时很有可能的，但是初次需求和变更需求差了十万八千里，这个就不好办了
需求明确确实非常重要，软件是给人用的，不是给电脑跑着玩的

写得很好！支持！！

看来人要强硬才行啊。自己认为是正确的就坚持下去，如果妥协，倒霉的还是自己。

看了LZ经验上有点少，这个不着急，慢慢来就好

每日集成是可能的，但是需要制度的约束