[转载整理]一本java书的序言——开发历程思绪随笔

以下文字是一本java书的序言,我觉得写的不错,给大家各位使用.NET的朋友看看。文字我只做了简单整理,题目是我起的,版权属于原作者

JDK中很多类的用法我都烂熟于胸了,我已经能够使用Struts+Hibernate做出一个像样的论坛,公司很多人都称我是Hibernate高手,我做过很多上千万的大项目,我有多年的编程经验,我写的代码很多人看了都叫好,我曾经用过Delphi三年,写过很多小程序,什么远程监控呀.API劫持呀.木马呀,Windows的API里边藏着不少好东西呀,Delphi的控件也真是很丰富,我还研究了C#,用C#的WebForm做东西真是方便呀,对了,我目前正在研究很火的AJAX技术!可是……我是软件工程师吗?

1.重剑无锋.大巧不工

很多开发人员做了一段时间开发以后经常琢磨着怎么写出精彩.巧妙的程序来,所以在程序中使用了大量的技巧,并引以为自豪,还被同事夸奖:“真是高手呀,人家独辟蹊径用这种方法解决的问题,咱都看不懂,惭愧!”

可是这样的技巧真的很好吗?

我曾经接手过一段代码,这段代码据说是一位前辈高人留下的,这段代码经常出现Bug,多少人接手过,每次试图修改Bug时就会引来更多的Bug,被人称为一块硬石头.我读过了这段代码以后倒吸了一口凉气,这确实是高人写的代码,里边嵌套了5层循环,数据在界面和数据库之间加载来保存去很多次,并且用了巧妙的方式拦截了一个框架API,实现了用很复杂的代码才能实现的功能,我读了一上午,并且用了两天时间去改Bug,可谁知仍然是越改Bug越多.一气之下我把原来的代码都删掉了,然后用最普通但是比较笨的实现方式重新实现,从此以后这个功能很少出现Bug,接手的人也再没有抱怨过代码难懂.

这件事让我想起我上学时候的一件事.大四的时候我在一个小软件公司兼职,当时做的是一个呼叫中心系统.我用了很多控件的高级特性进行开发,开发速度之快让项目经理惊讶不已,一个劲地夸我是高手,所以当功能做得差不多的时候他就放我去北京求职了.晚上12点,我正在北京的一个旅馆中整理第二天去招聘会所需要的资料的时候,项目经理的电话打了过来:“兄弟,这边你做的程序有一个间歇性Bug,现在程序跑不起来了.我让另外一个兄弟帮着改一下你的程序,他说看了半天也不知道你是怎么实现的.”我当时心里听了特别自豪,于是乎在电话中很骄傲地给改我程序的那个兄弟讲我是怎么实现的.后来这个程序又出现了一些问题,都是只有我才能搞定,以至于当我毕业要离开那个城市的时候,项目经理苦着脸对我说:“兄弟,你走了以后谁来维护你的程序呀,当初真应该让你用简单一点的技术做呀.”当时听了他这句话我心里仍然是美滋滋的,可现在想起来却好难过.

在软件开发领域中,技巧的优点在于能独辟蹊径地解决一些问题,缺点是技巧并不为大众所熟知.若在程序中使用太多的技巧,可能会造成别人难以理解.一个技巧造就的一个局部的优点对整个系统而言是微不足道的,而一个别人看不懂.改不了的Bug则可能是致命的.在团队协作开发的情况下,开发时应该强调的一个重要方面是程序的易读性,在能够保证软件的性能指标且能够满足用户需求的情况下,必须让其他程序员容易读懂你的程序.

编程时不可滥用技巧,应该用自然的方式编程,简洁是一种美.不会解决问题的人尽管是“菜鸟”,但是这种人破坏力很小,而把简单的问题用复杂的方式解决的人是“半瓶子醋”,这种人破坏力极强,就像当年的我一样!只有能够把复杂问题用简洁而又直接的方式解决的人,才有望成为高手,所以现在我们更愿意看到写得朴实无华,没有什么闪亮词汇的代码.

2.框架与工具箱

经常听到有人说“我用某某框架做了一个东西”.“我开发了一个实现某某功能的框架”,那么到底什么是框架呢?

用《设计模式》一书中的定义来说就是:“框架(Framework)是构成一类特定软件可复用设计的一组相互协作的类……框架规定了你的应用程序的体系结构.它定义了整体结构,类和对象的分割,各部分的主要责任,类和对象怎么协作,以及控制流程.”框架实现了对具体实现细节的反向控制(IOC),实现者无需考虑框架层已经实现好的设计,只要按照框架的要求开发就可以了,然后把开发好的东西放到框架中就可以运行.

以JavacWeb开发而言,任何人都知道MVC的架构方式比传统的Model1方式更容易管理和维护,可是在实际开发中很多人又禁不住Model这种简便开发方式的诱惑.那么如何强迫自己使用MVC模式呢?当然是使用MVC的开发框架了,比如Struts.采用Struts后必须写一个JSP作为View,必须从Action继承来实现Control,必须从ActionForm继承来实现Model,框架约束住了开发人员那充满幻想的大脑,让我们以最佳的设计策略进行开发.

尽管框架中经常包含具体可用的子类或者工具包,但是使用框架的好处是可复用设计而非复用实现,使用框架时,我们无需考虑一些设计策略问题,因为我们已经无形中使用了框架设计好了的“最佳实践”.

