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

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

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

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

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

其实这些东西呢，既然我说了那肯定我就是这么做的，而且我肯定想过这个事情，肯定是因为它有好处我才这么做而且还拿出来说。你要是有兴趣呢就去研究研究，是不是自己还有些东西没想明白。一上来就“我觉得不太好”云云，好吧你就这么觉得吧，你不去细想这个事情是你自己的损失，又不是我的损失。
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行多。

  

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

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

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

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

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

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

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

To lz,

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

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

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

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