信手拈来 妙手偶得

本文系原创文章,转载请注明出处(jungleosng.yculblog.com)

技术含量一词,自<<天下无贼>>后就开始流行,变成了很多程序员在闲暇时评论项目的标准用语.但我觉得部分人误解了技术含量这一词,有时候甚至本末倒置了.

首先让我们来澄清一下那些不是属于技术含量:
1.API不是技术含量.这样说原因有三,一.API是从手册上,网络上查来的东西;二.API不是难以掌握的,项目中纯粹的技术问题反而最好解决和掌握;三.考虑到实现的通用性和普及性,API会逐渐趋同,这样门槛会越来越低.总而言之,记问之学不足为人师.

2.名词概念不算技术含量.前几年EJB三个字会让人肃然起敬,去年则人人喊打,最后POJO的流行让大家都返璞归真了.概念并非不重要,但它应该是交流和讨论时用的缩略语,而不应该拿来当作吓唬人的名词,实话说笔者对这种人也很厌恶.很多概念和技术都有其适用的场合,并非放之四海而皆准,许多项目为了贪大求全,盲目的上了一些技术,结果只用了一小部分,其实还有更简便的方案存在.这种情况下技术名词概念实在不能算技术含量.

3.冗长的代码更不是技术含量.好的代码不在于其长短,它应该是"完美得无法进行增删操作"的.过分冗长的代码一把都有重复代码,未进行完全抽象,内聚度不高等典型代码臭味,属于重构的专政对象,不能想象这会被当作技术含量,最多当做辛苦程度的评价指标.

4.投机取巧或难为而为之的代码不是技术含量,这样的代码多为复杂多变的需求所产生,本身就存在耦合严重,难以理解修改,不适应变化等问题,后期维护更是一场恶梦.这是把需求分析和领域建模未充分解决的问题转移到了编码阶段,从一开始就充满着隐患.具体表现了冗长复杂的SQL语句,奇怪的作用域很广的变量,Session中的全局变量,违规的跨层调用等.这些都是应该完全避免的.

我觉得,真正有技术含量的项目应该具备以下特征:
1.复杂度最小,简单而易于理解.
2.易于维护,不会是维护程序员的恶梦.
3.松耦合.
4.可扩展,不会因为需求在可预计的范围内变化就要动大手术.
5.重用度高,不需要每个项目都制造一批新零件.
6.系统很好的利用了底层工具类.
7.精简性,系统没有多余的部分.
8.良好的层次,各层各司其责,没有跨层调用.
9.标准技术:API趋向于标准的,常用的方法.

但是,不仅仅是这样就可以了,如果程序员不能真正投入进去,恰当的发挥自己,再符合以上标准的项目都是别人的世界.一个优秀的程序员应该充分发挥自己的创造性和追求完美的精神,力争贴近这些目标.

所以,我觉得,如果一个维护性项目交付到程序员手中时,他应该先努力去发现其优点,整体了解后再向以上标准进行靠拢;如果是一个开发性的项目,那么程序员一开始就要想到以以上标准来指导开发.这才是程序正道.与正道相反的意见,规定,制约都是邪门歪道,无论有什么理由,都是应当唾弃的.

我的结论就是:技术含量就是指项目中正道与邪门歪道的比例.