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

[Livid]

[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
看你的回答，我觉得你没理解重构。