糟糕的代码设计真的让人很心烦..

刚进公司不到一个月, 现在正在进行一个项目开发,项目里使用 Hibernate2 + Struts1.2,正常情况下这是一个相当好的组

 

合,但是现在由于DAO层代码几乎全由MyExclipse 生成,不知是否由于MyExclipse 版本过低,生成的代码中大量使用了继

 

承,而且最主要的,项目管理人几乎没有进行重写的想法,他们的意思是:这些我们都用了很久,都很熟悉了;但是项目项目进度的

 

发展,这些问题也越来越突出,由于采用MyEclipse 自动生成的代码,在调用DAO对象前要先执行初始化,如:

try {
	_BaseRootDAO.initialize();
	dao = XXXDAO.getInstance();
} catch (HibernateException e) {
	e.printStackTrace();
}

 

然后才能调用,我想对它做个封装,可是对它这个初始化实在束手无测,现在我只能简单的把这些业务单独做个类来封闭,让它

 

不与WEB层混淆在一起,但是这样并不能彻底解决问题,我封闭的这些类中重复的代码实在太多,我也试过对这些代码进行重

 

构,可是由于现在项目也经进行到一半了,项目开发由多个人一同进行,我如果更改了原始代码结构,必然会引起别人代码不能

 

正常运行,可是每次自己读到这些代码,特别是自己还要参与到其中,真的很心烦.....

 

我应该如何做呢,难道企业里开发都这样吗? 大家能否给点建议..

评论

55 楼 wcleye 2008-08-14  

<div class='quote_title'>gigix 写道</div>
<div class='quote_div'>
<div class='quote_title'>mingr6370 写道</div>
<div class='quote_div'>以目前的情况项目推进到一半，而且开发都已经熟悉代码框架下，去修改代码是很费劲的事情，再说代码也不至于槽糕的要命 <br/><br/>另外LZ刚到新公司，就这么凸显能力，恐怕今后的路子不太平坦，如果要修改也是很隐晦的提出自己的想法，和项目的主要管理者商量，你觉得呢？ <br/><br/>如果让LZ很直接的说出来，我觉得会伤害一部分人（就算他说的很对，很有理），对不？</div>
<br/>你要知道，什么事情都不是一下子发生的 <br/>代码不是一下子变坏的 <br/>改进不是一下子改好的 <br/>能力不是一下子凸显的 <br/>这个项目不去一点点积累，那么下个项目还是会和这个项目一样</div>
<p> </p>
<p> mingr6370 说有道理,gigix 说得也不错,只不过你们考虑问题的角度不同,观点其实并不矛盾,mingr6370 说的会伤害一部分人,我考虑到了,所以到现在我没和他们提过,有改动的只是我自己的这块,当然为以后别人代码的改进也留有余地..</p>
<p>gigix 提到的代码不是一下子变好的,这点我现在真的体会到的,不是从书上看到的,也不是听到gigix提到我才这样说,代码是一点点积累才导致它变质的,以至于现在的同事自己都不愿再去碰以前写的东西,我之前这样问过他们:<span style='color: #ff0000;'>你们明明知道这样做不好,为什么不重构下呢? 他的回答彻底让我无语:任何一个系统需求变化到了一定程度就会重做一次</span>,所以没这必要..</p>
<p>基于这点,所以我现在只是打算改变自己的这一部分,让他们自己能看到这样改动后带来的好处,而不是用口去争辩......</p>
<p>我相信事实是最好的证明..</p>

54 楼 gigix 2008-08-14  

mingr6370 写道

以目前的情况项目推进到一半，而且开发都已经熟悉代码框架下，去修改代码是很费劲的事情，再说代码也不至于槽糕的要命

另外LZ刚到新公司，就这么凸显能力，恐怕今后的路子不太平坦，如果要修改也是很隐晦的提出自己的想法，和项目的主要管理者商量，你觉得呢？

如果让LZ很直接的说出来，我觉得会伤害一部分人（就算他说的很对，很有理），对不？

你要知道，什么事情都不是一下子发生的
代码不是一下子变坏的
改进不是一下子改好的
能力不是一下子凸显的
这个项目不去一点点积累，那么下个项目还是会和这个项目一样

53 楼 mingr6370 2008-08-14  

gigix 写道

mingr6370 写道

gigix 写道

mingr6370 写道

吃力不讨好的活还是忍了吧

下次项目技术准备时，提出自己的想法

这话说得很有意思
下次项目，凭什么别人就会听你的？
你不在真实的项目里尝试过，你就不会知道该怎么做才能让代码不变坏甚至变好
于是下次项目你还是没辙

