这是一个创建于 2832 天前的主题，其中的信息可能已经有所发展或是发生改变。
看见了同事写的一段代码不严谨，数据多了会出错，心痒痒想给改过来，但是怕改了项目会出错，不改看起心里总不是滋味，纠结。你们遇到同事的代码不严谨会怎么去做（修改比较麻烦的那种）？
 | 1 hhacker 2018-03-19 10:56:30 +08:00  30 可以提醒同事，改不改是他的事，但是！ 你不要改！ 你不要改！ 你不要改！ |
 | 2 ofnh 2018-03-19 10:56:31 +08:00 via Android 1 提交 bug，让他自己改 |
 | 3 HuHui 2018-03-19 10:57:26 +08:00 via Android 1 你们缺个 QC |
 | 4 p2pCoder 2018-03-19 10:57:48 +08:00 1 不要动别人的 bug |
 | 6 depress 2018-03-19 10:59:51 +08:00 1 提醒，别动，只要你动过的代码以后出事都是你的问题，如果他不，只要不影响你，当没看见，影响你的话找上级 |
 | 7 alexnone 2018-03-19 10:59:54 +08:00 1 头像好评. 不要改.可以提醒. 提醒的方式也很多.看你想怎么处理了. |
 | 8 guoyuchuan OP |
 | 9 Kilerd 2018-03-19 11:58:51 +08:00 1 坚决不改，提 BUG 最好，如果不行就帮他加个测试用例，复现这个 BUG 告诉他。 |
 | 10 wizardoz 2018-03-19 13:08:25 +08:00 1 别人写的让别人自己改。 如果非要你改，先写好充足的单元测试，用单元测试保证修改后代码的正确性。 |
 | 11 ChenXuting 2018-03-19 13:10:28 +08:00 via iPhone 1 楼主这个头像搞得我想举报。<(｀^)> |
 | 12 abccba 2018-03-19 13:11:58 +08:00 1 @ChenXuting me too... |
 | 13 Oo0 2018-03-19 13:23:13 +08:00  1 @ChenXuting 不是很正常嘛。< |
 | 14 zhuangzhuang1988 2018-03-19 13:25:21 +08:00 1 自己千万别修改 |
 | 15 linus3389 2018-03-19 13:37:11 +08:00 1 不要乱改别人的代码，git blame 引发真人 PK 可不好玩 |
 | 16 viator42 2018-03-19 13:42:01 +08:00 1 提醒一下就行了,如果他听的话就说说修改方案,不听的话就等他翻车好了 |
 | 17 xrlin 2018-03-19 13:44:09 +08:00 via iPhone 1 提醒一下就行了，最好不要自己改。 |
 | 18 QK8wAUi0yXBY1pT7 2018-03-19 13:50:41 +08:00 1 提醒，代码上加注释、标记 |
 | 19 yy120345 2018-03-19 13:52:03 +08:00 1 可以提醒同事，改不改是他的事，但是！ 你不要改！ |
 | 20 XinLake 2018-03-19 14:33:14 +08:00 via Android 1 这种事情你以后可能还会碰到，你不要随便去改。 告知你上级，程序有问题，为什么有问题，有原因、解决方案、参考资料更好。 最好开个会，你自己，程序开发者，能做主的人，有技术判断能力的人，这 4 种人都要参与。 |
 | 21 Paddington 2018-03-19 14:39:14 +08:00 1 看来你们没有 code review。 千万别动！ 千万别动！！ 千万别动！！！ |
 | 22 af463419014 2018-03-19 17:20:54 +08:00 1 做一个能复现 bug 的测试样例,让他改 自己千万别动!千万别动!! |
 | 23 happyzed 2018-03-19 17:21:56 +08:00 1 code review |
 | 24 otakustay 2018-03-19 17:40:44 +08:00 3 看了这楼，我总算是明白公司好和不好的差距，明白技术氛围是什么意思了…… |
 | 25 huluhulu 2018-03-19 17:46:52 +08:00 1 提交 BUG,让他自己改自己测... |
| 26 XinLake 2018-03-19 17:55:20 +08:00 via Android 1 |
 | 27 yrom 2018-03-19 18:48:41 +08:00 1 原来。。。是这样的吗 看来要改改我手痒的毛病了 _ |
