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

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

 

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

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

评论

75 楼 gigix 2008-08-21  

gurudk 写道

方法如果不可避免的大了（为了维护逻辑上的完整性），那一定要将方法中的代码段进行分段，每段注释说明意图。

我就没见过一个例子，在这种情况下有充分理由不把注释变成新方法名字的
有写注释的工夫，抽取一个方法出来好不好？同样的信息为什么要写两次？
而且在我见过的所有代码中，凡是这种情况，无一例外的是考虑问题没有层次，眉毛胡子一把抓
说到底不是代码问题，而是解决问题的思路问题

74 楼 ccxw1983 2008-08-21  

有很长历史的项目都会出现这些代码质量问题的，像我们的drp项目，以前只有几个人，干了3年，里面堆砌的代码确实厉害，毕竟他们是php转过来的，能够实现已经是非常让他们骄傲的事情了，况且需求收集不成熟，经常变动。
我们项目的性能优化高手，他的重构能力应该不错，但是我刚做出来的一个东西，他去修改，添加新功能也只是力求加上自己的实现，根本没有把自己加的实现逻辑放到新的方法里面去，为什么？很好理解，这样能够在最少的时间内实现领导需要的东西，能够让自己利益最大化。我从他那还学到一点东西，当你接手旧代码添加新功能的时候，不要破坏以前的代码的逻辑，新功能通过补丁的路径执行得以实现。这样，即使对以前的代码不懂，也不会因为 你加了新功能就导致以前的东西出bug。

项目是否需要重构取决于价值，有限的时间，没有必要为次要因素而增加成败风险，况且现有的可能只是临时用用。

73 楼 gurudk 2008-08-21  

土匪一份子 写道

gigix 写道

laorer 写道

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

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

5行？  感觉很难想象。。。  呵呵   看来我还得重构、重构再重构

呵呵，看好了，是平均不到5行，不要被忽悠了，小方法是为了逻辑上的清晰，过分强调就是教条。

方法逻辑上一定要完整，就是很容易理解任何一个方法的意图，不能说为了了解一个方法的意图，要在多个小方法里翻来返去，这是不合理的。

方法如果不可避免的大了（为了维护逻辑上的完整性），那一定要将方法中的代码段进行分段，每段注释说明意图。
如果暂时没有看到有复用的迹象，不必重构去抽取成方法。

我不知道除了为了逻辑上的完整性和复用，还有什么理由分更多的小方法。

另外，如果代码行小，另一个可能的因素是在一行里体现多种意图，方法嵌套方法调用，布尔表达式嵌套方法调用等等，这种可理解性很差，我宁愿拆成几行，而让它得到更多的人更好的理解。

代码，可理解性永远是第一位。

72 楼 mimijidi 2008-08-21  

闪人之前挣扎一下,把你的想法提出来,有道理的话或许项目经理会接受

71 楼 lg_techie 2008-08-21  

<div class='quote_title'>liuqiang 写道</div>
<div class='quote_div'>
<div class='quote_title'>wcleye 写道</div>
<div class='quote_div'>
<div class='quote_title'>liuqiang 写道</div>
<div class='quote_div'>项目经理都不急，你急什么？ <br/>这个现象很普遍啊，不要太在意，建议继续撞钟，机会来了跳到开发规范点的公司</div>
<br/><br/>当一天和尚撞一天钟吗?如果我去了下个公司还是这样呢?然后继续跳吗?</div>
<p>很多事情是你一个人改变不了的，是你去适应公司，而不是公司适应你，下次找工作时最好调研一下该公司的各个方面，比如说印客网就不会有你说的那些情况，因为人家的人才梯队做的比较好。当然如果下次你还是那么随意找个工作的话，撞不撞钟只有听天由命了……</p>
<p> </p>
</div>
<p>对，个人的力量太渺小了。很多公司管理不规范，代码一团糟，很多情况下是没有办法的。</p>

70 楼 gigix 2008-08-21  

土匪一份子 写道

刚换了家公司2个月  现在做的项目是个四期的项目   听项目经理说这个系统参与人次量估计有80人左右。。。   这家公司以前没有什么规范   好象就是能把业务实现了就完事了。。。  刚接手时真是晕了  里面的代码五花八门  想重构  根本没门。。。  你重构的时间  老总不如直接让你做个新项目。。。   打算呆到年底就闪人。。。  再做下去我都怕自己会被外界淘汰。。

老总这么决定那你就这么做好了
你应该做的是让他明白，重构的成本是多少，能得到的收益是多少，做不做，由他决定
你的能力从提建议的过程中也会有所提高

69 楼 土匪一份子 2008-08-21  