为什么没辙？

只要提出的想法会改进代码，并且说的别人心服口服，为什么不能这么做呢？

如果你换做LZ，现在马上就修改代码吗？多想想LZ目前在公司的状况吧，人际工程比项目工程更难搞

一个问题就能把你噎死
你说这能改进代码，证据呢？
于是，继续等下个项目吧。
既然你也知道人际工程更难搞
项目进行中你还有机会做实事你不建议他去做，却叫他等到下次项目准备这种纯靠沟通技巧的时候去提建议
你这不是往坑里推人么？

怎么叫往坑里推人呢？此话有待商榷

以目前的情况项目推进到一半，而且开发都已经熟悉代码框架下，去修改代码是很费劲的事情，再说代码也不至于槽糕的要命

另外LZ刚到新公司，就这么凸显能力，恐怕今后的路子不太平坦，如果要修改也是很隐晦的提出自己的想法，和项目的主要管理者商量，你觉得呢？

如果让LZ很直接的说出来，我觉得会伤害一部分人（就算他说的很对，很有理），对不？

52 楼 wcleye 2008-08-14  

<div class='quote_title'>mingr6370 写道</div>
<div class='quote_div'>
<div class='quote_title'>gigix 写道</div>
<div class='quote_div'>
<div class='quote_title'>mingr6370 写道</div>
<div class='quote_div'>吃力不讨好的活还是忍了吧 <br/><br/>下次项目技术准备时，提出自己的想法</div>
<br/>这话说得很有意思 <br/>下次项目，凭什么别人就会听你的？ <br/>你不在真实的项目里尝试过，你就不会知道该怎么做才能让代码不变坏甚至变好 <br/>于是下次项目你还是没辙</div>
<br/><br/>为什么没辙？ <br/><br/>只要提出的想法会改进代码，并且说的别人心服口服，为什么不能这么做呢？ <br/><br/>如果你换做LZ，现在马上就修改代码吗？多想想LZ目前在公司的状况吧，人际工程比项目工程更难搞</div>
<p> </p>
<p> 沟通不能完全解决问题,接触任何新东西之前,大家的想法是先看到改变能给我带来什么,是看到不是听到也不是别的...</p>
<p>我觉得一切得用事实说话..</p>
<p> </p>
<p> </p>

51 楼 gigix 2008-08-14  

mingr6370 写道

gigix 写道

mingr6370 写道

吃力不讨好的活还是忍了吧

下次项目技术准备时，提出自己的想法

这话说得很有意思
下次项目，凭什么别人就会听你的？
你不在真实的项目里尝试过，你就不会知道该怎么做才能让代码不变坏甚至变好
于是下次项目你还是没辙

为什么没辙？

只要提出的想法会改进代码，并且说的别人心服口服，为什么不能这么做呢？

如果你换做LZ，现在马上就修改代码吗？多想想LZ目前在公司的状况吧，人际工程比项目工程更难搞

一个问题就能把你噎死
你说这能改进代码，证据呢？
于是，继续等下个项目吧。
既然你也知道人际工程更难搞
项目进行中你还有机会做实事你不建议他去做，却叫他等到下次项目准备这种纯靠沟通技巧的时候去提建议
你这不是往坑里推人么？

50 楼 mingr6370 2008-08-14  

gigix 写道

mingr6370 写道

吃力不讨好的活还是忍了吧

下次项目技术准备时，提出自己的想法

这话说得很有意思
下次项目，凭什么别人就会听你的？
你不在真实的项目里尝试过，你就不会知道该怎么做才能让代码不变坏甚至变好
于是下次项目你还是没辙

为什么没辙？

只要提出的想法会改进代码，并且说的别人心服口服，为什么不能这么做呢？

如果你换做LZ，现在马上就修改代码吗？多想想LZ目前在公司的状况吧，人际工程比项目工程更难搞

49 楼 rtdb 2008-08-14  

习惯问题，只能慢慢改进的。
就算是你运气好，有机会完全重写，
过一两年回头看，还是会发现很多垃圾的。

最近这十几年，是软件开发思想大发展的年代，
从面向过程，到面向对象，
到设计模式，再到面向接口， 直到敏捷的TDD和重构，

以致每次我回头看若干年以前自己的代码时，
在不忍目睹的同时，也骄傲自己的进步。

48 楼 zhanyingle_1981 2008-08-14  

有想法应该要沟通,项目进行中想做大规模的重构,最好是要取得领导的支持,所有人达成共识才行,不然就乱套了

