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

[hp3325]

我就是上级，基本原则就是能跑的东西不要动！

影响到业务未来的，影响到性能的支持。炫技的自己一边玩儿去。。

[mysunshinedreams]

理解重构的意义，但并不支持。

[wupher]

能理解，不一定能支持。

我自己也是，尤其是大规模重构，尤其是底层架构重构。

越是深年旧坑越是如此，重构后引发的问题往往比之前还多，填坑的小伙伴也往往从踌躇满志到心力交瘁。

现在我宁可建议搞新系统，然后从业务上逐渐予以淘汰，或将旧业务予以迁移。

[xomix]

做上级的时候理解过，在老项目里面引入新框架做过重构，然后，今后再有机会宁可重做也不重构了。

[undefinedz]

不能，业务稳定第一，老大的意思是：你来重构，多出的测试工作量，运维工作量谁来做？如果出了产线问题谁来担责？

[no1xsyzy]

看完感觉说的 “重构” 都不是一个事。

我觉得重构其实根本不需要任何的理解和支持。
某段代码（因为需求原因）需要作修改的时候就直接顺便重构掉了。

[liuzhaowei55]

我是程序，理解也知道重构的好处，但是重构是在太难了。只能是在不断淘汰老业务的时候去演进。

[no1xsyzy]

@CHYK 我觉得你说的根本不是重构，而是修改。
重构的核心不是不发生任何改变吗？重构完除非调 commit 或者记得原本的代码否则根本不可能发现重构了。
更何况重构不可能解决、也不太可能帮助解决千年虫问题和年号问题，要能解决一定是用了未定义行为，或者编译器或者运行时有 bug。

[troycheng]

参与了两个大规模的系统重构（其中一个彻底重写百科，没错，是百度的那个百科），如果没有特别强烈的需求（比比如已经严重拖累业务发展），一般是不会获得支持的，业务系统涉及非技术的因素太多。

[CHYK]

@no1xsyzy 我大概能理解你所说的理性化的，或者理论化的"重构"，大概就是修改一个原型，接口的实现，而不改变接口本身。但是现实情况是，重构一般是长期，局部化的调整，甚至是架构调整，甚至是一个人或者团队的资源调整。
(这个没有经历过的人大概不会明白，简单就是说，往往是以重构的名义，实际也是重构，但是期间会做转换核心资源的调整，可能原来是围绕 Amd 这个人，然后一点点慢慢局部替换，最后就编程 intel 了)
换言之，人写代码，是既要考虑人，也要考虑代码。不能只考虑代码本身呀。(您应该不是 robot 发言)

至于后面说的老大难的问题，甚至 bug，这个可以叫做 fix，但当时确实是可以支撑下去的。也就是我上面的核心观点：
业务走不下去了么？需要提重构这种事儿。具体点儿，以往那个千年虫的问题，当时他就能解决，为什么他要甩锅给后来的人，且当时用的时候也是没有问题的，只不过 1900 和 2000 出现的时候(也就是他开发时的后面)，那时才叫 bug，如果当时的人解决，就是重构了。然后这些前辈却没有，可想而知重构不是那么容易。（可能我没有说清楚）

其实我可以反问您，我耗费这么人力，时间，财力搞的重构对于当前的业务有啥益处？后来的问题，后来的人不能搞么？这个东西为啥一开始没有就设计好？既然一开始没有设计好(又不是我们设计的原型)，现在又能用，何故看了一本重构就来谈重构？

私以为，所谓的重构，clean code，不过是程序员自己的消遣，在领导面前 show own profession，然做过独立开发者，自己要解决生存，赚钱问题时，这。。。

总之，我不喜欢重构(尤其是前一个离职的人花两个礼拜写的东西，要我接下来的 2 个月都在维护和重构他的东西，所谓的兜底，所谓的擦屁股)。要么就推翻重来。要么就开始设计好。

[fancymax]

有强制的单元测试和 UI 测试覆盖率要求~没写测试的 pr 无法 merge

[Yiki]

重构不可能把
直接重写吧……

[qiumaoyuan]

@no1xsyzy 有这样一个回复真的难得。

[luozic]

重構個鳥，直接運行不了就把老的幹死，假裝換個新的繼續。 那麽公司 /軟件都死了，不少一個新的垃圾系統。

[iamjs]

已经满足不了未来 1 年的业务需求。分出一个小 team 来逐步重构。完整测试后进行更迭。。

[lovejunjie1]

说点最近遇到的案例。之前追漫画用的大妈之家（ dmzj ）。最近他们老大说，为了以后的发展，我们要迁移服务器。可是网站用的祖传代码，已经多年没有维护了。新招的技术员一脸懵逼。啧啧，真的惨。现在已经四周了。技术员不知道重构到哪个部分了。现在晚上 12 点之后还是会断网的，大概是更新服务器的码子吧。
这事儿怎么评价呢……是苟且苟出来问题了。被动重构，难受的一比……

[Marlon]

天天在重构，关键是产品流程细节都没理清楚。。。/(ㄒoㄒ)/~~

[bluefalconjun]

除非开发新模块 否则绝不重构...

N 年的客户你说扔就扔吗... 别说 CEO 了 光销售就得过来骂娘了...

[wormcy]

不理解不支持 不增加新功能的重构是个笑话

[otakustay]

@lovejunjie1 我是真从来没见过大妈之家这种敢在线上重构的玩法……

[crs0910]

