我现在所在的公司是维护自己网站的，现在从当初小的规模已经渐渐变成大型的网站，但是随之而来的麻烦的事也出现了，比如，在一个web工程中有上千个配置文件，有上万个java类，而且各个子模块之间有很多耦合性。导致我现在启动web工程需要2分钟，有时启动的时候甚至会内存耗尽。
现在的情况是，我自己维护的模块其实只有几张jsp页面，和几个java累，倒是混合在这个庞大的代码沼泽中，如果别人提交svn的代码有啥错的话，往往会导致我无法启动，为了查找原因我常常需要花很长很长时间。这样导致我写代码的效率很低，而且每次为了调试而启动tomcat的时候常常需要花很长时间。
上面的头儿可不管底层架构如何，他才不管架构是否混乱，但是我也知道这样下去是肯定不行的，总有一天我会没法调试web程序的。
我也想过将一个大的web工程分成几个context，但是，这个分离过程非常麻烦，如同抽丝剥茧一样。
不知道有哪位有架构师有维护大型网站代码的经验，在一个大型的web项目中实践分而治之的原则。
最近我们听说有osgi，听介绍的时候貌似可以解决我们现在的问题，我想听听有哪位大侠能够给我指点迷津。
现在的情况是，我自己维护的模块其实只有几张jsp页面，和几个java累，倒是混合在这个庞大的代码沼泽中，如果别人提交svn的代码有啥错的话，往往会导致我无法启动，为了查找原因我常常需要花很长很长时间。这样导致我写代码的效率很低，而且每次为了调试而启动tomcat的时候常常需要花很长时间。
上面的头儿可不管底层架构如何，他才不管架构是否混乱，但是我也知道这样下去是肯定不行的，总有一天我会没法调试web程序的。
我也想过将一个大的web工程分成几个context，但是，这个分离过程非常麻烦，如同抽丝剥茧一样。
不知道有哪位有架构师有维护大型网站代码的经验，在一个大型的web项目中实践分而治之的原则。
最近我们听说有osgi，听介绍的时候貌似可以解决我们现在的问题，我想听听有哪位大侠能够给我指点迷津。
---------------------
你这个够雷的，重构都难。
把每个模块当成一个工程 发布
每个工程都用web service去偶联
我现在做的项目就是这样的
我们每个人都是在开发自己的模块
放到tomcat中启动就可以了 在webservice中的service.xml配置接口 实现接口
不知道 会不会给你点提示
经过几个月的摸索，我们终于找到了一条可行的方案：
1.就像 xuyang840117所说的那样在服务端用webservice类似的协议将各个模块按照业务来解耦，不过我们用的是java分布式解决方案中常用的rmi协议来解决。
2.使用osgi的方案来解决原服务器端的各个模块之间的解耦，这样原先各个模块之间还是有耦合，但是能够实现热插拔，可以对系统中的某个单独的模块进行开发测试。这样对开发来说效率就非常高了。daisycool 说的mvc的开发模式我们一直在用，但是问题是我们的程序员没有很好地理解mvc的真正意义，所以经常会将一些control的业务逻辑写到jsp中去造成页面难以复用，所以在项目开发过程中，必须要建立一套详细且清晰的规约，让大家来遵守，这个是非常重要的。
这位老兄说的我深有同感，现在公司中的诸多所谓的大牛只对什么分布式存储系统，什么分布式cache系统，什么异步消息系统，这些看起来比较高深的东西感兴趣。但是对我们最基础的代码报以能跑就行的态度，在开发的时候根本没有什么统一的规范，web工程中已经下线的代码也不去掉，弄得现在代码悦来越大，像一个庞然大物。
代码能跑就行了，我觉得有这种想法的人只是把程序当作混口饭的职业来看待的，一个真正意义上的程序员必须是像爱戴自己的亲人一样地，爱自己写出来的程序，经常会用苛刻，并且挑剔的眼光来审视自己昨天写过的代码到底有没有什么不完美的，进而来打磨它，让它更加完美。
我们个人的力量虽然有限，在一个公司里你的职位不够高根本没有话语权，即使有话语权，也要考虑在项目上线截止日的约束下有没有足够的资源来做这件重构这件事。但是，没关系，我告诉我自己，我是一个优秀的程序员，我会竭尽我所能来把这些技术难点来攻克，这就是我的价值。
如果需要看代码的话可以发邮件来。
http://blog.csdn.net/mozhenghua/archive/2010/01/16/5199209.aspx