刚换了家公司2个月  现在做的项目是个四期的项目   听项目经理说这个系统参与人次量估计有80人左右。。。   这家公司以前没有什么规范   好象就是能把业务实现了就完事了。。。  刚接手时真是晕了  里面的代码五花八门  想重构  根本没门。。。  你重构的时间  老总不如直接让你做个新项目。。。   打算呆到年底就闪人。。。  再做下去我都怕自己会被外界淘汰。。

68 楼 gigix 2008-08-21  

土匪一份子 写道

gigix 写道

laorer 写道

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

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

5行？  感觉很难想象。。。  呵呵   看来我还得重构、重构再重构

一个典型的分解细化的思考方法就会自然地引导出这样的代码。在任何一个层面上，你会把手上的问题细化成几个步骤（或者子问题），然后进入其中一个子问题，再分解细化。人的思维是很难同时思考超过7个元素的，换句话说一个问题很难被分解为超过7个子问题。所以直接的结果就是每个方法在5行左右的规模是很自然的事情。我经常看到一些长方法里用注释分成非常明显的5～7个大块，所以结论是显而易见的。

67 楼 土匪一份子 2008-08-21  

gigix 写道

laorer 写道

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

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

5行？  感觉很难想象。。。  呵呵   看来我还得重构、重构再重构

66 楼 levis2000 2008-08-20  

To lz,

你不一定需要有权利解决这个问题.
你可以研究如何解决并且向你的leader提出建议.

65 楼 fuwang 2008-08-20  

看了你的描述，估计你这个公司做项目没有考虑事务，其他类似的问题更多。
这种状况，说明你这个公司只重视商务不重视技术，公司领导层认为编程是体力劳动；不重视开发过程,做的项目漏洞百出，却总是希望靠忽悠来搞定；搞架构设计也比较菜，技术素养低,不知道真正能用的项目该怎么做。

64 楼 cgd123 2008-08-17  

楼主的情况已经很不错， 我team的同事好几个都是通信专业毕业的， 所写代码基本是一个“主函数”的样子， 使用面向对象的语言，但却没有任何一段面向对象的代码。在修改他们的代码时， 我经常挣扎在漫长的，可怕的代码从林之中，一点点增加测试，一点点提取类……

我尝试向同事讲解面向对象的好处，但得到的尽是“不感兴趣”，“面向对象的代码很难看”，“明明很简单的代码， 为什么要写成那么多的class， 实在不可理渝”的观点。我觉得勉强地要他们接受对于他们来说“那么新”的面向对象的观念，他们必然会十分抗拒。

同事有同事的生存方式，他们也会经常抱怨自己写的代码很难看， 很难进行改动了。但是他们却懒于寻找解决问题的方法。也不是他们不希望自己的编程生活好过一点，只是由于专业所限，见解所限，他们到目前还没有知道用面向对象的方式可以改善代码的质量， 当然也包括重构的方法。而我只是知道早一点而矣。

我的做法，在日常的工作里，坚持测试，重构，和良好地使用面向对象。做自己应尽的工作， 不要让代码的债务留给后人。我的想法很好，但是实践上却会出问题， 你的面向对象的代码，自然只有懂面向对象的人才好维护，我的那些不懂面向对象的同事还是不会看我的代码，他们阅读我的代码也会是一种痛苦。

这种处境比较尴尬，可谓进退唯谷。

63 楼 不是流氓 2008-08-17  

daquan198163 写道

看来面试的时候，很有必要提出观摩该公司代码

很希望他们有机会给我看他们的代码。。。
PS：高手和菜鸟的区别真的就在这里，高手：面试公司；菜鸟：被面

62 楼 lsk 2008-08-16  

gigix 写道

grandboy 写道

lsk 写道

gigix 写道

laorer 写道

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

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

平均方法不超过5行? 维护方便吗? 到处都是方法?

我觉得也不太好吧. 可能最后连方法名都不知道起什么好了吧? 什么事都是过如不及. 我感觉没有必要非得要这样. 只要在写程序时注意函数的功能单一性, 其实也就足够了.

其实这些东西呢，既然我说了那肯定我就是这么做的，而且我肯定想过这个事情，肯定是因为它有好处我才这么做而且还拿出来说。你要是有兴趣呢就去研究研究，是不是自己还有些东西没想明白。一上来就“我觉得不太好”云云，好吧你就这么觉得吧，你不去细想这个事情是你自己的损失，又不是我的损失。
http://lovdbyless.com/
这是个开源的项目。自己把rake stats跑一下看看

