到底改还是不改

[guoyuchuan]

看见了同事写的一段代码不严谨，数据多了会出错，心痒痒想给改过来，但是怕改了项目会出错，不改看起心里总不是滋味，纠结。你们遇到同事的代码不严谨会怎么去做（修改比较麻烦的那种）？

[Paddington]

看来你们没有 code review。

千万别动！
千万别动！！
千万别动！！！

[af463419014]

做一个能复现 bug 的测试样例,让他改
自己千万别动!千万别动!!

[happyzed]

code review

[otakustay]

看了这楼，我总算是明白公司好和不好的差距，明白技术氛围是什么意思了……

[huluhulu]

提交 BUG,让他自己改自己测...

[XinLake]

@otakustay

技术部门，技术工作，但是正能量技术导向、科学准确导向的公司不多见。
建自己小王国，家族化，倒是容易见。

[yrom]

原来。。。是这样的吗

看来要改改我手痒的毛病了 눈_눈

[abccba]

@otakustay 我的看法：
如果在一个鼓励“追求卓越”，真正有技术氛围的团队（部门、公司），团队 leader 和同事都是有追求的人，那么可以自己去改。
但是，国内大部分公司（团队）都不是那样的，包括几个一线公司的（绝）大部分团队（亲身经历、对周围的观察）。这种情况下，那么做，数学期望上对个人来说是负作用的。劣币驱逐良币？囚徒困境？

当然，应该还是有理想中的团队的，但幸运的人毕竟是少数？
绝大部分人都是普通人，不是那种能力挽狂澜的神人；可以试着用自己的行为去影响周围人，但不要抱太大希望。

我的建议是，楼主可以先评估下风险，和 leader 讨论下，如果得到肯定，可以尝试去改动。当然，要做好最坏的打算和心理准备。我刚工作时也像楼主一样，看不惯的小地方也愿意去改，有时候即便没有引入 bug，也会有各种各样的问题（包括无意义的扯皮），就会发现不是“改几行代码”那么简单，有些打击积极性。这种事情做多了就会发现，其实也是耗时间和精力的，但付出了不一定会得到认可。不过，楼主你想做的事情，如果代价不是很大，还是尝试一下吧，如果尝试一下觉得有意义，可以坚持；如果觉得受挫了，再平凡地活着，就像大部分人一样，其实也行？

最后，就算影响不了周围人，自己也要保持追求卓越的态度，自己的代码要好好写。
我们一路奋斗，不是为了改变世界，而是为了不让世界改变我们。——《熔炉》

[otakustay]

@abccba 是的，我总结出来是这么几条，不要怪我太严厉：

1. 技术氛围真的是区分团队好坏的一个东西，我现在能理解为什么有人会在我厂工资没竞争力的情况下选择留下了
2. 我在 V2EX 上也看到过很多人抱怨团队氛围不好，但从这个楼来看，我有一个疑问：氛围是不是就是楼上这些人搞出来的？
3. 无论团队的氛围是怎么样的，当出现问题时抱着这样的态度，作为一个个人，已经离“成长为优秀”越来越远了
4. 正确的办法难道不是：自己修一修，但可以不上线，然后找不找人去聊另说，总之遇到好玩的想写的代码当然第一时间写上去啊

[surfire91]

我就不服楼上两个能说到团队技术氛围上去。我赞成说通知维护者但是不私自改的，因为在某些复杂的情况下，你不一定分得清是 feature 还是 bug。

[Him]

你不会用嘴说吗

[abccba]

@surfire91
一般的做法或者工作流程来说，没法私自改吧。不知道你们是什么开发流程，我们这边是先和模块负责人沟通，之后写完代码强制发 code review，通过 cr 才有权限 commit.
如果要自己改，肯定是需要和同事沟通的。

[abccba]

对哦，应该先和原作者沟通下。如果他完全不想管，那你再决策。
如果他很乐意修复，你可以和他先讨论讨论修复方法，有强烈兴趣可以毛遂自荐去解决 ==

[nullen]

不要改．

[gravitybox]

交流一下吧

[akira]

不要私自去动别人的代码.
不要私自去动别人的代码.
不要私自去动别人的代码.

[NxiJSiOS]

让他自己改

[Leigg]

不说话，让他翻车

[lattemint]

提醒他吧，他不改是他的事情。还有你这个头像我点了两次了…………

[johnnie502]

出错再改，而且别人写的代码，可能有些地方已经考虑过了，你觉得会出错的地方，其实是不会被执行到的。没有真凭实据就不要费这个劲了