你们会去“优化”同事的代码吗？

更好，以后出了事找他就行了

改的时候最好跟你讨论一下

@dongyado 我觉得看到别人写的东西有问题，可以提，但是不能自己来

不会，最多提一下，除非自己是技术主管，否则这样做只能说心智太低。

code review 的时候让他自己去改咯

不会改别人的代码

@yxaaa123 对，告知，或者讨论是最基本的尊重，还能相互学习提高，如果直接改，只能说这人情商着急。

你们缺少 code review...

说句题外话，改写的部分写的好么？

你这种情况还好，我突然发现某个功能不正常，然后发现的代码是被直接清除了....虽然这些兼容代码是丑了点..

更新的是代码规范还是逻辑实现？
公司应当有一个统一的编码规范，大家都必须遵守，不应当在这个点上产生冲突；
至于逻辑实现，先行告知并讨论，选最优。

关键是改好了还是改坏了，从 lz 的描述，应该确实是改好了。。。

最好不要，如果真的要优化，应该先和同事讨论一下

会事先和同事沟通一下，但是大部分情况更偏向于直接一个 if else 把自己要走的逻辑单独出去。

会

在代码合并到 master 就应该做 Code Review 。

完全不懂你在说什么
git 新手在 commit 或 push 文件时出错了呢 也说不定
把 commit -m 发出来或许就更明白你在说什么了

这种问题应该贴代码，我就经常改别人的代码

会 但是会事先沟通说明以及解释

好在意他到底改的好还是改的坏。本身他未经你允许就改这个很粗鲁，沟通都没有的。

好像我改得最多了。觉得不好就顺手给改了。

一般没必要我不会改，改好了没好处，改坏了还麻烦。

其实这个就是个开发流程问题，如果代码采用审核机制，这个过程是知道的，大家效率会好很多。
流程：
需求会->模块分发->git 提交到代码审核平台->审核通过后就继续->如果没通过写下相关的意见->如果对意见不满意->提出复议->复议通过后代码将被统一提交到测试->如果复议被否决你就去改了后提交->然后提交给测试
这套流程是个人觉得最好的一个流程，效率和质量都能保证，哪怕有外包人员也行，但是 90%的公司都根本不注意开发流程，基本上就是扑上去乱搞一通

闲的蛋疼才去改别人代码，除非别人允许你改而且你代码质量确实比别人好的情况下，还得提前通知一下。要不就是集体 code review 或者 refactor 的时候

楼主需要解答下「优化」加上了引号表示其他含义还是真的优化了你的代码？我理解为后者。

这个问题应该分两个问题：

1. 同事修复并优化了我的代码对不对？
2. 同事改了最初由我写的代码而未通知我对不对？

1) 我觉得那位同事做得没有错。软件工程是个纯粹理性的工程，不是简单的我做一点你做一点拼凑出一个项目。代码的知识产权属于公司而非你个人。每个人都有自己的局限，别人帮你改了错你应该客观地表达感激。按照你的观点，你在职没人会动你的代码，离职之后更没人敢改你的代码，整个项目的代码越来越烂，这不是反智吗？如果因为这件事情而玻璃心来 V2EX 找认同感， LZ 应该乐观积极一些。做人得客观。 客观人士小组 https://www.douban.com/group/493081/

2) 如果流程上有 code review 环节而他没守规矩通知你来 review, 这是他的问题，应该帮他指出来；如果整个公司都没有 code review, 而改别人代码大家一般会通知上一次改动的人，应该提醒他，并且在公司推行 code review; 如果流程上就没有 code review, 大家改了上一次别人写的代码也不会通知别人（这个需要和公司内的其他人确认而不是你以为怎样，或者 V2EX 上的人以为怎样），这是流程缺陷，应该推行 code review.

随便改人代码和反感别人对你代码有意见本来就都是一种低情商的体现，重点不是改得好改得坏的问题。

有规范按照规范流程来（ code review ，统一编码规范等），没规范就讨论着来。

也就是说，不要玻璃心怕人对你代码质量有意见，也不要总 “自以为是” 的帮别人改。

都是打工的，对吧。

改别人的代码确实应当知会一下本人，不然很是不妥

前段时间被要求去优化同事的一个代码.....结果掉到一个很深的坑了，代码太底层了，太多依赖考虑不过来...准备下周再改回去 = =。。

优化个毛 直接重写

h 会找同事聊下自己对代码的看法。不会轻易去改别人的代码，一来是程序员都是自傲的，二来不同的人对业务的理解不一样了如果接手别人开发的代码，需要认真跟同事他当时为什么这么实现的，以免由于自己不了解而导致做了一些不好的事情。

个人很不喜欢这种 “你的代码” “我的代码” 这种叫法，大家在合作做一件事情，代码是大家的。

1. 态度问题
工作上如果看到别人的代码有问题，还要战战兢兢的考虑要不要帮他改，这明显是一种影响效率的做法。
如果看到自己的代码被别人修改了，我觉得应该抱着一种谦虚学习的态度去看为什么被改，大家互相学习才能进步。

可能有经验不足的开发人员随意改别人的代码造成一些问题，但是程序员不就是从错误中成长起来的吗。

2. 这种事能避免吗
开发过程中，不管怎么切分任务，总免不了遇上这种情况。只让一个人负责一块代码而跟别人没有交集，个人认为这是一种很危险的做法（再牛的人也会犯错）。

3. 流程问题
有人提到了 code review 。我想说，即使有 code review ， review 的过程中也不可能发现所有的问题，程序的优化是无止境的。我鼓励开发人员一旦发现有不合理的代码，随时去改（当然要考虑下项目发布什么的），至于怕出错什么的，我们要测试， ci 这些事干啥的？


@yxaaa123 楼主你好，我觉得对这种事没什么好“无语”的，恰恰你应该拥抱这种做法，这种“无语”的态度在我看来是一种自负的表现。希望对你有帮助。

不允许也不应该直接修改在职员工的代码！如果发现问题，通知对方，让对方修改！确实有问题，并且对方拒绝修改的，知会上级领导！

大家都很在意到底是改好了还是改坏了，其实我是加了引号的。。。

@leoli 我并不是“谁也不许碰我的代码”，而是“请告诉我哪里错了”，如果有人提出了我的错误，我一定虚心接受，但是这种直接去修改才是自负。

@Honwhy 以后别这样了。。真的

@yxaaa123 心累，以后不干了

@yxaaa123 如果有时间的话，应该一起讨论下，并且 pair programming 一起修改的。不过很多情况下，我们可能没有足够的时间把工作做的那么细，所以遇到这种情况还是要多点包容。我觉得比较好的做法是自己看看别人改的有没有道理，有道理，就默默的感谢，接受，并学习；如果没有道理或你觉得改的不好，大可以找他一起讨论下，来个 pair programming 。

除非是接手 否则不管 人家至少测过能跑 改完跑不了 锅谁的