47 楼 wcleye 2008-08-14  

<div class='quote_title'>neo_q 写道</div>
<div class='quote_div'>其实初步看来你的这个问题是可以解决的。如果你可以确定你得到dao的方式是以factory的形式来得而非直接new，那么你在这里使用proxy，返回一个proxy的instance，在proxy里面判断是否已经init过了，没有做过就做init，如果已经做了则直接调用target对象的方法。 <br/>这样既可以满足你每次不调用root class的方法也可以不让你的同事的代码受到影响。</div>
<p><br/><br/>我现在作法: </p>
<pre name='code' class='java'>public Abstractxxxx(Class clazz){
     try {
_BaseRootDAO.initialize();
Class[] type = new Class[]{};
Class[] arge = new Class[]{};
Method method = clazz.getMethod("getInstance", type);
dao = method.invoke(null, arge);
      } catch (Exception e) {
e.printStackTrace();
     }
}</pre>
<p>业务类继承它,在构造方法中执行:</p>
<pre name='code' class='java'>public XXXService(){
super(XXXDAO.class);
dao = (XXXDAO)getDao();
}</pre>
<p> 这样来得到对象实例..</p>
<p> </p>

46 楼 weicanhuang 2008-08-14  

只要不出问题，重构还是算了吧，中途改这个是大忌。

45 楼 happy31 2008-08-14  

leonhe_cn 写道

公司规模太小了吧，我上次到新公司报道，一看项目和楼主一样连spring都没用，马上走人了呵呵

。。。受不了。。。

44 楼 bulargy 2008-08-14  

如果没有老大肯推动重构这件事情，奉劝兄台还是独善其身的好。
这些都是吃力不讨好的事情~~~

43 楼 laorer 2008-08-14  

gigix 写道

我目前的项目，产品代码平均每个方法不到5行

五行？我还有好长的路要走，至少暂达不到

42 楼 gigix 2008-08-14  

mingr6370 写道

吃力不讨好的活还是忍了吧

下次项目技术准备时，提出自己的想法

这话说得很有意思
下次项目，凭什么别人就会听你的？
你不在真实的项目里尝试过，你就不会知道该怎么做才能让代码不变坏甚至变好
于是下次项目你还是没辙

41 楼 mingr6370 2008-08-14  

吃力不讨好的活还是忍了吧

下次项目技术准备时，提出自己的想法

40 楼 gigix 2008-08-13  

laorer 写道

这个应该有点难度吧...
那要写多少个小方法，而且有些代码内聚度比较高的，为什么要拆成多个方法

我目前的项目，产品代码平均每个方法不到5行

39 楼 Allen 2008-08-13  

其实“陈旧”还是要比“不统一”来得要好一些。

各自为战的混乱远比武器落后要可怕……

38 楼 neo_q 2008-08-13  

其实初步看来你的这个问题是可以解决的。如果你可以确定你得到dao的方式是以factory的形式来得而非直接new，那么你在这里使用proxy，返回一个proxy的instance，在proxy里面判断是否已经init过了，没有做过就做init，如果已经做了则直接调用target对象的方法。
这样既可以满足你每次不调用root class的方法也可以不让你的同事的代码受到影响。

37 楼 laorer 2008-08-13  

[quote="gigix可能是我想太多了吧
代码要变好，不是靠“大的代码变更”来达到的
我的标准是，三行以上的代码不应该重复
（当然还有别的标准，例如一个方法不应该超过10行）
发现这样一个小小的不好，你就把它扫干净，于是代码就变好了一点点
一点点积累起来，整个代码库就会变好

（当然还有别的标准，例如一个方法不应该超过10行）
这个应该有点难度吧...
那要写多少个小方法，而且有些代码内聚度比较高的，为什么要拆成多个方法

36 楼 gigix 2008-08-13  

林杰杰 写道

gigix 写道

林杰杰 写道

我估计这代码不是开发人员想写成这样的。
而是开始的时候需要很简单，而他写的代码对于那个需求来说很适合。
只是后来的需求一点点变化，每一次的变化都不足以引起大的代码变更，只是一点点积累起来，成了这模样了。

既然你知道代码质量不是一下子变坏的
为什么又认为它会一下子变好？

貌似我没有说过代码会一下子变好的话。。。

可能是我想太多了吧
代码要变好，不是靠“大的代码变更”来达到的
我的标准是，三行以上的代码不应该重复
（当然还有别的标准，例如一个方法不应该超过10行）
发现这样一个小小的不好，你就把它扫干净，于是代码就变好了一点点
一点点积累起来，整个代码库就会变好