组建依赖带来的思考

组建依赖带来的思考

入题：
使用 SSH 个人感觉 最大的隐患就是 升级维护。包括SSH之外的其他组建比方说Log4j,Dom4j等，到不是说这些组建不支持扩展和他们维护困难。
设想如果有这样的一个项目 WebMap，它是提供Web地址查询并且提供地图显示功能。在开发阶段开发团队可以充分发挥SSH的性能。但是随着时间推移。项目需要升级维护。一个新的复杂查询需求提出，如果此时SSH没有版本改动那么还是好事。如果SSH有部分组建已经升级。（比方说Struts从1.x升级到2.x）此时SSH组建升级你只能望尘莫及。因为你的项目使用的是老版本。新版本很可能对你当前项目不兼容，所以不可能花费大量的时间进行项目重新开发。
即使你拥有时间开发，在长时间的网站运行维护中很可能整个Web站点上已经提供了一大堆的外围功能。 如果仅仅因为一个新的需求就要重新开发整个项目这对网站运营者来说是一个致命的一刀，对设计者来说是一次否定。
谁都想让自己设计的项目完美，能够胜任长时间的技术、需求变更。这就需要我们选择的组建变更不要太频繁。这又是很难的，因为一个组建的版本变更意味着它变的更强大更完善。在选择技术时候我们都在考虑这个技术的发展前景，如果一点前景都没有我们在去选择它，这是多余的。毕竟新的总要淘汰旧的。
回到我们的议题中，新的需求到来时我们的SSH组建已经升级，新版本的组建中提供了大量实用的工具和技术策略让我们快速的解决新需求带来的开发时间。但是由于维护的项目使用的是老的技术设计，所以我们不能冒昧的替换原有的SSH框架。因为我们无法确定新组建在原有框架上运行的稳定性和兼容性。为此我们需要做大量的测试来确定。这是在最初系统设计时没有考虑的。
如果使用老技术完成新需求可能我们需要很长时间用来解决新需求需要的算法和逻辑实现。这是一个相对我们可以接受的一个办法，很多企业都在这样做。
但是这样做又存在另外一个隐患，那就是如此长期维护下去，整个项目可能到最后非常混乱。搞的维护人员对原有代码不报任何期望，他们开始自己开发新需求需要的工具，即使这些工具在原有系统中存在。如此往复，这个系统恐怕是一个最大的垃圾站，不过这个垃圾站还能比较完好的运行。至于它的运行效率和维护成本必定很高。如果放弃这个系统。那势必是一个非常大的损失，于是这个项目因为最初选配的组建升级搞的变成了一个"毒瘤"无人赶碰触，我在吉林省长白科技就碰到一个这样的项目。
好了问题我们知道了，系统基础组建一旦选配就意味着以后的升级维护我们需要受到它们的牵连，如果组建的升级兼容性没的说，这篇文章也就是一篇杂谈。但是我们是无法确定兼容性的。问题又回到原点上了。系统组建各版本的兼容性导致开发成本难以估计。
其实已经有很多的这类问题以及解决方法我举几个：
1)使用老技术维护更新。
2)对需求进行变更来适应老系统环境。
3)重新开发一个新项目，将新项目部署在一起。
4)重构项目，对项目进行一次大的改版。
5)开发并维护自己的核心技术。
6)使用组建兼容的系统架构。
上面列出的6种方法除了最后一种我没有遇到之外，其他的都遇到过，甚至采用过。最后一种方法可以使我们解决组建依赖带来的危机。但是它也有它的弊病，那就是它要维护大量的组建。不过还好维护组建总比上面4个解决方法要好。
第5种方案，在大一点的公司中普遍使用，因为他们的项目经常面临这些问题，一个软件的生命周期往往很久，这段时间内技术更新不知道已经几个来回了。所以他们只会选择一些变化不大的，技术很固定的组建，比方说邮件组建，XML组建。这些组建基本一成不变，然后在搭配一个强大的开发语言他们开发自己的核心技术。任凭技术更新，这些公司只需要维护自己的核心技术就好了。
回到我们的例子中，如果这个web项目在先前没有采用这么多框架技术，在新需求来临时他们仅仅维护一下自己的核心技术就适应了新需求，同时核心技术又得到了提升。
何乐而不为呢？
构建核心技术不是一件简单的事情。但是至少我们需要有这方面的努力，就像每个程序员都曾有收集代码的时候。