老同事不让重构代码怎么破？

[CrazyMoon]

最近组里开始做代码互审，同事审到偶修改的一个程序，有意见。意见是偶除了修改需求要求的内容之外，还做了一些其它修改。

偶的确改了一些其它内容，这因为偶发现程序里面的一些 hard code 比较难读（比如 type = 'P', type = 'A'之类的），于是创建了几个常量，以便看代码的人通过常量名理解这些编码的意义。

偶觉得这样改很好，但同事不同意，她说 1)改的地方太多，后人比较版本的时候，会对修改内容感到很困惑。2)改了需求外的东西，可能会导致意料外的 bug 。

同事资格比较老，且一向比较看重规则。偶年轻而且又比较散漫，没能坚持自己的观点，最后还是把这些东西又改回去了。不过偶依然觉得自己原本的做法没错。。。要怎么办呢？

[Orenoid]

还没到维护不了的地步，重构又还有阻力，改出问题还得你担责，风险和收益完全不成正比。

[baiyi]

要去争取

“业务部门会认为系统的正常工作很重要。软件开发人员常常也采取了这种态度。但这种态度是错误的。”
“请记住，你作为一名软件开发人员。软件的可维护性需要由你来保护，这是你角色的一部分，也是你职责中不可缺少的一部分。”
“请记住：如果忽视软件架构的价值，系统将会变得越来越难以维护，终会有一天。系统将会变得再也无法修改。如果系统变成这个样子，那么说明你没有尽到自己的责任。”

以上内容节选自《 Clean Architecture 》，我觉得挺有道理的

[dandycheung]

做对的事，等着被开除。我支持你。

[murmur]

你同事是对的，无论你再牛逼，你一定要考虑上线后出 bug 谁背锅，谁给你做全面测试
老的系统出了 bug 属于无法维护的范畴，重启一下就过去了，做的再烂的系统也是久经风雨，就算是 bug 我都知道什么时候触发，针对性回避就可以
你重构后属于你开发的问题，你要背这个黑锅的
我们集团 OA 是 0X 年开发的，domino （使用 vb 语言开发），维护专门有人负责出问题重启，都坚持到现在，前端代码还是 js 和 vbs 混写（ IE6 年代的数组可以像 vb 一样用圆括号访问，比如 arr(0)）
有什么是必须维护不可的

[murmur]

宁可推倒绝不重构，推倒属于新项目研发性质，可以双轨运行，出了最严重的问题大不了停掉就是老的还能用

[rapperx2]

偶真是精神洗脑的字，我读完 脑海里全是偶！！！！！！！！。好想 Block 啊！！！！！！！！！

[goodryb]

你是嫌工作量不够还是鱼摸着不舒服，吃力不讨好的事情还想不通

[balaWgc]

倒，还有这种事啊，听偶的，偶支持你

[otakustay]

我觉得他说的 2 不合理，但 1 是对的，不如重构单独一个 commit，用 message 详细说明改了什么为什么改，后人也能 blame 看到

[essicaj]

不要老想着改别人的代码，到时候出问题都不知道该找你还是找她。

[zooo]

那就等你变成老员工

[AstroProfundis]

> 除了修改需求要求的内容之外，还做了一些其它修改
> 改的地方太多，后人比较版本的时候，会对修改内容感到很困惑
这是对的，需求没有要求你做，你就不要放在这个需求的实现里面，另外提一个需求来改历史代码里面不合理的地方

> 改了需求外的东西，可能会导致意料外的 bug
这个就看你们有没有足够的测试资源了

[raymanr]

没事儿别搞啥重构...

我自己的我都不想动

[akira]

一次提交做一个事情

[sunulin]

这类似帖子感觉过几天冒出一个来

[Biwood]

如果仅仅因为局部代码看着不顺眼，想通过重构一小部分代码来解决问题，那还是趁早放弃。
如果是想做整个项目的代码翻新，可以做渐进式的局部重写（ rewrite ），而不是重构（ refactor ），当然有这几个前提：

1. 项目已经做好了模块解耦，即你改动一个模块的时候不影响全局
2. 你有足够的技术自信
3. 充足的开发时间
4. 保证重写方案可以进行到底，而不是最终只做了一半

尽量避免新旧代码大量混合，否则对后来的维护者来说根本就是灾难，而且维护的人越来越多，代码风格就越混乱，最终整个项目就是一团糟。
当然，对于一开始规定了严格代码风格和代码质量评审的团队根本不应该存在这些问题。

[geekboy]

狐吧月神？

[6oML852dJf9Kn2l7]

我看见这个 [偶] 吐了！！！！！

[buffzty]

你提出的问题是对的,但是改老代码是不对的. 你可以跟他说以后新写的项目禁止使用字面量 全部使用有意义的常量.
老项目真的是能不动就不动. 而且人家说不定 知道这里错了,只是不想改而已

[eryueyu]

出了问题你负全责的话，可以改