This topic created in 2236 days ago, the information mentioned may be changed or developed.
最近组里开始做代码互审，同事审到偶修改的一个程序，有意见。意见是偶除了修改需求要求的内容之外，还做了一些其它修改。
偶的确改了一些其它内容，这因为偶发现程序里面的一些 hard code 比较难读（比如 type = 'P', type = 'A'之类的），于是创建了几个常量，以便看代码的人通过常量名理解这些编码的意义。
偶觉得这样改很好，但同事不同意，她说 1)改的地方太多，后人比较版本的时候，会对修改内容感到很困惑。2)改了需求外的东西，可能会导致意料外的 bug 。
同事资格比较老，且一向比较看重规则。偶年轻而且又比较散漫，没能坚持自己的观点，最后还是把这些东西又改回去了。不过偶依然觉得自己原本的做法没错。。。要怎么办呢？
40 replies • 2020-04-25 13:42:28 +08:00
 |
|
1
wysnylc Apr 23, 2020  3
偶?现在是 2010 年?
|
 |
|
4
a719114136 Apr 23, 2020
你没错，他也没错。就一风格问题，没那么多可纠结的，既然他资格老就听他的呗。
等你资格老了就你说的算了
|
 |
|
5
th00000 Apr 23, 2020
信老同事的,
觉得不爽, 后台再提交一个 pull request 请原本开发这个地方的同事帮你 review 一下, 确定你没有将老代码改出 bug, 再把代码合进去.
|
 |
|
6
imn1 Apr 23, 2020
你的项目，你对
公司的项目，她对，尤其是她说的两点，注意并不是说你改错了
|
 |
|
9
blindie Apr 23, 2020 via Android
就让你们看不懂 她这个项目才稳稳归她 own 饭碗捧的牢。其他修改感到困惑就抽离这个修改单独 commit 并完善注释文档 意料外的 bug 没测试的吗？总而言之就是让你别碰这些 那你就理解别碰就好了
|
 |
|
10
opengps Apr 23, 2020 1
你是做技术的，但是眼里不要只有技术。改动他的代码，及时你在技术上得满分，但在这件事的处理上也未必能及格。指出他人代码不足会让人感觉不爽，自然也就会不顺从你的意思。
另外，少改动线上代码，这本身也是个非常安全的做法
|
 |
|
11
yikyo Apr 23, 2020
你的错，你在当前任务中做了无关此次任务的工作。你要重构可以，单独提任务，测试，上线。想法是好的，做法是错的。
|
 |
|
14
ccoming Apr 23, 2020
如无必要，勿重构代码。
|
 |
|
18
glfpes Apr 23, 2020
这个‘偶’，有 15 年前内味了
|
 |
|
19
lneoi Apr 23, 2020
这也没不让你改吧，改了需求以外的东西以后不好复查，可以另外提一个
|
 |
|
21
Orenoid Apr 23, 2020
还没到维护不了的地步，重构又还有阻力，改出问题还得你担责，风险和收益完全不成正比。
|
 |
|
22
FinnBai Apr 23, 2020
要去争取
“业务部门会认为系统的正常工作很重要。软件开发人员常常也采取了这种态度。但这种态度是错误的。”
“请记住，你作为一名软件开发人员。软件的可维护性需要由你来保护，这是你角色的一部分，也是你职责中不可缺少的一部分。”
“请记住：如果忽视软件架构的价值，系统将会变得越来越难以维护，终会有一天。系统将会变得再也无法修改。如果系统变成这个样子，那么说明你没有尽到自己的责任。”
以上内容节选自《 Clean Architecture 》，我觉得挺有道理的
|
 |
|
23
dandycheung Apr 23, 2020 via iPhone
做对的事，等着被开除。我支持你。
|
 |
|
24
murmur Apr 23, 2020
你同事是对的，无论你再牛逼，你一定要考虑上线后出 bug 谁背锅，谁给你做全面测试
老的系统出了 bug 属于无法维护的范畴，重启一下就过去了，做的再烂的系统也是久经风雨，就算是 bug 我都知道什么时候触发，针对性回避就可以
你重构后属于你开发的问题，你要背这个黑锅的
我们集团 OA 是 0X 年开发的，domino （使用 vb 语言开发），维护专门有人负责出问题重启，都坚持到现在，前端代码还是 js 和 vbs 混写（ IE6 年代的数组可以像 vb 一样用圆括号访问，比如 arr(0)）
有什么是必须维护不可的
|
|
|
25
murmur Apr 23, 2020
宁可推倒绝不重构，推倒属于新项目研发性质，可以双轨运行，出了最严重的问题大不了停掉就是老的还能用
|
 |
|
26
rapperx2 Apr 23, 2020 2
偶真是精神洗脑的字，我读完 脑海里全是偶！！！！！！！！。好想 Block 啊！！！！！！！！！
|
 |
|
27
goodryb Apr 23, 2020
你是嫌工作量不够还是鱼摸着不舒服，吃力不讨好的事情还想不通
|
 |
|
28
balaWgc Apr 23, 2020 1
倒，还有这种事啊，听偶的，偶支持你
|
 |
|
29
otakustay Apr 23, 2020
我觉得他说的 2 不合理，但 1 是对的，不如重构单独一个 commit，用 message 详细说明改了什么为什么改，后人也能 blame 看到
|
 |
|
30
essicaj Apr 23, 2020
不要老想着改别人的代码，到时候出问题都不知道该找你还是找她。
|
 |
|
31
zooo Apr 23, 2020
那就等你变成老员工
|
 |
|
32
AstroProfundis Apr 23, 2020
> 除了修改需求要求的内容之外，还做了一些其它修改
> 改的地方太多，后人比较版本的时候，会对修改内容感到很困惑
这是对的，需求没有要求你做，你就不要放在这个需求的实现里面，另外提一个需求来改历史代码里面不合理的地方
> 改了需求外的东西，可能会导致意料外的 bug
这个就看你们有没有足够的测试资源了
|
 |
|
33
raymanr Apr 23, 2020
没事儿别搞啥重构...
我自己的我都不想动
|
 |
|
34
akira Apr 23, 2020
一次提交做一个事情
|
 |
|
35
sunulin Apr 23, 2020 via Android
这类似帖子感觉过几天冒出一个来
|
 |
|
36
Biwood Apr 24, 2020
如果仅仅因为局部代码看着不顺眼，想通过重构一小部分代码来解决问题，那还是趁早放弃。
如果是想做整个项目的代码翻新，可以做渐进式的局部重写（ rewrite ），而不是重构（ refactor ），当然有这几个前提：
1. 项目已经做好了模块解耦，即你改动一个模块的时候不影响全局
2. 你有足够的技术自信
3. 充足的开发时间
4. 保证重写方案可以进行到底，而不是最终只做了一半
尽量避免新旧代码大量混合，否则对后来的维护者来说根本就是灾难，而且维护的人越来越多，代码风格就越混乱，最终整个项目就是一团糟。
当然，对于一开始规定了严格代码风格和代码质量评审的团队根本不应该存在这些问题。
|
 |
|
39
buffzty Apr 24, 2020
你提出的问题是对的,但是改老代码是不对的. 你可以跟他说以后新写的项目禁止使用字面量 全部使用有意义的常量.
老项目真的是能不动就不动. 而且人家说不定 知道这里错了,只是不想改而已
|
 |
|
40
eryueyu Apr 25, 2020 via iPhone
出了问题你负全责的话，可以改
|
Select Language