在你所服务的公司里，你的直接上级能够理解和支持重构的意义吗？

@CHYK 至于千年虫，我感觉更像是重构时 **意外** 解决的，这我有过不少经历，事后的感觉就是 “欸？这么说我原本的代码是有 bug 的？”。
可能某些时候算是代码健壮性的一部分，健壮性也确实是重构的目的之一，但不是靠重构本身完成的，而是重构期间形成的可读性。有人说：没 bug 的代码只有非常复杂以至于看不出 bug 和非常简单以至于看出没 bug 两种。重构的一个目标就是尽可能将前一种变成后一种。

在前司，本上级的团队基本没有做过重构，新的活架构做好一点就行了，精力主要华仔逐步引入更合理的架构设计风格和工具、框架行。
没有空闲的资源去重构老项目。

理解并支持，当然，团队小，项目也小

我想重构，老大想重写。

不能。

不能

能，因为上级是技术出身

@no1xsyzy 其实掌握重构的程序员，从来不会把问题积累到需要专门拿出大段时间来做所谓的“重构”，脑子里设置好了各种触发器，一遇到 bad smell 很容易就识别出来，并警觉起来分析代码需要不需要整理。而另外的程序员即使专门花了大块时间做所谓的“重构”，也依然会留下很多糟糕的代码。我觉得这种事情很难存在处于中间状态的人，要么从来不留需要清理的代码，要么即使“重构”了他也必然清理不干净。有句话叫时时勤拂拭，勿使惹尘埃，我觉得在重构这件事上很适用。

现在多数程序员连“消除重复代码”的必要性都还认为是需要讨论的事情，在这种意识普遍存在的前提下，我觉得重构很多时候无从谈起。像 110 楼倒数第二段话这种价值观完全相反的，我根本没有讨论的欲望。

可以简化成一个成本问题.
所以要看这个"直接上级"是站在什么角度来考虑成本了.

不定期重构的系统, 迟早会腐坏

分情况。。比如服务器支撑不了更多业务需求。不重构你就别来埋怨服务器老崩。。

@crs0910 我其实也是这么干的。。。有把握的根本不会告诉上级，做了再说。。。当然。这也是有风险的。所有负责的测试总是说我这为什么出些莫名其妙的问题。还好频率很低，不然就哪凉快哪呆着了。。

支持，平时闷声不吭随手就重构才是好习惯，代码不是一次性写完美的，随手就改随手就改随手就改。
把重构花费的时间和人力平摊到每时每刻才是真正的成本。
单独花时间重构就像是跟老板说我之前有好多问题没解决，快要爆了，给我点时间。但是你之前跟老板承诺的时间可能很短。
软件开发流程中也没有把重构列为单独一项
而重构是编码过程中的基本意识和操作。
我也在实践。

根据实际情况看，一般来说不会轻易的重构

@no1xsyzy 求同存异。人类一思考，上帝就发笑。阶段性认识，或许我之后也会随着阅历成长，经验堆积有同意你的看法。赞👍。

不能，不见兔子不撒鹰，，，