Coding style 处理一些灰色代码样式的问题

我们有一个中级开发人员，他非常擅长他的工作，但这颗钻石有一个粗糙的边缘。他坚持认为每个方法只有一个入口和一个出口

我采取的方法是，对于他编写的代码，不要把它做得太大（除非存在严重的清晰度问题）。让我烦恼的是，他开始重构别人的代码，使之只有一个入口和出口。这是已经测试过的代码（但不总是使用自动测试），因此存在风险

---

我是团队中的一名高级开发人员，因此我有权在代码库中定义规则。但在这里，正确的道路是什么？我应该让他继续像这样重构别人的代码吗？如果不是，那么最好的解决方法是什么？

如果你是定义规则的人，你认为这没有意义，只要告诉他，他不是按照自己的方式重构代码，而是为了完成一个项目而获得报酬。

允许人们浏览其他代码，只是为了在实际性能不成问题的情况下重新格式化，这是破坏团队关系的好方法。只有在有令人信服的理由时，或者如果团队对其非常开放，才可以更改其他人的代码。

简而言之，不可以，除非您的编码标准中有明确的规则（您有，对吗？）。为了代码而更改代码只是自找麻烦（以及团队中的紧张气氛）

首先，我将与开发人员讨论这一点，并给出过去导致重大问题的此类更改的示例

此外，这是一种代码审查可能会有所帮助的情况。如果开发人员确实需要发布代码审查，并向团队其他成员明确说明此更改，那么他很可能不会费心，或者代码会被他的同事拒绝

---

如果不可能进行代码审查，您可以决定强制执行代码所有权，即如果要更改代码库中的内容，您需要咨询模块的主要开发人员

询问他是否允许其他人在方法上有所不同。如果他做出了让步，你可以简单地指出，对于他重构的每一行，可能会有人出现，并将代码还原回原样，因为他们的意见不同。从而确保了一个我们都知道是坏的巨大无限循环

告诉他，任务是将代码更改保持在最低限度。您不应该更改与手头任务无关的代码。主要原因是：

为了降低风险--“嘿，如果有什么东西坏了，是你负责。”

审阅代码会更快，因为它允许审阅者只关注实际添加/更改的代码

---

让他对所有他更改的内容和涉及的内容进行代码审查。我不喜欢使用代码审查作为惩罚的想法，但他必须理解他所做的事情的深度

然后我会让他和QA坐在一起，向他们解释他是如何改变了远远超过他需要的功能的。在他们打了他一段时间之后。然后带他去见项目经理，让那个人解释他是如何影响进度的

---

如果不行，就揍他直到他哭。

我有点糊涂了。这是否意味着他在每个方法中的所有代码周围都放置了一个

try{}catch（…）{}

（或您的语言的等价物）？如果不是，则异常将被视为方法之外的备用路径

坦率地说，这正是他们设计的目的。否则，一个简单的退出代码也可以达到同样的目的

如果这真的让人们感到困扰，那么他所做的任何没有任何功能影响的改变都值得例行地放弃。如果你没有消极的攻击行为，把它写在他的绩效考核上。这听起来可能有点不太对劲，但我已经把更愚蠢的东西放在我的衣服上了

他人代码

如果您相信社区代码所有权，那么就不存在这样的事情

灰色代码样式

如果没有社区编码规则，我将/必须制定自己的编码规则。我不期望其他人做出同样的决定。如果我注意到这一点，并且重构成本低，我将重构我正在处理的代码以符合我的规则

---

我的个人规则有两个代价

“我的时间”

我可能会在其他编程任务上取得进展。如果我没有其他的编程任务，那么我的时间是空闲的，这是一项很好的工作

“代码基振荡”

如果其他人正在重构我的重构，那么显然需要一个社区编码规则。规则可以很简单：两种方式都可以接受——不要重构这个场景。该声明必须明确，否则将无法执行

---

这是已经测试过的代码（但不总是使用自动测试）

---

啊哈，一个编程任务。这应该得到分配。

我以前就遇到过这种情况，尽管我认为你的中间程序员可能是个例外，而不是正常情况——问题是大多数程序员不会接触其他代码，除非他们不得不这样做

很有可能，如果你的中间人正在这样做，它以前咬过他，他知道原则上更改代码可能不是最好的主意。我建议进行一次坚定但公开的讨论，首先讨论他为什么要做出这些改变。机会是，如果你清楚但不有力地陈述你的论点，他会意识到他可能造成的伤害

我要小心的一件事是扼杀这家伙编写好代码的热情。他这么做显然是因为他认为这会改善你的代码库。正如我所说，我认为他的态度是个例外，而不是常态，听到其他人希望积极改进他们的软件，这让人耳目一新