java运维工程师

入题：使用 SSH 个人感觉 最大的隐患就是 升级维护。包括SSH之外的其他组建比方说Log4j,Dom4j等，到不是说这些组建不支持扩展维护困难。回到议题中，新的需求到来时SSH组建已经升级，新版本的组建中提供了大量实用的工具和技术策略让快速的解决新需求带来的开发时间。但是由于维护的项目使用的是老的技术设计，所以不能冒昧的替换原有的SSH框架。因为无法确定新组建在原有框架上运行的稳定性和兼容性。为此需要做大量的测试来确定。这是在最初系统设计时没有考虑的。其实已经有很多的这类问题以及解决方法我举几个：1)使用老技术维护更新。2)对需求进行变更来适应老系统环境。3)重新开发一个新项目，将新项目部署在一起。4)重构项目，对项目进行一次大的改版。5)开发并维护自己的核心技术。6)使用组建兼容的系统架构。上面列出的6种方法除了最后一种没有遇到之外，其都遇到过，甚至采用过。最后一种方法可以使解决组建依赖带来的危机。但是也有弊病，那就是要维护大量的组建。不过还好维护组建总比上面4个解决方法要好。第5种方案，在大一点的公司中普遍使用，因为项目经常面临这些问题，一个软件的生命周期往往很久，这段时间内技术更新不知道已经几个来回了。所以只会选择一些变化不大的，技术很固定的组建，比方说邮件组建，XML组建。这些组建基本一成不变，然后在搭配一个强大的开发语言开发自己的核心技术。任凭技术更新，这些公司只需要维护自己的核心技术就好了。回到例子中，如果这个web项目在先前没有采用这么多框架技术，在新需求来临时仅仅维护一下自己的核心技术就适应了新需求，同时核心技术又得到了提升。构建核心技术不是一件简单的事情。但是至少需要有这方面的努力，就像每个程序员都曾有收集代码的时候。