• 2004-01-15

    惯性思维

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/72034.html

    有没有压力的感觉果然不一样。

    经过近乎疯狂的编码,项目顺利拿出手,一根紧绷了近一个月的弦一下子松了下来。这两天感觉整个人特别懒散,什么都不想干,就连blog都懒得写了。

    在我们传统的开发方式中,比如用C/C++,我们会把自己应用的所有东西放到自己应用的目录下,比如bin下放可执行文件,conf下放配置。通常顶层目录则是由我们任意指定。
    对于J2EE部署,我的认识基本上是,把所有class和部署描述符打成一个包,可能是EAR、可能是WAR,然后部署到应用服务器上。一般部署的结果就是放到了应用服务器的目录上。
    这是我脑子里一直难以解开的一个结,我们无法按照传统的方式部署我们的应用。

    我们的新系统中,一个同事创造性的解决了这个问题,使我们按照传统的方式部署我们的应用。具体做法很简单:部署时,只把描述符部署到应用服务器上。而我们应用的class文件打成一个JAR文件,把它配置到应用服务器的classpath中。至于可能用到JAR文件,我们也不像原来一样打入应用的包中,而是单独部署,放到我们应用的lib下,然后也是配置到应用服务器的classpath中。至于配置,程序会读一个环境变量确定配置文件的位置,于是配置文件的位置也成了可配的。

    由此,我们的应用彻底与应用服务器分开,我们可以按照传统的方式组织自己的应用。

    或许从表面上并不能看出这种做法的好处,如果你能够亲身经历一次打包发布的漫长煎熬,现在这种只要自己手工就可以简单完成打包,发布变成了一个FTP的过程,估计就能体会我们用这种方法的幸福。另外,我们的实施人员更习惯于原本的那种部署方式,而并非J2EE那种一切尽在应用服务器的方式。

    最初接触到这种做法,我惊讶的嘴都合不上了,太精妙了。回过头来想想,其实这只是一个惯性思维的问题,太过于习惯现有的东西,有些很好的解决办法其实只要简单的转化一下思路就OK了。

    突然想起前不久调系统的一个bug,费了好大的劲,最终的bug是出在一个已经用了几个月的类上。这是一个读XML配置文件的类,现在的系统用了多个配置文件,一读就错。最终发现一个成员被写成了静态的,所以第二加载的时候会覆盖掉第一个,之所以以前没错,因为以前只有一个配置文件。

    调这个bug费了好大的劲并不是因为这个bug如何之难以找到,关键是因为我根本没有想到这个类会错,因为它已经是我多次维护过,并且稳定运行了好长一段时间了。这还是一个惯性思维的问题。

    偶尔跳出三界外,一片海阔天空。

    分享到:

    历史上的今天:

    引用地址: