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

不能，除非到代码质量和架构已经影响到业务营收的时候才会考虑。

除非项目跑不动，赚不到钱的话估计会

不能，一提就拒绝

不能，因为重构不在 kpi 里

都是领导在推动重构

哪怕作为开发者，我也很反对重构，绝大多数重构就是为了 api

小公司。
以前的上级（ VPE ）不喜欢重构，一套烂代码用了 10 年还要继续修补贴药膏加功能。
现在他们全离职了，我最大，重构起来为所欲为，把那些天天爆炸的代码模块全重写了。

能不能看怎么说。
维护成本和重构成本全计算好发给上司一般都会同意。

@msg7086 没有上级。。为所欲为

能。
并且，在一定范围内支持重构上的试错。
最终目标还是让产品更稳定，口碑更好。

有需要就重构，一堆四五年前的烂代码都重构了

可以，可能要看上级是不是技术出身了，一般技术出身的更能理解重构的含义

理解和支持是两回事

看公司和领导吧，我前段时间重构了一个项目，直接上级理解并支持，算到 KPI 里了。他想知道重构的意义和收益何在，如果只是基于个人喜好，为了重构而重构，那肯定是不支持的

我司是重构驱动型公司

目前接触到的，技术路线的支持，非技术路线的不支持

不能

多数能明白重构的必要性和价值，但基本不会支持和着手执行。
只有一家公司，因为主要业务是外包完成的，后续无法继续支持，也没人能维护，才重新设计和实现了整个系统。

从重构的时间和人力成本来讲，我更支持从一开始就考虑周全并保证质量。持续迭代优化比从头再来简单多了。

我就想知道 livid 想重构 V 站吗

能
这个东西跑了很久没出问题了，你不要乱改

表示理解，但不支持，因为没有时间，就算愿意用自己空闲时间重构都不行，因为要测试。

问题是重构不应该是单独某个时间段里做的，而是在日常开发中进行。上级根本不需要知道。

求稳吧

之前的公司在主要业务部门，不想做产品需求的时候领导就会组织重构，顺带要点绩效。
现在的公司做创新业务，一般没等到重构的机会就战略调整了

我支持重构，如果是在我对业务的可控范围内
但是很多时候没有时间去做这件事
久而久之也不愿再提

重构这种东西应该是自上而下的,不然阻力非常大

单元测试搞不起来，重构也搞不起来

什么是重构。应该在代码还能忍的时候就开始重构。不幸的是，很多意识到需要重构的时候实际需要的已经是重写了

@kkeiko #4 +1

只有迭代 推翻全重搞是不可能滴

能理解，但是通常业务优先，不到不得已的时候是不会开始重构的。

之前重构一个大型系统项目，梳理了一篇文章，有兴趣可以点击阅读。
https://mp.weixin.qq.com/s/yQJwMHS9Bb7FHoqPJ3mo2g

提过，短时间没有价值就否了。

我认为是能理解的，但是现实条件太刻，如果那些提重构的人能力不强，上级肯定也会否决的。

不重构，维护成本和人力成本逐步增加，连人都招不到。
已经提上日程，预估今年应该可以重构，看排期。

能理解，但是不支持，没资源去重构

参考小平同志提出中国特色社会主义的历史。重构也是要有实际需求支撑的，稍微有点代码洁癖张口闭口就重构的同事能躲多远躲多远。

一知半解，不能

能不能看场合，这是一个产品质量和工作量之间的取舍问题，不是二选一

有一句话：老板要结果，程序员要重构... 我们老板属于前者，每个月都有那么几天，没啥需求，这段时间是重构时间...

上级和领导都是技术出身，之前也是程序员，非常理解 refactoring。
但什么时候 refactoring 则需要根据业务发展安排轻重缓急。
闲的时候就 refactor，忙的时候就先凑合着用。

老板这都是为你们啊，重构的话那岂不是需要你们 996 了～

作为一个运维，重构都是对用户（开发者）透明的。
有的时候搞得好我们会吹下牛逼，每个月省了好多钱！节省了好多时间！老板听着很高兴。
但想让老板花资源来支持，我自己都懒得找他好么……

自己能悄么声儿干了的就干了，不能的就暂时搁置吧。反正能干的事儿挺多的呢。

因为顾虑到会增加 bug，所以是吩咐以前的代码尽可能不要动

不能，惰性太严重了。。。

只要能跑就不支持

完全理解，但是支不支持看情况。如果任务排的比较紧就不支持，会有优先级更高的任务要做。我们最近正在准备重构，一方面业务方向有变化，一方面最近任务比之前少了一些。

这是我之前抱怨代码过长时间没有重构的朋友圈配图：

一般都能理解吧，但一般也不会支持的，跟 KPI 搭不上啊

不能，重构需要成本，业务目标不清晰。除非遇到一天三崩，不得不的时候。

@sneezry 感谢你这图，哪天我忍不了了，也发一下

我就是领导……我支持重构……

我们是微服务架构，你不怕麻烦想重构某个服务尽管重构好了。反正时间就是这么多，这个没办法。我所能提供的帮助就是帮你在设计上尽量地去掉不必要的东西，使服务更加纯粹。最多再帮你写点代码。。。

一个字，能

首要的问题应该是，工程师能够解释清楚重构的意义吗？不是用“感觉”、“信仰”、“维护不动”去解释，而是实打实的把业务目标、技术目标、市场目标放在一起去合理解释

我新来的这家招我进来就是为了能重构... 好在不是强制性的，目前的考虑是从大的结构往细微的逻辑方向进行调整，而不是一次性全部重写，保守一点吧

@xuanbg 233, 领导一看就是过来人。

感觉大家好像默认重构就是一件无比正确的事情似的……

从帖子里大部分人的对立面聊聊这个话题。

先表立场：小公司，我就是上级，开发出身。我的 boss 不算太懂技术。

大概 80%的重构需求由开发提出，其中只有 20%的重构需求我会认可，80%都被我拒了。常见原因按比例列举如下：
1，纯粹就是想炫技，想用新技术，想搞事情想赚工分。这个比重最大，一般特点是年轻、活跃、激进、前端等。这些人纯粹就是吃饱撑的，兴趣驱动最大无视其他一切因素。没办法，只能说磨砺中成长吧。。。把他们的无穷精力稍微倾斜一些在预研、攻关、分享等技术型任务会更双赢一些。
2，代价，时间和人员。说实话这是男默女泪的巨坑。但毕竟公司不是学校，盈利是根本目的。学院里好的技术人员可以用无限的资源挑战学术的极限，但社会中好的技术人员需要带着沉重的现实镣铐尽最大可能让各方利益都能接近最大化。这部分只能说可惜，但必须让开发同学能理解能把心态调整好。
3，不够平滑。这种一般原则上已经赞同了，但执行方式上比较粗暴，比如项目主线暂停、阶梯式升级导致用户流失、服务暂停等。会搁置、会要求优化、会要求分解，分阶段落地或者部分落地。
4，动机不纯。一般发生在老员工。为了攫取话语权和 KPI。这部分直接堵回去，打负分。

以上来看，根本原因大部分都出在视野问题，视野不够大，看不到全局看不到负面。另外一个根本原因是出在立场问题。毕竟屁股决定脑袋，有时候并不是使坏，是潜意识让人做出了对自己利好的决策而没有意识到。期望大家能换位思考，能认可共赢价值观，能杜绝自我自私损人利己。

大概 20%的重构需求由我提出，其中 80%会得到上级的认可，推行并落地。
毕竟同是开发，懂得在屎山中摸爬滚打是什么滋味。有时候能从架构层面发现开发同学们发现不了的重构点，就尽力去推动改善，这也是对团队对公司都有利的。但毕竟不存在人定胜天的鬼话，有时候我也有局限，推不动的甚至推错方向的，同学们多担待吧，我陪你们。

温柔的不能，没时间

理解，但是不支持，谁会和钱过不去呢，上级也很无奈，上级的上上级理解不了

多数人重构只是为了符合自己的开发逻辑，对业务并没有太多改善。支不支持重构应该看人，刚刚进公司不到一年就喊重构的就不要理，把业务吃通透了，能规划新系统来帮助提高业务效率等等，说得清楚就支持

