我们都去过那里。你已经编写了一些代码和单元测试，测试都通过了，代码也很合适（没有什么是完美的，对吧？）。然后，确定他们比你更了解并且决定将代码或接口更改为代码的人只是因为他/她不喜欢你使用的变量/类名。没有“真正的”重构，没有真正的优化，没有真正的改进 - 只是不同的词 - 不一定是更好的词，只是不同。
我真正的问题在于：（a）浪费时间;（b）它首先表现出对编写代码的开发人员的公然不尊重。
我的内心反应是抨击，但这反作用。相反，我认为我可能会怀疑一两段作为项目所采用的“宪章”或“哲学”。我想知道是否还有其他人试过这个，如果有的话，是否成功了？
在查看下面的初始评论（感谢之后）之后，我认为我的问题主要在于此更改打破了已经运行的代码的构建。因此，需要花费时间来修复（在我看来）非增值变更的代码。
- 谢谢
答案 0 :(得分：25)
...决定更改您的代码或 只是因为你的代码接口 他/她不喜欢 您使用的变量/类名。
我真正的问题是（a） 这是浪费时间和（b）它显示了一个 公然不尊重这位家伙 编写代码的开发人员 第一名。
我的内心反应是抨击......
我在这些陈述中看到了一些非常关注的事情。
你太个人了。
我曾经和一个在我改变“他的”代码时吓坏了的人一起工作过。他的代码太可怕了;它是马车和不可维护的。他总是熬夜，扑灭火灾和破坏事情 - 基本上是一个消极的贡献者。我在一个周末为一个项目重写了他所有糟糕的代码以获得一个很大的功能，当他星期一回来时有一个非常合适的东西。我并不是说你的东西太可怕了，但也许你需要冷静下来并对此更加客观。
不要亲自接受。退一步考虑一下 - 也许“你的”代码需要修复
如果您发布了代码和更改，我们或许可以提供更好的答案，或者至少通过一两个例子更好地了解情况。
编辑： 在看到代码更改并发现构建被破坏后，我将不得不改变这个答案的基调。我理解史蒂夫的沮丧 - 我同意 - 这不是一个好的改变。它使特定的typedef更加通用，不再具有描述性。
虽然我认为我的一些观点是有效的，但在这种情况下看起来似乎不合适。
代码“所有权”的问题无关紧要。如果代码更改没用，那么团队中的每个人都应该感到高兴。如果他们是好的变化，那么每个人都应该为此感到高兴。如果存在意见分歧，那么你们都需要找到一个共同点。
打破构建不是一件好事。
史蒂夫，对不起，如果我苛刻下来 - 看起来在这种情况下，你的挫折是合理的，但不是因为它是“你的”代码。答案 1 :(得分：17)
在这种情况下可能有所帮助的一件事是要求对所有更改进行代码审查。如果其他人必须首先审查它，人们就不太可能做出毫无意义的改变。如果他们真的可以说服另一位开发人员他们的改变应该进入那么也许它毕竟不是那么毫无意义。
答案 2 :(得分：7)
嘿，
专家！我们都需要 TALK ！
只需将 放在一起，然后TALK ！总有理由改变，总有理由不这样做。
一起决定 ！
不要只是去StackOverflow或论坛并说出这类问题。
新的开发人员做到了 - 他从社区获得的回复可能是积极的（ 是的，错误的代码应该重构 ）。 目前的开发人员也做到了 - 他也得到了社区的回应：“ 白痴可以做出这样的改变！ ”
结果是：长时间适得其反，具有破坏性，令人反感的环境。
谁想要它？
只需 将您的论据放在桌面上 ，就是这样。
新的开发也需要一些介绍。
旧开发者需要列出TOO。
这应该是 协作工作 而不是互相惹恼。
一起决定，谈论，作为团队 。
并且...更好地提出诸如“如何更好地重构这个？”之类的问题。
干杯。
答案 3 :(得分：4)
在任何尺寸为＆gt;的软件开发团队中1，标准化是关键。不仅每个开发人员都能理解其他代码，而且在2年，5年和10年内出现的人可以查看代码的任何部分并看到清晰一致的模式。你是否......以及团队的其他成员......认真地仍然在那里，在这个项目上工作多年？
如果你们“只是按自己的方式做事”并且项目/公司没有正式标准，我建议你与团队和/或老板一起建议采用正式的标准。已经针对各种环境发布了许多标准，您可以将其用作标准或起点。
如果有正式的标准，团队中的每个人都有义务遵循它......无论他们认为他们的方式有多“好”。
对于硬技能这么多。
现在处于软技能方面......
您和您的同事需要建立健康的关系，或决定在不同的地方工作。导致人们觉得他们想要抨击的Tit-for-tats会让每个人都感到不快，更不用说严重危害每个人都需要付钱才能完成的项目。寻找一个你尊重的人（也许是你的老板，也许是一个受人尊敬和头脑清醒的团队高级成员，如果你有一个好的人力资源部门，也许是HR）。向那个人解释问题是什么，这会让你感到无价值和不尊重。寻求帮助，与您的同事讨论这种情况并同意更好的合作方式。
最后，你需要对你的同事可能做出主观正确的改变的可能性持开放态度，即使他所采取的方式冒犯了你。将正确的编码与正确的人际交互分开。为项目做正确的事。
答案 4 :(得分：3)
如果那个人要维护你的代码，让他做任何他想做的事。 请记住，这不是“你的”代码。该代码属于您所在的公司。你写了代码，你得到了报酬。让管理层做任何他们想做的事。
不要亲自去拿东西，继续前进。
答案 5 :(得分：2)
有时，更改名称可能是合理的。如果项目的一半是指一个人的性，那么你可能会感到困惑，然后你会检查一些引用 gender 或其他内容的新代码。好吧，这可能是一个不好的例子，因为从技术上讲，它们是两个不同的东西，它们的意义很可能仍然很明显。但是，如果项目的代码使用两个不同的术语来引用相同的概念，那么它可能会令人困惑。
通常我会试着单独留下人们的代码，除非我有一些重构的理由。幸运的是，我的同事似乎也是这样，所以不，我还没有必要写这样的章程。
答案 6 :(得分：1)
如何使用自动构建系统，因此当此人更改代码并破坏某些内容时，团队将收到有关它的警报。这解决了你的问题，不得不浪费你的时间修复被别人改变你的代码而破坏的东西。通过这种方式，每个人都会知道某某做出了改变并破坏了构建，并且可以自己看到。规则是“不要破坏构建”。
答案 7 :(得分：1)
你应该以非威胁的方式与做这件事的人讨论这个问题。
答案 8 :(得分：1)
我相信每个开发人员都应该承担责任，因此拥有一些代码，但不是所有的代码。我理解我编写的代码（无论它有多好/多坏）比其他任何曾经见过它的代码都好。因此，我所做的更改将更快，更不容易出错。
我不介意任何人改变我后来写的代码，但我有几个条件：
并非所有开发人员都应该始终对所有代码进行更改。只是在某些时候，为了了解代码（分享知识）。
我从未为一个赞成“每个人都可以随时改变任何事情”政策的雇主工作。开发人员拥有代码的某些部分，并且他们被要求专门根据发展民主进行更改/重构。
你触摸我的代码并破坏了一些东西，（1）你最好有充分的理由让所有开发人员同意这一变化;（2）你最好不要让破碎的东西破碎或者让我去做清理工作除非你是我的上司。如果是这样，我会谦卑地提交。
答案 9 :(得分：0)
我同意Laurence的说法，代码审查可能有所帮助。这是您的团队应该如何协同工作的问题。可能有帮助的是Egoless Programming的概念 - 简而言之，将代码视为团队的联合产品，并试图为代码而不是因为程序员的自我而做出决策。你的队友违反了fourth commandment of egoless programming - “未经咨询就不要重写代码。” 也许如果你的团队了解这些原则，情况会有所改善。我会尝试这个。
答案 10 :(得分：0)
也许不完全是关于主题的，但是....如果你有开发人员有时间对代码进行更改只是因为他们不喜欢使用的变量名，那么也许谈话应该是关于你是否也有许多开发商和哪些应该被展示出来......或者你将如何管理你所拥有的臃肿的员工，特别是在当前的经济环境中！