| 28 abccba 2018-03-19 18:53:57 +08:00 2 @otakustay 我的看法： 如果在一个鼓励“追求卓越”，真正有技术氛围的团队（部门、公司），团队 leader 和同事都是有追求的人，那么可以自己去改。 但是，国内大部分公司（团队）都不是那样的，包括几个一线公司的（绝）大部分团队（亲身经历、对周围的观察）。这种情况下，那么做，数学期望上对个人来说是负作用的。劣币驱逐良币？囚徒困境？ 当然，应该还是有理想中的团队的，但幸运的人毕竟是少数？ 绝大部分人都是普通人，不是那种能力挽狂澜的神人；可以试着用自己的行为去影响周围人，但不要抱太大希望。 我的建议是，楼主可以先评估下风险，和 leader 讨论下，如果得到肯定，可以尝试去改动。当然，要做好最坏的打算和心理准备。我刚工作时也像楼主一样，看不惯的小地方也愿意去改，有时候即便没有引入 bug，也会有各种各样的问题（包括无意义的扯皮），就会发现不是“改几行代码”那么简单，有些打击积极性。这种事情做多了就会发现，其实也是耗时间和精力的，但付出了不一定会得到认可。不过，楼主你想做的事情，如果代价不是很大，还是尝试一下吧，如果尝试一下觉得有意义，可以坚持；如果觉得受挫了，再平凡地活着，就像大部分人一样，其实也行？ 最后，就算影响不了周围人，自己也要保持追求卓越的态度，自己的代码要好好写。 我们一路奋斗，不是为了改变世界，而是为了不让世界改变我们。《熔炉》 |
| 29 otakustay 2018-03-19 19:18:34 +08:00 1 @abccba 是的，我总结出来是这么几条，不要怪我太严厉： 1. 技术氛围真的是区分团队好坏的一个东西，我现在能理解为什么有人会在我厂工资没竞争力的情况下选择留下了 2. 我在 V2EX 上也看到过很多人抱怨团队氛围不好，但从这个楼来看，我有一个疑问：氛围是不是就是楼上这些人搞出来的？ 3. 无论团队的氛围是怎么样的，当出现问题时抱着这样的态度，作为一个个人，已经离“成长为优秀”越来越远了 4. 正确的办法难道不是：自己修一修，但可以不上线，然后找不找人去聊另说，总之遇到好玩的想写的代码当然第一时间写上去啊 |
 | 30 surfire91 2018-03-19 19:56:42 +08:00 1 我就不服楼上两个能说到团队技术氛围上去。我赞成说通知维护者但是不私自改的，因为在某些复杂的情况下，你不一定分得清是 feature 还是 bug。 |
 | 31 Him 2018-03-19 20:10:11 +08:00 1 你不会用嘴说吗 |
| 32 abccba 2018-03-19 20:13:22 +08:00 1 @surfire91 一般的做法或者工作流程来说，没法私自改吧。不知道你们是什么开发流程，我们这边是先和模块负责人沟通，之后写完代码强制发 code review，通过 cr 才有权限 commit. 如果要自己改，肯定是需要和同事沟通的。 |
 | 33 abccba 2018-03-19 20:22:59 +08:00 1 对哦，应该先和原作者沟通下。如果他完全不想管，那你再决策。 如果他很乐意修复，你可以和他先讨论讨论修复方法，有强烈兴趣可以毛遂自荐去解决 == |
 | 34 nullen 2018-03-19 20:30:58 +08:00 1 不要改． |
 | 35 gravitybox 2018-03-19 20:31:45 +08:00 via Android 1 交流一下吧 |
 | 36 akira 2018-03-19 23:16:14 +08:00 1 不要私自去动别人的代码. 不要私自去动别人的代码. 不要私自去动别人的代码. |
 | 37 NxiJSiOS 2018-03-19 23:36:19 +08:00 via iPhone 1 让他自己改 |
 | 38 Leigg 2018-03-20 00:26:28 +08:00 via iPhone 1 不说话，让他翻车 |
 | 39 lattemint 2018-03-20 02:30:34 +08:00 提醒他吧，他不改是他的事情。还有你这个头像我点了两次了………… |
 | 40 johnnie502 2018-03-20 05:01:43 +08:00 1 出错再改，而且别人写的代码，可能有些地方已经考虑过了，你觉得会出错的地方，其实是不会被执行到的。没有真凭实据就不要费这个劲了 |
 | 41 scipio 2018-03-20 08:44:34 +08:00 1 不要自作主张地改！ 不要自作主张地改！ 不要自作主张地改！ 但是作为一个团队而言，最好也不要视而不见。 我个人建议： 你觉得这段代码有问题的话，最好能构建一个能让这段代码跑出问题的用例: - 如果你们有较完善的 BTS，就直接提 BUG 出来，并把你的定位结果也附上去。 - 如果你们只是一个不太正规的小团队，那么就喊上这部分代码的负责人，以及你们的 Leader 聊一下这个事情，先把问题抛出来(这里的建议是： 千万不要一上来就说人家的代码有问题。而是一上来只谈你的用例)。如果大家都认为这是个问题了，你可以提出你调查的结果(即 xxxx 的 xxx 代码有问题)说出来。如果连 Leader(负责人)都不认为是个问题的话，那就不要再继续往下聊了。但最好能形成一个简单的备忘录来证明你组织大家讨论过这个问题，结论是啥啥啥。省得万一以后有什么衍生问题发生时，别人责怪你没早把问题提出来。 |
 | 42 jimi2018 2018-03-20 08:46:54 +08:00 1 提醒一下不就 ok 了吗。 |
 | 43 cxh116 2018-03-20 09:10:02 +08:00 via Android 1 不改。 看人，对方是对技术有追求的话，提醒一下，否则当作没看见。 @otakustay 技术氛围是技术 leader 搞出来的。当 leader 有工具格式化不格式化，要打空格的地方不打空格，导致代码都不能正常高亮，虽然能运行。没错，只要能运行就行了。 你作为下属要去大谈代码质量吗？ 所以， 只跟同道中人谈追求。 这些都不是问题，给的工资过的去就行了。 |
 | 44 uuus007 2018-03-20 11:08:54 +08:00 1 很多时候你看的问题都有其内在的逻辑。 可以询问同事，你的想法对不对。 但是千万不能你来改 千万不能你来改 千万不能你来改 千万不能你来改 |
 | 45 annielong 2018-03-20 14:27:42 +08:00 1 这个和氛围什么的没关系吧，作为程序员肯定不能私自动别人的代码，尤其是 GIT 的公共环境下 |
 | 46 miemiekurisu 2018-03-20 14:39:36 +08:00 1 Please DO NOT touch anything if it still woks well now, unless you REALLY KNOW what you're doing. |
Select Language