能理解，也想支持，但是基本很难落地，而且对于不懂技术的大领导来说，重构等于承认整个团队以前做的有问题。

我最近刚好在重构，没有向领导申请，直接干的，最近几个星期每天都自己一个人加班到十二点以后，刚上完线。

不能 一重构 就 996 去吧 直到项目功能全部实现 来自 惨痛的重构经验

一般都支持边迭代边重构。

偏技术的领导，还是支持重构的

自己抽时间重构，领导不关心这些，只关心你的代码稳不稳定，重构完没问题的话他就不会管，有问题会影响绩效

我理解你们

不能，只能慢慢迭代掉

支持，好在写年报的时候大吹特吹。

很难，谁也不想承担这个风险。

之前在外企的时候 重构可以当做业务排期来做 现在换到国内的大公司 重构只能找闲的时候。。。

我们这边从 C#重构到 java，结果研发那边工期一再拖延，现场的人快被坑死了

@wtks1 这应该是重写了 =，=

看需求排期，在不干扰正常工作情况下可以

@flyingghost #56 看了这么多 你是说得最在理的

能理解 很支持

但是考评的时候不看重 所以完全看自己兴趣

个人觉得，重构的根本问题不在技术上，而在利益纠纷上。特别是如果你重构的内容、接口涉及到几个小组，部门的时候，比如一个 gpio 口大家共用，这部分你改动一下试试看。

如果确定背后站着一个足够支撑你在利益冲突时，给你加持的人，那么可以谨慎操作。

否则，一谈重构，我现在的感觉就是实际收益(对公司)不好。
如果这种重构对个人，比如 KPI 有特殊的意义，那就另话。

More Important: 业务到了不重构不升级就走不下去了么？(比如: 千年虫？日本天皇年号类的？)

谨慎，谨慎，谨慎。

纯个人意见。

重构不好听，换个词呗。 技术改进，持续优化。。

非常支持……

而且会帮助我协调推动这些事。当然前提是我给出合理的理由说服他。

@msg7086 我也好不容易能为所欲为了，但是发现已经熬太久，体力不支，力不从心……←_←

你能说服他带来的好处，或许能。
不然，想都别想，不然他会认为你工作量不饱和。

能。但需要想个说法来和业务价值结合，忽悠产品经理。

很少。我自己的策略就是在每次改动代码的时候做小规模重构。当然这样会有同事说你 git commit 碰了太多没必要碰的代码。另外一种策略就是在不是那么忙的几天，添加单元测试，同时部分重构。
至今没有遇到上级会同意，“嘿，这周你把 xxx 重构一下”。

能明白代码腐朽就能理解代码重构的价值，尤其是业务需求快速变化的项目

8 年的 php 站点迫于没人维护被要求重写了

能 比较闲的时候支持我们折腾

认同上面的说法，理解和支持是两回事儿。。
如果大老板信任技术管理者，那么他可能不理解重构，但仍然能给予支持。
但是很多业务导向的公司，技术管理者理解重构的意义，但可能无法支持。

会看投入产出比，如果开发一个新需求成本高过重构，就会选择重构，不过一般都高不过。

能，因为她完全不懂，我告诉她重构就是离婚，是净身出户还是对半分主要看前期犯了多大错误。

不能。。而且经常说什么 xxx 地方做过拿过来用就行。。老项目升级都是这个样子。。

code review 是浪费时间 （摊手

上级不会要求。实习跟了一个内部系统，来了不愿意写测试、重构的正式工也拿他没办法。

除非有技术债的概念和相应的资源

你就说，再不重构新需求就做不了了

理解但不支持，KPI 导向，明年就搞新的啦，这坨东西就用新的换掉，或者就丢给别人

我人微言轻，不敢重构。因为自己没做出什么成绩，随意重构可能会导致其他人返工。

我提了几次，终于答应了，说 2019 过完年做，现在又没声了，怒而转岗

有收益就能，放 KPI 里，没明显收益就不能

刚刚重构完