合理的使用技术

盲目的为项目选择新技术框架，对项目是非常危险的。

 

根据项目的实际需要来选择适合项目的技术框架，而不是仅仅为了追逐最新的技术而使用升级。

 

做Java开发，尤其是web应用的开发，技术的更新是十分频繁的。这个时候，谨慎清醒的选择项目的技术框架，不要被新的技术框架的种种华丽外衣所蒙蔽。

 

更多的时候，选择新技术，或者升级现有的技术框架，是为了适应用户的使用平台软件的变化。

 

为什么把dwr2升级到dwr3？最重要的原因是，dwr2生成的javascript代码，与IE8不兼容，这是必须要做的升级，况且升级的代价并不大，对系统代码的影响是非常小的，可以接受。现在大部分的系统用户都是用IE8浏览器了。总不能要求用户去使用低版本的浏览器吧（如果是升级，用户可能还会接受），或者在页面中强加一段标签，强迫用户开启IE8的IE7浏览器兼容模式吧。

 

为什么要升级datepicker到最新的版本，因为在IE8下版本，在进行日期选择处理时，出现了bug，解决的版本是升级到IE9。但是用户拒绝升级呢？那就只能我们想办法了，况且只是更换js文件而已。

 

但是系统项目首要的是稳定。用户不会关心你后台的技术是如何牛X，代码实现是如何有没，平台框架是多么的先进。他们关心的只是，软件在使用的时候，不要太麻烦，尽量简单。毕竟用户使用软件，是为了减轻工作量，而不是给自己增加麻烦。最重要的时候，不要在正使用的时候，出错崩溃！那么我刚才的工作都白瞎了！那样用户肯定会抓狂的！

 

必要的时候再进行软件技术框架的升级，或者新技术的应用。如果既能毫无障碍的平滑升级，提升软件的健壮性与性能，又能减少软件开发的工作量，那是最完美的了。幸好现在很多的软件技术框架，没有必要的话，升级的代价都不大，完全可以接受。

 

那么新技术的使用，比起技术框架的版本升级来说，就要慎之又慎了。毕竟使用了新的技术框架，或多或少都会影响软件项目的现有代码，开发流程和开发习惯，还有开发人员的学习过程。

 

比如现在的项目使用JDBC很稳定，性能也很好，没有出现任何问题，仅仅是为了追逐当前最流行的ssh框架，就要使用hibernate作为项目的持久层框架，有必要么？如果项目组的成员已经熟练使用了SQL进行开发，并且也有相应的工具简化JDBC开发，这还有必要么？

 

一旦更换hibernate，首先系统的开发模式就要变换了，无论使用注解，还是xml文档配置，意味着开发人员习惯的开发流程发生了巨大的变化。对于小型的项目来说，得不偿失，对于大型项目来说，代码更迭带来的工作量的增加也是不爽的。

 

使用新技术，一定要明白，它的引入，对项目来说是弊大于利，还是利大于弊。如果有必要，最好做一原型系统验证一下，最好业务功能来自于要升级的系统，并且开发习惯的改变不要太大。

 

 

不要开发你能下载到的东西。

 

这算是另一种极端了，往往很多技术牛人不相信别人的技术框架，疑虑重重，坚持要自己来开发才放心。

 

有的大型软件项目使用已有的开源技术框架，确实是无法满足要求，这是没办法的事。但是如果已有的技术框架完全能满足你的要求呢？

 

更重要的是，新开发的代码，需要进行测试，验证，并且谁能保证一定比你能下载的东西强呢？如无必要，还是关心你要实现的业务需求。

 

记得有一个项目，使用了Struts2框架，结果与系统中使用的一套富文本编辑器发生的冲突，导致编辑器上传文件发生系统错误。其实只要简单的研究一下Struts2的配置，就能解决这个冲突了。结果某牛人，以为为依据，就认为struts2不能再使用了，幸亏他还没有牛到开发出一个mvc框架来，但是却要大动干戈的重写struts2中相关的功能代码。最后项目延期了，他的改动也极不稳定，结果就是普通的struts2上传和富文本编辑器都可以实现上传文件了，但是经常出现莫名的问题，不了了之。