各位老哥，如果你们写好的代码，才提测，就被老员工擅自修改且在改完提交后才跟你说，你怎么想？

[Gaussen]

上周开会分配给我一个新的需求，我本周三的时候刚刚写好，然后今天提测，在测试没有提 bug 的情况下，一个老员工 review 了一下我的代码，并且和我说改动代码的时候，他已经改好并且提交了。

我当时看了一下他的代码，发现对我的实现逻辑改动巨大，大到什么程度，大到我这几天就相当于只写了一些 if 判断，核心实现逻辑全部被推翻，并且代码量大概只有我三分之一。

我以为他有什么特别好的实现方法，就仔细的看了一下，想学习学习，究竟怎么把代码缩减到如此地步。结果越读越感觉不对劲，后来自测了一下发现，实现的需求和产品的需求截然相反。

我拉来产品特意又确认了一下，我的理解没有错，于是我和产品与那位老员工开始扯皮，不过大多数时候是我在旁听，是他和产品在就需求方面 battle，battle 的结果是他说服了产品，然后需求使用了他改写的那套逻辑，这之后我坐在椅子上，洗了个梨，越吃心里越不舒服，总感觉自己这几天就他妈像个傻 x 一样，劈里啪啦敲了一堆代码，绞尽脑汁想办法实现产品的需求的行为真是宛如弱鸡。

至于这个功能以后出 bug，可别来找我，谁写的找谁去吧。

说明一下，他的实现逻辑因为是反产品定的逻辑，所以简单了很多，我的代码多就多在了很多情况校验，他直接一刀切所以就没那些逻辑了。所以对性能来说，他的代码要比我的快，不过实现逻辑并没有什么好学习的，因为没有什么技术亮点。

[qping]

没什么好想的，
1、一般老员工都不屑甚至是厌恶修改新员工的代码，他愿意 review 并且帮你重构，可能是他对你有好感？
2、学习下老员工的 battle 技巧，这才是实用技能

[TypeErrorNone]

因为他有自己对产品的思想。
不是说需求怎样就怎么翻译成代码。

[cjc2017]

emmm 多点时间滑水 它不香吗

[gdrk]

这是老员工实战给你演示该如何合理优化需求并和产品 battle，憋说话，认真学

[Justin13]

我只能说这位老员工比你更了解产品，或许是他从产品的需求描述中看到了产品的真正意图，很多产品写的描述和他本人想要的并不相等。
也有可能看完了需求后觉得这需求无理取闹，也有充足的理由能说服产品，所以就改了。

[ice2neet]

学习如何和产品 battle 这个是个重要技能

[zbl430]

这老员工真是闲的蛋疼，我以为重构你代码有什么优化提供呢，就是蛋疼

[hbolive]

他能说服产品，且重构后比你的性能好，那就说明他这事的结果没问题，只是在操作过程中，（对你）不太友好，让你有种被忽略的感觉。。

[lp7631010]

一般来说 这种情况而且还说服了产品 有可能是产品不了解你们公司的真正产品 需求不合理导致 老员工熟悉所以提前修正了不合理的东西，只是和你这边一样沟通少了点。只是猜测

[ETO]

我不喜欢改别的代码，也不喜欢别人改我的。不过这老员愿意这样做，感觉人还是挺好了，就是跟你缺少了沟通。

[hp66722667]

多学一下 battle 神技，站好队，你咋跟产品整一块堆去了

[webcoder]

同意 9 楼的说法，既然他能说服产品，表示他对这个系统的理解和产品甚至在产品之上。至于不和你说，大至可能有两种原因，一时间不够了，二可能是觉得和你说完代码都能作完了，干脆写完之后你看一下代码和你自己的代码思路核对一下差异，更方便理解系统的流向。

这件事你可以往好的方面去想，他帮你搞定这了段代码，首先，这代码出问题找不到你。再者如果他看了代码发现不对和产品沟通，之后再由产品和你沟通修改代码，这一左一右的时间，再加上你要重改代码的时间，估计你的加班是跑不了了，甚至可能会背上让项目限期的锅。 我觉得这老员工对你很好了。

[cquptzzq]

这事得看你和老员工关系咋样吧，我平常写完一坨坨代码还指望老大能抽出个时间给我看一样提出问题呢，怎奈人家没时间。