当同事在未通知的情况下进行不必要的改进时，如何对我的代码负责？

我的队友之一是我们IT部门所有行业的杰作，我尊重他的见识。

但是，有时他会不加提示地查看我的代码（他是我们团队负责人的第二命令，所以可以预期）。因此有时他会在我完成最终目标并立即进行更改之前查看我的更改，甚至破坏了我的工作一次。

其他时候，他对我的3个月以上的代码进行了不必要的改进。

这让我很烦，原因有几个：

1. 我并非总是有机会改正我的错误
2. 当他感到困惑时，他没有花时间问我要做什么，这可能会影响他的测试或更改
3. 我并不总是认为他的代码可读
4. 截止日期不是问题，他的当前工作量除了查看我的代码更改外，不需要在我的项目中进行任何工作。

无论如何，我过去曾告诉过他，如果他在我的工作中看到一些他想更改的东西，以便我可以拥有我的代码（也许我应该说“缺点”），并且他没有回应，请把我保持在工作状态。 。

当我问他向我解释他的改变时，我担心我可能会变得冒犯别人。

他只是一个沉默寡言的人，坚持不懈，但他的行为仍在继续。我不想阻止他进行代码更改（不是像我能做到的那样），因为我们是一个团队，但是我想尽自己的一份力量来帮助我们的团队。

补充说明：

• 我们共享1个开发分支。我不会等到所有更改都完成一个任务后再做，因为我可能会失去一些重要的工作-因此，我确保我的更改可以建立并且不会破坏任何内容。
• 我担心的是，我的队友没有解释其更改背后的原因或目的。我认为他不需要我的祝福，但是如果我们不同意我的做法，我认为最好是在我们都了解发生了什么之后再讨论利弊并做出决定。
• 我尚未与团队负责人讨论此事，因为除非有必要，否则我宁愿在不让管理层介入的情况下解决个人分歧。由于我的担忧似乎更多是个人问题，而​​不是对我们工作的威胁，因此我选择不打扰团队领导。我正在研究代码审查过程的想法，以帮助促进组织更有组织性的代码审查的好处，而又不至于使我烦恼。

我认为大多数开发人员都会在某个时候找到自己的位置，我希望每个受害的开发人员都能意识到，当他或她成为大四学生并被迫清理初级编写的代码时，这将是多么沮丧。

对我而言，在这种情况下避免冲突归结为两点：

1. 礼貌。与某人谈论他/她的代码可以使开发人员知道您感兴趣，并且可以作为成年人来讨论。

2. 忘记“代码所有权”-团队拥有代码。其他想要进行更改的人是一件好事。如果高级开发人员进行的更改“不可读”或更糟，请撤消。您不需要太激进，只需让编辑知道他/她的更改没有用，并且您很乐意讨论您的版本转换。

请记住，团队对代码的所有权很棒，而且可以双向进行。如果您发现在别人的代码中没有用的东西，请修复它。过度占有和沟通不足是创造有毒发展环境的必经之路。

您和大多数回答者将其视为两个同事之间的沟通问题，但我真的不这么认为。您所描述的听起来比其他任何事情更像是一个残破的代码审查过程。

首先，您提到您的同事是第二把手，并且期望他会审查您的代码。那是错误的。根据定义，对等代码审查不是分层的，并且肯定不仅仅在于发现缺陷。它们还可以为所有参与人员提供学习经验，社交互动的机会，并证明是建立集体代码所有权的宝贵工具。您还应该不时查看他的代码，向他学习并在他错了时纠正他（没有人每次都正确）。

此外，您提到您的同事会立即进行更改。这也是错误的，但是您当然已经知道了。如果他的工法不是问题，就不会问这个问题。但是，我认为您在错误的位置寻找解决方案。老实说，您的同事让我想起了……我，在类似情况下对我有用的是一个定义明确，可靠的审核流程和一系列出色的工具。您并不是真的想阻止您的同事检查您的代码，并要求他停下来并与您交谈，然后再做一点小小的改变。也许有一段时间，但是他很快就会变得太烦人了，而您又回到了开始的地方，或更糟的是：他将停止审查您的代码。

解决方案的关键可能是对等代码查看工具。我通常会避免产品推荐，但对于代码审查，请参考Atlassian's Crucible确实是救生员。它的作用似乎很简单，而且确实如此，但这并不意味着它并不惊人。它连接到您的存储库，使您有机会查看单个变更集，文件或文件组。您无需更改任何代码，而是对感觉不太正确的所有内容进行评论。而且，如果您绝对必须更改其他人的代码，则只需在更改集内留下注释，以解释您的更改。如果您想了解更多详细信息，请观看Crucible产品页面上的入门视频。坩埚的定价并不适合所有人，但有许多免费的同行评审工具。我曾与之合作并享受其中的一个是评审委员会，我敢肯定，通过简单的Google搜索，您会发现很多其他人。

无论选择哪种工具，它都会完全改变您的过程。无需停下来，离开椅子，打扰其他人并讨论更改；您需要做的就是每周休假一段时间并仔细阅读评论（一周一次只是一个建议。您比我更了解自己的日程安排和日常工作）。更重要的是，核心评论存储在某个地方的数据库中，您可以随时检索它们。他们不是围绕水冷却器的短暂讨论。我最喜欢的旧评论用例是在我们的代码库中引入新的团队成员时。当我可以让一个新的人走遍代码库，指出我们到底被卡在哪里，在哪里有不同的意见等等时，总是很高兴。

