你们平时会重构自己代码吗？

还是秉承能用就不动的想法？

项目早期会，结构稳定了重构都是偶尔提炼一下通用逻辑了，写代码都不经常，重构更不经常

构不了一点

没事别乱动

全部是自己写的，没事的时候，心情好的时候，或多或少可以重构一下。
只要别人参与了逻辑，能不动就不动

重构是我的乐趣所在

除非是自己的个人项目不然怎么可能想动就动

会重构，都是实在看不下去或者不重构每次要花费更多时间的情况下。
重构导致最严重的 BUG 是 P2 ，一个很小的疏漏，但是影响到了渠道的划分，所以定级较高。

但说实在的，你节省出来的时候会被新的需求所占据，但导致线上问题的情况会少一点。

这可太会了，一闲下来就想重构
就是大部分时候项目经理或下游会拦着不让

一直都会
不过感觉自从有了 ai ，越来越多失去自己的智慧痕迹了，毕竟在 ai 面前，越来越不智慧

能用就不动，很多经手的业务，生命周期可能也就 1-2 年，之后就被废弃了，重构没意义。

经常，一般是迭代几版之后发现以前有些冗余代码，在后续模块引入之前写的服务的时候会把以前模块的这些冗余代码做重构

重构的快乐可太大了，看着代码量减少跟拉屎一样舒服

自从不用自己为大模型 token 付费后，只要闲下来就会借助大模型尝试重构。和大模型沟通以及看大模型思考过程以及重构结果，也算是一种温故而知新。

会，别人写的也会，换成自己的看着就舒服

为啥要重构....

重构有啥意义吗...

＃12 铲

自己拉完了的屎，我不想再去翻。

会新建一个版本文件来对业务代码进行重构，旧版本依旧运行，等重构版本测试稳定了就替换了，目前感觉还好吧，就是类爆炸，多个版本类

除非有大量的单元测试，不然重构出错了怎么办……

想，但是不敢或者不让，除非需求明确说明，那还可能有足够时间多测试测试。

特别是那种你的服务已经投产，有多方在使用的情况。
哪天因为改了以前的代码，生产出问题，半夜接电话，心慌慌的回去排查或者紧急变更，就老实了。

会的，有空时候心情好就会改一下，砍掉很多之前赶工期瞎写的代码

以前就想重构，但是自己能力有限。现在有了大模型的助力，让 Cursor 给我提重构的建议，再让它针对每一条建议给出完整可落地的重构方案，别提有多爽了。

有需求有时间就会，没有就凑合用吧。

这个方法好我也打算这么干之前赶工期代码太恶心来

以前会，现在发现没人在乎。

什么 go ？

csgo 必需 go

如果没问题的代码, 那就要看我有没有空.

对于 php 这种代码跟着版本走，会修补不兼容的地方。

重构意味着可能有 bug 哦，如果测试不够完全的话，指不定哪里就数据出问题了……

又不是不能用，别重构了。

我都是为了用新的 IDE 、新版本运行时、新 API ，才可能用。

大版本迭代时，可以申请多点来重构代码就好了，并知会测试全流程要走一遍
小版本迭代时抽离部分功能重构，并知会测试改该部分功能走一遍；然后多个版本后其实重构的差不多了

曾经有个小朋友最爱雕花，有一天他改了支付接口中字段的下横线为驼峰，然后.... 问他回答道这样看着顺眼

直接让 ai 重构

我自己写了一个 py 脚手架，每次写新项目就把之前的一些经验放在脚手架重构上面

如果是提前规划好的，那肯定按照计划去重构。

如果本来就是去拉屎的，拉完走人就好了，就别老惦记你那坨屎了。

自己写的代码能跑不动，别人写的代码我就蠢蠢欲动

不会，没有 bug 绝对不会回来看一眼

需求有变动就重构，否则就不动。要不改了还得让测试测，这不凭空给别人增加工作量吗？

平时没事也不会这么闲大工程

公司的不会自己的会

写的实在太烂的同事代码，然后后面我要基于这块改就会重构下

不会上次费心 go 了下过了两个月公司就裁员

