一种不好的开发方式

最近接手一个系统的维护工作，发现该系统的现状有些奇怪：

该系统是一个B/S系统。大家知道一般这种应用就是对应一个工程，工程的目录符合规范，比如在WEB-INF下的lib包里放依赖的jar包等。然后这个工程可以直接打成war包，放到servlet容器里就可以跑起来

但是这个系统不是这样的，它是由30多个工程组成的。这些工程都不具备单独打包，单独跑起来的能力

比如每个工程都没有lib目录（有的工程甚至没有WEB-INF目录），所有工程依赖的jar包在工程外部统一管理（关键这些jar包不是静态的，比如说工程B依赖工程A打出的一个A.jar，而工程A也在时时更新中）

再比如说有的工程有web.xml，有的工程就没有web.xml，但是并不是所有的web.xml都是有用的，实际上后面会说到，只有一个web.xml起作用，其他的都是摆设

总的来说，就是有这么30多个工程。然后有一个用ant写的整体的编译脚本和部署脚本，首先需要运行一下编译脚本，把所有工程编译一遍，当然这个编译顺序是有讲究的，比如前面说过，工程B依赖工程A编译后生成的jar包，那就必须先编译工程A，再编译工程B，否则工程B就编译不通过

运行完编译脚本以后，再运行一下部署脚本，把.class文件、.jsp文件、资源文件、配置文件等一起打成一个war包

最后把这个war包扔到容器里，才能跑起来

这几天熟悉过程中，感觉比较痛苦，觉得至少有以下几个弊端：

1、最主要的问题，就是修改的代码没有办法马上验证。像一般的WEB工程，可以直接通过IDE（比如eclipse）发布到容器里，代码修改以后会马上自动编译部署，修改的结果立刻就可以看到。能够这样做的基础在于，单个工程本身是可打包，可运行的。

但是在这个项目里，根本就不可能，比如我修改了项目A的几个java文件，我总不能再全部编译部署一遍，就只好把修改后的.class手工替换到容器里面去，再重启容器进行验证

2、依赖关系很混乱，比如项目B是依赖于项目A的，那么有这样的情况，即一个小组正在修改项目A，另一个小组正在修改项目B。项目A的修改结果，没有办法实时知会到项目B小组（因为项目B的小组不可能时不时地停下来，去编译一下工程A，然后替换jar包）

所以这样就存在一个代码不同步的问题，可能白天开发的时候都好好的，因为项目B使用了项目A的旧jar包，但是到了晚上统一编译的时候，就会编译不通过，因为项目A的代码，其实在白天也已经变了

3、基础工程不稳定，造成项目非常不稳定。请想象一下这种情况，你的一个项目使用spring、hibernate、commons等多个jar包，但是这些jar包每天都在更新，每天都提供最新的jar包给你。并且每天你不止要编译自己的项目，你要先把这些基础框架编译一遍，再编译自己的项目，这是什么感觉？我感觉这个项目就是这样的一种情况

现状就是如此，我反思总结了以下3个体会：

1、不要盲目拆分工程

一个项目拆分成3个或者4个工程，然后通过某些方式集成起来，或许有一定的合理性，但是一个项目拆分成30多个工程，很难认为这种决策是正确的

2、无论怎么拆分，务必保证每个工程的独立性

即每个工程自己要能够发布成war包，独立地运行起来。否则代码的修改验证就是一场噩梦

3、稳定的工程才打jar包

将代码打成jar包，虽然没有本质区别（一段代码依赖某个类com.xxx.SomeClass，这个类的代码放在工程里，或者放在一个jar包里import进来没有明显区别），但是打成jar包就是进行了一次封装

如果是一个工程中的代码，你可以立刻修改它，看到结果；但是如果是从另一个工程里打出来的jar包，那么如果要修改它的话，那么至少，你要多一个编译打包的过程。这个区别很小，但是有时就会带来很大的麻烦

所以，如果基础工程还不稳定，就不要打成jar包。可以先“裸”在工程里，有问题随时改。这部分代码用了一段时间，经历几个版本，很稳定了，再抽取出来打成jar包也不迟。而不是像这次这个项目一样，好几个所谓的“平台工程”，天天在改代码，天天出新jar，还要打肿脸充胖子

疑惑：

我做过的十来个大大小小的项目，一般都是一个独立的工程，或者是若干个可单独部署的工程组合起来的，像这次这种情况我没有见过。

究竟是这个项目确实错了，还是我个人见识太浅，希望有经验的人可以谈谈看法