技术选型注意事项

最近一个朋友比较烦恼，原因是他们的系统换数据库了，如果仅仅是换个数据库倒是没啥大不了，撑死了改个数据库的驱动，改改连接字符串就得了，这都是分分钟的事。但是悲哀的是表结构也得到了较大的调整，“累觉不爱”来形容这为朋友对换数据库这件事的感受再恰当不过了。而笔者对这件事有几点体会。

错误发现的越早浪费的时间越少

其实如果后面Dao实现用的是Hibernate或者是JPA那么在开发阶段换数据库就不再是什么麻烦的事情，然而他们用的是Ibatis（或者是MyBatis？忘记哪个了who care~）所以在换数据库的时候实体得换、VO得换、界面得改、sql得改，累觉不爱啊！

以前对Hibernate有些偏见，感觉其也不像传说中的那么方便（官方宣扬将开发者从sql语句中解放出来），简单的sql是可以，但是遇到复杂的sql还是得写，而且对于Hibernate后期维护修改表的时候也得改代码，现在想想其实无论是jdbc还是Hibernate在维护阶段都需要改一定量的代码，问题在于哪个能更高效、准确的开发和维护代码。

Hibernate的优势是将错误放在编译之前（如果实体错了启动就会报错），错误出现的越早越好解决相应的浪费的时间越少。Ibatis中sql语句如果错误或者配置文件错误得等到服务器启动运行的时候才能发现，这就使得开发人员把大部分时间都浪费在了重启服务器上面了。

对开发者而言时间分两种：开发的时候时间即从0到1的时间，后期维护的时间即从1到1.5的时间，在后者无特别大的差别的情况下（不论用哪个框架修改表结构的需要对代码进行调整）开发时间越少框架优势越大。

没有思想性的重复的动作应该交给工具去做

如果框架本身不完美那么就给他配一个能令他完美的工具（比如eclipse当中无尽的插件），这样可以避免不必要的错误。人和计算机比起来计算机还是比较靠谱得，毕竟人的核心是靠激素，计算机的核心是二进制。

人类进步的标识之一就是社会分工越来越明确。很多人写代码的时候纯粹靠自己手写，比如在写spring配置事务的时候（那个表示类中方法的字符串）不知道有多少小白浪费了多少时间，其实这些东西应该让计算机来做，因为这不包含思想，纯粹的是体力劳动。很多人感觉自己能手写出一个jdbc连接字符串很厉害，的确你非常的（神）厉（经）害（病）。有工具为什么不用工具呢？想到中国的小孩能珠心算，能背诵圆周率，天哪，我已经无力吐槽了。

是否能为公司节约成本是鉴定框架优秀是否的唯一标准

如果一个框架可以让开发人员快速掌握，如果一个框架在使用的过程中避免开发者犯低级错误，如果一个框架在后期维护的时候可以快速修改原有的代码……。归根结底如果一个框架能为公司节约成本（人员成本，时间成本，开发成本，维护成本等等）那么这就是一个优秀的框架。

拿Hibernate与Ibatis来说同样的一个insert语句笔者坚信后者会给开发人员更多的机会犯错，同理拿JSF和SpringMVC来说笔者依然坚信后者会让开发人员在细节上浪费更多的时间。

别跟我说你是高手，犯低级错误的概率极低，试问多少公司能雇佣的起成群的高手。框架的选择一定要和公司利益挂钩一定要公司的成本。

别跟我扯效率，100个公司80个公司不需要特别考虑性能，彩票还没买就考虑500万怎么花是不是有点儿自欺欺人了。

 

每次类似这种框架比较的文章最后为了避免被无辜地吐槽总免不了说那么一两句留后路的话，例如：“框架没有好坏之分啊”，“任何技术都有其优缺点啦”，“没有最好的技术，只有最适合的技术啦”等等吧。这里换换说法，“对于高级开发人员框架没有好坏之分”，“对于高级开发人员任何技术都有其优缺点”，“对于高级开发人员没有最好的技术，只有最适合的技术”，aha这样就好多了。