继续前进，您提到您并不总是发现此同事的代码可读。这让我知道您没有一套通用的编码标准，这是一件坏事。同样，您可以将其视为人员问题，也可以将其视为过程问题，并且我再次强烈建议后者。让您的团队团结起来，尽快采用通用的编码风格和标准集。您选择了开发生态系统中常见的一组标准还是提出自己的标准并没有多大关系。真正重要的是您的标准要保持一致并坚持下去。那里有很多工具可以为您提供帮助，但这是一个完全不同的讨论。只是为了让您入门，一个非常简单的事情是让预提交钩子在您的代码上运行某种样式格式化程序。您可以继续编写自己喜欢的代码，并让该工具自动地“修复”它，然后其他人才能看到它。

最后，您在评论中提到管理层不认为需要单独的开发部门。好吧，我们将它们称为“开发分支”而不是“管理分支”是有原因的。我将在这里停留，因为没有任何理由让我脑海中形成怒。

话虽如此，但请注意，我毫不怀疑您的同事在这里有过失。这不是我的意思，我的意思是您的整个开发过程也有问题，这很容易解决。用适当的工具武装自己，探索众多正式和非正式程序，然后选择适合您团队的程序。很快，您将意识到大部分“人员问题”不再存在。而且，请不要听任何提出“我们是一个小团队，我们不需要所有这些”借口的人（包括您自己）。一支有能力的开发人员团队可以在不到一周的时间内设置必要的工具，使可以自动化的一切实现自动化，并且再也无需回头。

PS。“代码所有权”是一个含糊不清的术语，经常有人争论不休，对不同的人来说意味着不同的意思。您可以找到关于C2的大多数不同（有时是相反）观点的绝妙收藏。

使您想对“您的代码” 负责的过程是什么？您是否有责任确保某些功能正常运行？主持人是否说过“迈克尔，我要你对……负责”？还是您的责任是隐含的，因为每当某些功能出现问题时，领导和团队其他成员都会向您寻求帮助？

无论哪种方式，如果您有责任，那么您都需要对代码进行授权。下次另一位同伴进行单方面更改时，线索又回到您那里来解决它们，您应该与线索坐下，并要求使您的权限和责任保持一致。

这样做并不能解决整个问题，但是您可以尝试在源代码中添加更多注释。

1. 如果代码不完整，则可以这样标记。
2. 如果代码块的目的不是自我记录，则应该对其进行记录。

总而言之，尝试制作柠檬水，而不是浪费时间吮吸柠檬。正如迈克尔所说，总的来说，队友并不会让你看起来很糟糕。尝试从错误中学习，并将其应用于将来的修订。

如果您认为他的变动有负面影响，请（外交地）发声。如果是我，我只会问为什么要进行特定的更改，然后看看您是否可以捍卫您的原始更改。您的高级同事也是人。他很可能错过了一些东西，并且/或者没有意识到他提供的任何负面影响。

每个人都隐含地“拥有自己的代码”，而不管政治，法学或经济学如何—这是“事物的本质” —您自然会感到自己与自己的工作有个人联系。

如果您的同事正在采取您描述的行为，并且在您要求抬头时仍无反应，则至少可以说，该同事是无礼的，并且可能正试图损害您的利益（最坏的意思是。） 。） -确实不是听起来像一个团队球员。

一个好的同事会触及基地，你并指出与您的代码的问题给你 -让你修复/更改，或做出适当的反应。我非常感谢，即使我还是个新手，我的导师总是向我指出我做错了什么，解释原因并让我（或让我）修复它。那使我成为一个更好的程序员，每个人都受益。这就是我回顾他人所做的工作时一直做的事情。然后，您（或任何人）实际上从您的“万事通”中学到了什么，代码和团队也都变得更好了，包括您的老师：教学有助于理解。

如果有可能，我将与团队负责人私下讨论。根据您对情况的描述，好的团队领导者会支持您-不好的团队领导者不会。...显然，这需要谨慎-您必须自己判断。

如果您编写代码，那么我应该对其进行审查。

如果我在审核期间更改了您的代码，则该代码不再是我审核过的代码，而是我更改过的代码。因此，需要对其进行审查。大概是你

如果我用更改提交新代码而没有人检查我的更改，则表示我犯了（1）未审核的更改，并且（2）如果认真对待代码检查，可能会犯下最严重的错误。

我认为您目前正在以正确的方式进行处理-但是很快就会出现一个引爆点，在这种情况下，您可能会完全不满意以这种方式进行编码。

如果我是您，我将要求与此人快速一对一，并冷静而坚定地解释我的PoV。团队对代码的所有权等都是很好的，但是除非您给每个开发人员足够的空间来完成他的工作，犯错误并加以改进，否则您将永远无法构建好的代码。这可能是较早而不是稍后的摩擦区域。

（如果这是在workshop.stackexchange上，则有完全不同的答案。找出正确的代码审查方法很容易。要说服您的同事遵守这一点要困难得多）。