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

代码

重构

bug

优化

53 条回复 • 2022-10-16 00:28:48 +08:00

1

frank1256

2022-10-14 10:22:27 +08:00

1

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

2

zwdsix

2022-10-14 10:25:01 +08:00

3

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

3

lmshl

2022-10-14 10:26:16 +08:00

4

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

4

kaz10025

2022-10-14 10:27:36 +08:00

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

5

panlatent

2022-10-14 10:28:18 +08:00

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

6

s524256521

2022-10-14 10:30:13 +08:00 via Android

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

7

wr410

2022-10-14 10:30:40 +08:00

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

8

god7d

2022-10-14 10:33:08 +08:00

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

9

darkengine

2022-10-14 10:33:11 +08:00

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

10

xianyv

2022-10-14 10:37:20 +08:00

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

11

god7d

2022-10-14 10:39:36 +08:00

1

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

12

c8c

2022-10-14 10:58:03 +08:00

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

13

d119

OP

2022-10-14 10:58:34 +08:00

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

14

garlics

2022-10-14 11:00:14 +08:00

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

15

ericgui

2022-10-14 11:01:22 +08:00

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

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

16

janus77

2022-10-14 11:02:13 +08:00

kpi

17

westoy

2022-10-14 11:05:16 +08:00

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

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

18

lujiaosama

2022-10-14 11:10:42 +08:00

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

19

infun

2022-10-14 11:13:54 +08:00

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

20

alen0206

2022-10-14 11:23:12 +08:00

自己不接手的一般不改

21

d119

OP

2022-10-14 11:26:57 +08:00

如果是为了提高可读性作为目的，那起码代码需要有其他人读吧，如果就只是自己维护，别人根本看都不看，或者没机会看，你还重构吗

22

dvsilch

2022-10-14 12:13:48 +08:00

@d119 我个人倒是更愿意重构自己的代码...因为别人的业务代码，在不清楚具体业务逻辑的情况下，很容易牵一发而动全身。
但是自己的代码会有自己看得懂的注释，即使放了一段时间再回头看也能很快读懂当时的思路，并且结合当前的理解写出语法更优雅、性能更好的代码。

23

zwdsix

2022-10-14 12:14:06 +08:00

重写就重写吧，重构啥呀。这楼里有人能说出重构名录里的任意一个重构手法叫什么？

24

zwdsix

2022-10-14 12:17:18 +08:00

所以他们总是会说“重构”这事“很费时”，“没时间做”，“引入更多 bug”。请问重构和 bug 、性能有啥必然关系？

25

fox0001

2022-10-14 12:17:51 +08:00 via Android

自己的代码，会。公司的项目，一般就算了，除非有要求。重构完还得重新测试、改 bug ，一堆麻烦事。

26

kujio

2022-10-14 12:23:41 +08:00

有，不断尝试用新技术替代老技术，然后根据新技术尝试写一个简化版的

27

xuanbg

2022-10-14 13:33:59 +08:00

现在不会。因为现在只可能需要升级，绝对不需要重构。

28

aguesuka

2022-10-14 13:51:12 +08:00

@zwdsix rewriting 和 refactoring 和 <<Refactoring>> 完全是三回事

29

shenlanAZ

2022-10-14 14:31:56 +08:00

不会，可能会把更好的设计思想来做下个项目。

没有性能问题优化重构和浪费时间没区别了。

30

296727

2022-10-14 15:17:27 +08:00

不会，做的好了不一定有奖励，做的差了一定有批评

31

andyJado

2022-10-14 15:37:08 +08:00

@zwdsix
重写可以不重构, 重构必然要写新的.

32

karott7

2022-10-14 16:11:06 +08:00

小项目会，大项目就算了

33

aonshuy

2022-10-14 16:32:57 +08:00

重构是为了引入 bug 和性能问题吗

34

lcbp

2022-10-14 17:51:28 +08:00

无情重构

35

IsaacYoung

2022-10-14 17:52:27 +08:00

不会

36

sadfQED2

2022-10-14 17:55:13 +08:00 via Android

编程第一原则：只要项目还能跑，那就不要动他
编程第二原则：如果项目烂得没法跑了，那你人就赶紧跑

37

mazai

2022-10-14 18:00:12 +08:00

会，代码的第一要务就是保证看你代码的人能看懂

38

xiangchen2011

2022-10-14 18:13:32 +08:00

会，增加扩展性和可读性

39

dolphintwo

2022-10-14 18:31:09 +08:00

面向工资编程，哪来的重构，代码和程序员有一个能跑就行了

40

golangLover

2022-10-14 18:41:21 +08:00 via Android

@lmshl 你好像是 scala 大神。对你很有印象

41

lmshl

2022-10-14 19:00:48 +08:00

1

@golangLover 😊
https://www.bilibili.com/video/BV1Qa4y1L7dj
3:07:00 开始是我，就是从 Future 迁移 IO Monad 后做的社区分享。

42

RicardoY

2022-10-14 19:26:47 +08:00

重构这个词被滥用的太多了，可以去翻翻书，上面有清晰的定义和什么时候应该重构的指南。重构不是为了解决程序 Bug 和提升性能...

43

RicardoY

2022-10-14 19:30:33 +08:00

楼上这么多人，对重构的理解好像跟 Martin Fowler 都不太一样...

44

zhuweiyou

2022-10-14 19:46:43 +08:00

别人写的,不会.
自己写的,会.

45

golangLover

2022-10-14 20:28:08 +08:00

@lmshl 感谢你的分享！

46

kongkongye

2022-10-14 20:34:56 +08:00 via iPhone

个人的开源或长期维护项目就会重构，为了后面维护与扩展更容易，但公司的项目，又不是一个人的代码，就没有重构的想法，而且你想重构上级也不支持，重构了还是那个功能，并没有效益的提升，重构不好出 bug 还要你背锅，不重构老是出各种 bug 问题反而能体现你的价值，造成一直很忙的假象。没办法，上级跟更上级领导不懂技术只能这样，环境如此。

47

kkbblzq

2022-10-14 20:56:59 +08:00

看情况，如果需求刚好改到了相关代码，我觉得需要重构，在影响范围 /时间花费可控在一定范围内的情况下我会做小规模的重构；影响较大的，工期影响比较多的，根据当时需求量和测试资源，有空余的话我会去争取 PM 支持，实在没操作空间的话那就先挂起；

重构更多的是提供可读性、可维护性、可扩展性等等，如果是自己参与长期维护的代码，合理的重构是可以降低不少维护成本的，也可以提高自己对项目代码的掌控性；

说实话，真堆屎山到堆不上去再来搞，那时候只能追求：代码和人有一个能跑就行了😂