# 怎么对经理说
“该怎么跟经理说重构的事？”这是我最常被问到的一个问题。毋庸讳言，我见过一些场合，“重构”被视为一个脏词——经理（和客户）认为重构要么是在弥补过去犯下的错误，要么是不增加价值的无用功。如果团队又计划了几周时间专门做重构，情况就更糟糕了。如果他们做的其实还不是重构，而是不加小心的结构调整，然后又对代码库造成了破坏，那可就真是糟透了。
如果这位经理懂技术，能理解“设计耐久性假说”，那么向他说明重构的意义应该不会很困难。这样的经理应该会鼓励日常的重构，并主动寻找团队日常重构做得不够的征兆。虽然“团队做了太多重构”的情况确实也发生过，但比起做得不够要罕见得多了。
当然，很多经理和客户不具备这样的技术意识，他们不理解代码库的健康对生产率的影响。这样的情况下我会给团队一个较有争议的建议：不要告诉经理！
这是在搞破坏吗？我不这样想。软件开发者都是专业人士。我们的工作就是尽可能快速创造出高效软件。而我的经验告诉我，对于快速创造软件，重构可带来巨大帮助。如果需要添加新功能，而原本设计又使我无法方便的修改，我发现先重构再添加新功能会更快些。如果要修补错误，就得先理解软件的工作方式，而我发现重构是理解软件的最快方式。受进度驱动的经理要我尽可能快速完成任务，至于怎么完成，那就是我的事了。我领这份工资，是因为我擅长快速实现新功能。我认为最快的方式就是重构，所以我就重构。

—— 摘录自《重构-第 2 版》第 2 章 ”重构的原则“

[chiu]

有重构的工作内容和工作量，不过优先级会比较低

[gaocc]

基本不支持，没有实际效益，而且出错锅没的甩，反而有损失。
所以架构特别重要的了，重写很多时候不然重新写，很现实

[lovejunjie1]

@otakustay 2333333，这下你看到了。大妈之家的同志辛苦了。如果他在看 V2，估计应该会看到这个帖子吧。（最近肯定是没空了。哈哈哈哈哈哈）

[robinlovemaggie]

我的老板只喜欢他看得见的符合他审美的重构，除此之外，都是无稽之谈。

[saulshao]

首先，要说清楚什么是重构。我理解重构是指将代码的实现方法在不改变输入输出的前提下，修改内部结构。这可能包括但是不限于下面的事情：
1. 将原本在某个函数内的几行代码移出，使其成为一个新的函数。
2. 将某些（少量）代码重写，以提高效率或者增加可读性。
3. 将整个包的文件夹结构调整，新增或者删除某些文件 /文件夹。
4. 将整个项目重写，期待之后达到一个理想的效果。
其实上述的这些事情，后面的 2 个会严重影响整个项目的“可运行性”，可能需要运行完整的业务场景测试才敢干。我不建议制定一个长期的计划干后面的 3 和 4。
如果只是 1 和 2，我的建议是不要告诉经理，自己干就行了，至于重构之后是更好还是更差了，其实是一个见仁见智的事情。因为可读性其实不是一个客观标准。举个例子：有人认为射雕英雄传更容易理解，而有的人则认为西方哲学史更简单易懂。
而效率则需要运行某些测试或者遇到特定的场景才能够证实。
因此，我的结论是：重构不是一个总是正确的事情，既然如此，那就应该基于个人的选择来决定。

[linergoudan]

重构是不可能重构的，只要能跑，就算是屎也要让你在屎里翻滚

[thfurior]

不能，先不说重构花的时间，那么多的测试用例谁来写？

[reus]

@thfurior 重构难道不是可以用旧的测试用例？

[lincanbin]

看重构能不能被认可为绩效和产出，能就会推动，不能就不会。

[Michaelssss]

没有重构,当业务发生变更后,用新业务替换掉老业务...你学到的新的视野什么的再新业务里面做完就好了,反正之后还是一坨屎

[CoCoMcRee]

用新东西开发, 一般大家讨论下, 做下技术选型,觉得坑能趟过去的 那就干.
要是老代码, 业务不变的话, 基本会可能回去重构.

[qiyuey]

取决于“成本”和“收益”

[KunMinX]

又不是不能用，又不是用户痛点，谁在乎你因为架构反人类而加班呢。

何况，十个人里边有 9 个人并不真正的懂得重构及其价值，他们对重构的理解仅仅停留在形式上，而不是事实规律原则上。

重构的目标是解藕，解藕的本质是职责上的分离，而不是形式上的假分离。都 9102 年了，某些社区还在疯传 MVP 架构，这是 3 年前就已弃用的违背原则的垃圾架构。

[huisezhiyin]

我一度以离职来胁迫和告诉领导重构的意义

[jinhan13789991]

java 编程思想里有一句话：
继续错误的责任由他人承担，而承认错误则由自己承担。
你愿意承担别人的错误吗？

[no1xsyzy]

@CHYK 我同意你说的 “以重构的名义”，但我不认可你说的 “实际也是重构”。
你这个叫 “重架构”（ restructuring —— 我瞎编的，不清楚有没有这个词，或者更正确的词）和技术性调整而不是 “重构”（ refactoring ）。甚至可能同时进行重构和其他事情。
不要同时做两件事，更不要在同时做两件事时以为自己在做一件事。
一个简单的判断：重构应该能够在 20 分钟内完成（或者按自己的番茄钟时间），并且这 20 分钟就好像从未存在一样消失了。

[tairan2006]

代码规模小，重构不如重写

[diggerdu]

有个组整个双月的计划都是重构

[fsafdasfsdafsd]

@CHYK
看你的回答，我觉得你没理解重构。

[no1xsyzy]

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

[min]

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

[gimp]

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

[banxi1988]

我想重构，老大想重写。

[polun]

不能。

[ezreal]

不能

[anyele]

能，因为上级是技术出身

[qiumaoyuan]

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

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

[b0x]

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

[niubee1]

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

[sampeng]

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

[sampeng]

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

[wikiisviki]

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

[pipinstallpy]

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

[CHYK]

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

[mintist]

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