不会，可能会排排版，说实话一个人写一个东西，重构思路变化不大的。

很经常，随着每个迭代都会排进去一个重构。基本上每次重构都会有新的思考和收获，感觉很棒。不过一定要做好风险管理，不宜一次性涉及太多。或者修改太多的话新增一个新的接口路由，这样切回老的逻辑也很方便

平时不会，如果遇到新增功能或改动时，如果有空档则会顺带重构部分相关代码，不会重构整个项目

为什么要重构自己的，当然是重构别人的啦

如果要删除功能和增加功能肯定要重构。

自己的代码会经常的重构抽取通用模块到基础库里面等，但是和别人合作的代码的话那就是屎山，能不动就不动

有时候重构确实是好事。但是我们 boss 也说了，能运行的代码，建议不要随便动它。

自己写的优秀代码不需要重构，别人的垃圾代码必须重构，忍不了一点

肯定要重构的，不然怎么提升代码能力怎么进步呢

别人写的除非发现 bug 否则就不动，这样后面出 bug 可以根据 git 记录甩锅🤣

不值得写单元测试用的代码，不要重构，需要的时候重写就行了。有价值的代码，没有单元测试，先补单元测试再重构。就一个简单原则，单元测试都没有，不配重构，只需要重写。重构的重点是得无痛重用，有业务价值。重写的重点是写，没有用例，你又怎么证明重写的比之前的山更好？作出一样的功能，还是你输了。

AI 工具跟我家自动猫砂盆一样，以前自己铲屎很懒，看不下去了才铲。现在工具铲，我只负责倒屎。

公司的不会(除非必要), 自己的会.

看重构回不回带来某种收益，比如心情舒畅也是收益！

正常不会，不过有新需求或者 BUG 修复这种场合，可能看情况把那块重构一下

能用就不动，除非必要

我会定期重构，主要是随着业务迭代代码必然是会腐朽的。后面新功能迭代我自己写起来也得心应手一点。

不过其他同事的代码我一般是不会去碰，谁的内容谁负责好了

主要看又没有时间，有大块儿时间还是会想重构一下的，小块时间就算了，半天一天都懒得动它（万一出问题就更多时间进去了

会先评估不重构往后发展最终会怎么样。如果结果可接受，没必要重构；反之则重构。
在老板（给你发工资的那个人）的角度上，无论如何都不希望重构，因为你是在让他重复投资。所以重构是对内对你自己的，对老板的汇报，只能借助升级、扩展、增加兼容性的方式来表述，切不可说重构。

受教了表述重构的确对于程序员可以理解老板可能会厌烦

以前项目大部分只有自己写的时候会，现在两三个人进来一起做，他们乱写我也照着乱写，能跑就行

经常精简代码逻辑，看着几千行代码会很烦人的

Always

首先如果不是时间特别赶的情况下，当时写的就代表了自己当时的最高水平；
其次生产的东西不是想改就改的，除非有很大的性能瓶颈。
所以一般来说即使学了新东西有新感悟，最多也就做做意念重构了，也是进步迸发的时刻

一般是前期过度设计了后期发现并不需要但是没花力气去重构了

只动自己的, 并且不重构不行的情况下会重构.

以前不加班的时候会，现在天天加班别说重构了，bug 只要不被人发现我都懒得修。

会重构我现在开发流程是先基于功能开发一个版本当然在开发过程中我也会基于单反重复 2 次及以上的代码都会提炼出来。会做一些简单的优化比如减少 if ease 多用 map 结构加快查询速度，对于重复的页面和逻辑都用 map 包装区分。属性获取的时候都会提炼成函数获取值方便封装逻辑。多用三元表达式。对于复杂的业务提前抽离和计算和和校验逻辑。以前人工 review 现在有 ai 帮助很多尤其是我这种取名废。我是真取不好啊只能取一些比较中性的。专门看了重构的那个书写完代码优化的时候我会自己想诶这个地方的业务后续扩展可以用什么设计模式比较好。我一般会提前用会扩展的设计模式方便后续迭代经常这样干自己水平其实提高很快的很多都是熟能生巧的事情