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

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

对，个人的力量太渺小了。很多公司管理不规范，代码一团糟，很多情况下是没有办法的。

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

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

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

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

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

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

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

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

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

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

<div class="quote_title">lg_techie 写道</div><div class="quote_div"><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>很多事情是你一个人改变不了的，是你去适应公司，而不是公司适应你，下次找工作时最好调研一下该公司的各个方面，比如说印客网就不会有你说的那些情况，因为人家的人才梯队做的比较好。当然如果下次你还是那么随意找个工作的话，撞不撞钟只有听天由命了&hellip;&hellip;</p>
<p>&nbsp;</p>
</div>
<p>对，个人的力量太渺小了。很多公司管理不规范，代码一团糟，很多情况下是没有办法的。</p></div><br/>

很多公司当领导的不懂技术，也缺乏胸怀和眼光，急功近利，固执己见，有时凭借手中的权利，去执行只有他自己认为正确的事，突然有一天想到一种方法，兴冲冲的去实践，却不知这是别人早就知道的方法，而他只知其中一二就自我满足，鼠目寸光，这就是中国软件的悲哀。有一天，你们当领导了，一定不要这样，否则，遭殃的是更多的人。

用许三多的话，没有意义。详细解释一下：

1） 首先不可能是很长的方法，比如超过50行，这只是经验数字，任何时候都有例外，但不影响讨论基本原则。
2） 如果抽取出来，不能复用，我觉得没有任何意义，还得费挺大劲想方法名，随便对一个方法命名是可耻的。
3） 一屏幕我都能看到，分段注释又可以帮助理解思路，注释是自然语言，简短的自然语言比一个再好的方法名都好。
4） 如果有复用，我还是赞成重构成方法。
5） 我感觉你可能考虑问题太有层次了，我的哲学是中庸而实用，可理解性好就行。

场景不同，习惯不同，看法也就不同，正常，呵呵！

能够满足“开闭原则”，水平已经很高了，值得学习！

已经成熟的产品，重构代价太大，我觉得没必要重构，推到重来更不值得。我们公司也有这样的产品，每次都有重做的冲动，每次都舍不得。 已经正常履行功能，稳定运行的代码，就不要碰了，不要为了重构而重构。