感觉重构成了笑话
从开始编程到现在，呆过的公司，呆过的每个项目组，几十上百行的函数都比比皆是。以此为美的还不在少数，认为这是“紧凑”；变量太多也不认为是问题，统统提到函数开头就行了，认为这样“更易读”；变量命名也很简短，一个字母的，两个字母的大行其道，也不认为是问题，可能认为这样并不影响阅读，相反还使得代码更简短。代码嵌套太深也不认为是问题，反对分拆函数，认为不是公用的代码就不用分拆，是否分拆与函数长度基本没有关系。
我已经不相信国内有严格践行重构的公司了，觉得多数公司的代码都是这样写的。
尽管阅读了《重构》一书，并自认为初窥门径，但仍无法说服同事们，除非他们也读过并认同。在认为重构就是伤筋动骨，是每隔一段时间就进行一次的大修的同学面前，直接向他们灌输书上的做法确实不行。我说变量应该紧贴逻辑块，就近原则，全部提到顶部不容易阅读，且相当于全局变量，应该限制作用域；但他们认为放在顶部就是更容易阅读。在怎么样更容易阅读方面起了争执，而且没有办法解释清楚。因为以我目前的功力和表达能力，我确实没有办法解释盐为什么是咸的，醋为什么是酸的。 17 楼 ygyz03 16 小时前 white_crucifix 写道我和楼主一样也是一个重构爱好者，不过我其实深深的理解楼主说的那些同事。因为重构这件事情，必然是以兴趣为驱动的，当一个人完全对这个系统没兴趣的时候，他是不会打从心底想去做优化重构的。你愿意重构的系统必然是你喜欢的，想要做的更好，写出完美优雅的代码，这其实是出于一种兴趣驱动，你重构时充满着激情。有些人不喜欢大动干戈，因为本身对系统也不报太多的激情，需求频繁的修改，前期都无所谓的功能后期都要赶工做出来，界面粗糙，重构完领导也不一定让你提交，等等等等。总而言之因为这个系统不是你的，没把它当作自己的心血，以后提到这个系统的时候也不会兴奋，“哦，以前我做个这个，大概是这个样子的”。我们看到很多开源项目，代码写得很好，人家不一定是大牛，但代码都是经过精心雕琢的，因为这是属于某人或某团队自己的东西，有激情。所以，什么样的系统值得你去重构，什么样的系统不值得你花时间去重构，了解清楚了自己就不怎么会生气了吧~
说出了我的心声，确实得有兴趣驱动才行。我自己有一些代码洁癖，看到那些乱七八糟的代码，唉...我这边连最基本的代码缩进都不讲究，废弃的代码直接注释掉，程序里都是System.out.println("aaa");之类的调试语句。每一个业务都是一坨代码的堆积，if else能嵌套10多层，而他们还以自己用一千多行代码实现了一个复杂的业务无比自豪。当你维护这些代码，基本上就是在滚鼠标的滚轮，都是一些老员工，说都没法说，沉闷！ 18 楼 ygyz03 16 小时前 zqb666kkk 写道重构 代表这 设计初始阶段 的失败 重构只是为了用一个错误去弥补另外一个错误，如果项目很烂 要么 废弃重做 要么 ，就是一烂再烂 看你如何选择
很多公司以为重构是在做一件有意义的事情 ，我只想说 我去年买了个表
前两个月，接了一个项目，交给我维护，烂的都没法看，索性自己重写了一个！烂东西越改越烂，注重重构的公司至始至终必定对项目有严格的要求，人家做重构是顺理成章的。不像大多数公司，前期着急赶进度，又没有统一的编码规范，到最后了，才想起来重构...那不就是那些2B项目经理挂在嘴边ZB用的么！
