如果代码没有 bug、也没有性能问题，是否还会为了其他目标来优化重构？

[d119]

如题，如果代码没有 bug ，也没有性能问题，是否为了追求代码的优雅、格式、项目结构的优化而去调整重构代码呢？

[frank1256]

会，总有人不喜欢屎的味道（闲下来的时候）

[zwdsix]

我就说一句，程序员其实往往不懂自己说的“优雅”是什么意思。甚至不知道“重构”的定义。

[lmshl]

我做过，算是提升可读性吧。
把整个系统的异步模型从 Future 迁移到纯函数的 IO Monad ，重构过程中发现了一堆小 Bug ，只是运气好没走到这个分支。以及重构完了还发现访问量高于半年前但 CPU 降到原来 1/10 的样子，也是重构的小惊喜。

[kaz10025]

小项目调整无所谓 屎山你改的动？

[panlatent]

自己的会。公司的以前也许会，现在不会。

[s524256521]

个人猜测，优化重构的根本原因是客户需求在不断升级，代码本身有没有问题不是关键，所以很多时候为了增强竞争力，会把没有 bug 和性能问题的代码重构上云，或者优化算法来降低成本。

[wr410]

不会，这是一个大工程，牵涉人员众多，不是你自己的东西想改就能改的

[god7d]

不会，能跑就行，直到有一天实在是无法维护了才会考虑重构

[darkengine]

会为了其他目标（可读性，可维护性）局部优化代码。至于大范围重构，最好要有充分的理由和评估。

[xianyv]

自己写的代码还有点动力,别人交到自己手上的没啥兴趣给重构

[god7d]

@s524256521 是的，一般代码有 bug 或者是写的不优雅很少会成为进行重构的动力，一般都是项目的不断迭代更新，原先的架构无法再加入新的功能或适应现有的业务模式，才会被迫进行重构。一般有经验的架构师会早早的预测到这类情况的到来，所在在项目之初就会在架构上做出预先设计。很多公司的软件 leader ，会有第一版“先完成再说，等后面用不了了大不了重构嘛”的想法，他们的重构频率会相对较快，但是这种一种错误想法，本质上也是架构师经验不足的表现。因为频繁重构严重加大开发、测试人员的工作量，也使得软件的稳定性下降，同时也可能会增加客户的学习成本（如果重构引起客户察觉的话）。

[c8c]

看情况吧。
举例：
如果扩展性不够好，而业务量增加，需要扩展，就需要重构啊。
如果 Ops 很重，也会重构，简单结构，减少 Ops 。

[d119]

我初入门的时候，带我的一个前辈，就花了很多时间在重构上，那时候还不流行微服务这种模式，是面向对象开发模式的的中大型项目，我很清楚的记得，他每隔一段时间，（并不是一定闲下来的时候），他就重构（当然在那种项目里面，重构是要花很多时间的，因为重构是逐渐逐渐的，不可能一下就优化重构到很好），他重构到了什么地步呢，我也清除记得：一个不会写代码的项目经理，经常站在他旁边看，而且说，看他的代码跟看书一样，很明白这段代码是什么作用和意义。

[garlics]

感觉大规模的重构最主要的目的还是空降的领导想控制代码

[ericgui]

当然 TMD 要重构了，你都不知道，一个 react class component ， 在我老东家， 能有 1300 行，我以为这就够屎了，新东家 1800 行，怎么样？

不是没有 bug ，而是你没测出来罢了

[janus77]

kpi

[westoy]

没 BUG 和性能问题的重构一下

可能就有了.........

[lujiaosama]

不是技术驱动型的公司有哪个天天给你重构，能跑起来的代码就算再烂也是经过生产环境检验的。重构还得把之前跑过的流程全部来一遍，哪里只是改改代码的事情。

[infun]

会的，我之前对接的开发团队，为了可读性和扩展会做比较多的重构
和他们合作比较愉快

[alen0206]

自己不接手的一般不改