与框架相对应的是工具箱(Toolkit).工具箱是预定义在类库中的类,它是一组相关的.可复用的.提供了通用功能类的集合.我们经常使用的ArrayList.FileOutputStream.CGLib.Dom4j等都是工具箱.这些工具箱不强迫我们采用某个特定的设计,它们只是提供了功能上的帮助,所以说工具箱的作用是实现复用(或者称代码复用).

在Java中有一种特殊的类叫做工具类(Utils),比如java.lang包中的Math.cCommons-cBeanUtils中的BeanUtils.这些类并没有封装任何状态在里边,也不允许调用者实例化它们,它们只是暴露了一些静态方法供其他类调用.这种类在其他支持函数库的语言里(比如C++.Delphi)被称为“伪类”,因为这些类没有封装任何东西,没有自己的状态,只是一堆函数的集合而已,原本是应该被坚决杜绝的东西,但是由于Java不支持函数库,所以才允许它们的存在.很多人都批评说这些类是面向过程的东西,不是真正的面向对象.但是不得不承认的是,Java这样的面向过程与面向对象的混合产品正是工业级开发所需要的,面向过程与面向对象并不冲突,否则那些真正的面向对象语言为什么一直还生活在学院派的温室里面呢?

3.再次框架

“再次框架”是我想使用的一个词汇,意思是在现有的框架基础上为了实现更多应用层次的设计复用而进行的框架设计.

很多人认为使用Struts.cSpring这样的框架开发就是基于框架开发了,就是最好的设计了,岂不知这些框架只是解决了大部分通用的问题,很多具体实现上的问题还需要进行框架设计,否则做出来的东西仍然是难以理解.难以复用.难以扩展的.很多人基于某些著名框架写出来的论坛.网站的源代码里实际上充斥着大量重复的代码.糟糕的设计,这些东西确实应该被好好地“再次框架”了.

4.企业框架

很多企业都建立了自己的一套或自用或开放的框架,比如SAP的Netweaver.用友的UAP.金蝶的BOS.浪潮的Loushang.上海普元的EOS等.开发这些框架是需要大量的资金和人力资源的投入的,但是带来的如下好处也是非常明显的.

(1)模块复用

在企业信息系统中很多模块是通用的,比如权限管理.组织架构管理,企业框架把这些模块抽取出来,这样具体业务系统的开发者就可以专心于具体业务功能的实现.

(2)提高产品开发效率

企业框架通常都提供了很多通用的工具箱或者辅助开发工具,业务系统的开发者使用这些工具箱或者辅助开发工具可以用最少的工作量在最短的时间内完成功能开发.试想如果做第1个功能和做第1000个功能耗时耗力一样多的话,那要这个框架有什么用呢?

(3)保证业务系统使用了最佳实践

企业框架常常采用了非常合理的设计,如何取得远程接口.在哪个地方进行数据校验.如何储存数据等一系列问题都已经被设计好了,开发者只要按照框架的要求进行设计,就可以保证开发出来的产品是设计合理的.

(4)对知识管理很重要
企业框架集中了公司所有软件项目的共同点,集中了对于公司最重要的知识的精华,随着框架的应用,框架本身也会随之升级优化.一个新加入企业的员工只要理解并掌握了这个框架,就可以很好地融入到团队中来,而离职的人员也已经把自己的知识留在了这个框架中.

(5)提高产品的一致性

此处的一致性包含两个方面,一个是产品功能的一致性,另一个是产品实现的一致性.功能的一致性主要指产品的界面.操作方式等的一致性,这保证了用户可以很容易地学习和使用系统的所有模块,实现的一致性主要就是规范产品的实现方式.

开发人员是聪明且富于想象力的,不同的开发人员写出来的程序具有个体差异性.这里举一个例子.

有一个界面的功能是:用户可以往这个界面中输入人员的姓名.年龄.性别.地址等信息,然后单击“保存”按钮保存到数据库中.

如果没有一个统一的框架,那么开发人员就可以随意发挥了:有人会在单击“保存”按钮的时候去逐个读取控件的值,然后通过JDBC执行一个Insert语句把数据保存到数据库中,有人会使用开源的数据绑定框架把控件与数据库的字段绑定起来,然后让数据绑定框架处理数据的保存,有人会先为人员建立一个hibernate配置文件,然后逐个读取控件的值填充到值对象中并调用session.save()方法把数据保存到数据库.

开发人员的这种随意发挥是项目非常大的一个风险,如何保证离职人员的代码能迅速地被接手人读懂是非常重要的一个问题,如果这么一个小小的功能就有这么多种实现方式的话,较大规模功能聚合中将面临的问题就更是可想而知了.

而使用特定的开发框架以后呢?对于上述界面功能而言,系统规定只要覆盖父类的initDataBind方法,并在方法里注册界面控件与数据库字段的绑定关系就可以了,其余的如何连接数据库.如何保存都由框架处理了.相信这样做的话接手的人员几乎不用看代码就能知道程序是如何实现的.

采用企业框架带来的一个主要变化就是开发人员可随意发挥的余地小了,必须在框架的约束下进行开发,无法在开发过程中体现自己的“高超本领”.从提高管理效率角度来说,软件企业应当欢迎这种变化,而另一方面,企业中具有挑战新技术激情的优秀开发人员尚可针对企业框架不断地实施改进和完善工作,为企业的技术路线注入新的活力.

你可能感兴趣的:(包括小经验,小技巧))