+----------------------+-------+-------+---------+---------+-----+-------+
| Name                 | Lines |   LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Controllers          |   811 |   617 |      13 |      69 |   5 |     6 |
| Helpers              |   278 |   224 |       0 |      27 |   0 |     6 |
| Models               |   640 |   351 |      10 |      49 |   4 |     5 |
| Libraries            |   154 |   108 |       2 |      14 |   7 |     5 |
| Integration tests    |    50 |    36 |       1 |       3 |   3 |    10 |
| Functional tests     |  1162 |   948 |      11 |      27 |   2 |    33 |
| Unit tests           |   609 |   402 |      12 |      20 |   1 |    18 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total                |  3704 |  2686 |      49 |     209 |   4 |    10 |
+----------------------+-------+-------+---------+---------+-----+-------+
  Code LOC: 1300     Test LOC: 1386     Code to Test Ratio: 1:1.1

没怎么认真重构的代码，刨掉测试的部分不看，平均每个方法5行多。

  

61 楼 gigix 2008-08-16  

grandboy 写道

lsk 写道

gigix 写道

laorer 写道

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

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

平均方法不超过5行? 维护方便吗? 到处都是方法?

我觉得也不太好吧. 可能最后连方法名都不知道起什么好了吧? 什么事都是过如不及. 我感觉没有必要非得要这样. 只要在写程序时注意函数的功能单一性, 其实也就足够了.

其实这些东西呢，既然我说了那肯定我就是这么做的，而且我肯定想过这个事情，肯定是因为它有好处我才这么做而且还拿出来说。你要是有兴趣呢就去研究研究，是不是自己还有些东西没想明白。一上来就“我觉得不太好”云云，好吧你就这么觉得吧，你不去细想这个事情是你自己的损失，又不是我的损失。
http://lovdbyless.com/
这是个开源的项目。自己把rake stats跑一下看看

+----------------------+-------+-------+---------+---------+-----+-------+
| Name                 | Lines |   LOC | Classes | Methods | M/C | LOC/M |
+----------------------+-------+-------+---------+---------+-----+-------+
| Controllers          |   811 |   617 |      13 |      69 |   5 |     6 |
| Helpers              |   278 |   224 |       0 |      27 |   0 |     6 |
| Models               |   640 |   351 |      10 |      49 |   4 |     5 |
| Libraries            |   154 |   108 |       2 |      14 |   7 |     5 |
| Integration tests    |    50 |    36 |       1 |       3 |   3 |    10 |
| Functional tests     |  1162 |   948 |      11 |      27 |   2 |    33 |
| Unit tests           |   609 |   402 |      12 |      20 |   1 |    18 |
+----------------------+-------+-------+---------+---------+-----+-------+
| Total                |  3704 |  2686 |      49 |     209 |   4 |    10 |
+----------------------+-------+-------+---------+---------+-----+-------+
  Code LOC: 1300     Test LOC: 1386     Code to Test Ratio: 1:1.1

没怎么认真重构的代码，刨掉测试的部分不看，平均每个方法5行多。

60 楼 coolnight 2008-08-16  

lz碰到的这种代码， 是代码生成器生成的， 显然不能随意的重构，除非代码维护
全部交给lz个人！

重构了之后下次需要更新又要用代码生成器重新生成大量东西怎么办？
要想改变这种模式， 你写个更牛更好使得代码生成器出来！

这个代码貌似是hibernate synchronizer 生成的， 事实上在用它的时候应该有很多
灵活的选项， 也有很多是常见的做法

不用spring， 代码的质量未必就差！

59 楼 grandboy 2008-08-15  

lsk 写道

gigix 写道

laorer 写道

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

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

平均方法不超过5行? 维护方便吗? 到处都是方法?

我觉得也不太好吧. 可能最后连方法名都不知道起什么好了吧? 什么事都是过如不及. 我感觉没有必要非得要这样. 只要在写程序时注意函数的功能单一性, 其实也就足够了.

58 楼 lsk 2008-08-15  

gigix 写道

laorer 写道

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

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

平均方法不超过5行? 维护方便吗? 到处都是方法?

57 楼 mingr6370 2008-08-14  

gigix 写道

mingr6370 写道

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

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

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

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

项目积累非常重要，同意你的观点

我之所以说LZ在目前阶段不要大面积修改代码，是从LZ目前的实际情况出发的，更多是想的人际工程

其实在项目生存，找到自己的位置是很重要，尤其是在很大的项目组里，这是生存的方法

56 楼 gigix 2008-08-14  

wcleye 写道

我之前这样问过他们:你们明明知道这样做不好,为什么不重构下呢? 他的回答彻底让我无语:任何一个系统需求变化到了一定程度就会重做一次,所以没这必要..

说得很对啊，除了“任何”两个字稍微有点极端。
要考虑成本与收益的。如果这个系统本来就没打算活过一年，你去为它两年后的可维护性做的任何工作都是浪费。