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

Question

我们有一位中级开发人员，他非常擅长自己的工作，但这颗钻石有一个粗略的优势。他真的坚持每个方法只有一个入口和一个出口点。

我采取的方法是不要为他编写的代码做出太大的交易（除非存在严重的清晰度问题）。困扰我的是他开始重构其他代码，以便它只有一个入口和出口点。这是已经过测试的代码（但并不总是使用自动化测试），因此存在风险。

我是团队中的高级开发人员，因此我有权根据代码库来定义规则。但是这里要遵循的正确道路是什么？我应该让他继续重构像这样的其他代码吗？如果没有，接近这种情况的最佳方法是什么？

Answer 1

简而言之，不，除非你在编码标准中有明确的规则（你有一个，对吧？）。为了它而改变代码只是在寻找麻烦（以及团队中的紧张局势）。

首先，我将与开发人员讨论这个问题，并提出过去导致重大问题的变化示例。

此外，这是代码审查可能有所帮助的一种情况。如果该开发人员需要实际发布代码审查并将此更改明确告知团队的其他成员，则他可能不会打扰，或者代码将被他的同行拒绝。

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

Answer 2

当真正的表现不成问题时，允许人们通过其他代码来重新格式化是破坏团队关系的好方法。只有在有令人信服的理由时才更改其他代码，或者如果群组动态非常开放。

Answer 3

如果您是定义规则的人并且您认为它没有意义，那就告诉他，他没有按照HIS的方式重构代码，而是完成一个项目。

Answer 4

我以前曾两次遇到类似情况。

在第一种情况下，我们有一个人对One True Brace风格的感觉与团队的其他人不同，他在阅读代码时改变了它。我们大多数人要么忽略它，要么把它放回去。在他的情况下，他太好了，不能给他一些如此轻微的东西。不是很大，只是讨厌。

在第二种情况下，我们有一位工程师在不同的时区远程工作，他就像鞋匠的精灵一样。用一堆FIXME实现了一半的东西神奇地完成了并且很漂亮。在他的情况下，他可以让事情变得更好，也只是对他所分配的事情起作用，所以对我们来说很好。

在你的情况下，这不是他所分配的工作，所以你可以

• 请他不要这样做：这不是他的任务
• 告诉他不要重构不是他的代码（即，保留其他人的代码相同）
• 要求他安排任务，包括为他希望在实际输入范围内更改的每个例程/方法创建基线单元测试，并验证重构代码的输出。你可以告诉他你正试图让它变得难以接受，因为修复他所引入的错误的成本肯定不会超过重构的时间，他宁愿做出核心功能吗？

Answer 5

这样的事情是不可接受的。如果没有设置编码标准/样式/布局，那么程序员应该模仿现有的代码和样式，不要重构任何东西。

如果这个程序员有时间重构一切，那么很明显他/她需要分配更多的工作。

Answer 6

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

1. 降低风险 - “嘿，如果有什么事情发生，那就是你的责任。”
2. 检查代码会更快，因为它允许审阅者专注于实际添加/更改的代码。

Answer 7

谁在你的商店开船？有人会更好。如果是你，那就直接和这位优秀的家伙一起拍摄并向他解释你店里的工作原理。对于基本上等于繁忙工作的东西来说，可能没有真正的好处。人们可以争论一个方法与单个退出的多个退出，但重点是，如果允许他改变他想要的东西，那么你就会遇到一个严重的流程问题。

绝对是一个'人'问题，可以通过告诉他工作原理来快速解决。不需要讨厌，说实话。

此外，谁有时间搞乱其他人的代码？他显然没有完全的任务。 ：）

Answer 8

让他为他所做的一切以及所涉及的一切进行代码审查。我不喜欢使用代码审查作为惩罚的想法，但他必须了解他正在做的事情的深度。

然后我会让他和QA坐在一起并向他们解释他是如何改变他所需要的更多功能的。他们完成了对他的殴打一段时间后。然后带他去项目经理，让那个人解释他是如何影响时间表的。

如果这不起作用，请打他，直到他哭泣。

Answer 9

你可能想指出它，但要小心你的用语。每次你拉“我是对的，因为我是老人”，你就会失去信誉，而你会打击士气。如果你的权利无关紧要，就不会被这种方式所感知。

他可能不应该重构/重新格式化未经过主动测试的代码，但在同一时间点，如果你对待他就好像他做不了什么事，那么很可能他最终会结束狭路相逢。最后，这很可能会使公司花费超过少量额外的qa时间（特别是如果他真的要清理坏代码）。我并不是说你不应该向他提起它只是试着看看他是否从他的观点出发让他在你所说的话的一半见到你。

Answer 10

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

Answer 11

我有点困惑。这是否意味着他在每种方法的所有代码周围放置try {} catch (...){}（或您的语言等价）？如果没有，则异常将被视为该方法的替代路径。

坦率地说，这就是设计要做的事情。否则，简单的退出代码将起到同样的作用。

如果它确实是人们的烦恼，那么可能需要定期退出他所做的任何没有任何功能影响的变化。如果你没有进入被动攻击行为，那就把它放在他的绩效评估上。这可能听起来有点俗气，但我已经把更多的东西放在我的身上了。

Answer 12

  

其他代码

如果你相信社区代码所有权，就没有这样的东西。

  

格雷码风格

如果没有社区编码规则，我将/必须制定自己的编码规则。我不希望其他人做出同样的决定。我将重构我正在努力遵守我的规则的代码，如果我注意到它并且重构是否便宜。

---

我的个人规则有两个成本。

“我的时间”

我可以在其他一些编程任务上取得进展。如果我没有其他编程任务，那么我的时间是免费的，这只是一项很好的工作。

“代码库振荡”

如果其他人正在重构我的重构，那么显然需要社区编码规则。规则可以很简单：两种方式都被接受 - 不要重构这种情况。该陈述必须明确提出，否则将无法执行。

---

  

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

Aha，编程任务。这应该被分配。

Answer 13

我之前一直处于这种特殊情况，虽然我认为你的中级程序员可能是例外，而不是常态 - 问题是大多数程序员除非必须接触其他代码，否则不会触及。

如果你的中级人员这样做，可能会被他咬过，而且他知道在原则上改变代码可能不是最好的主意。我建议一个坚定但公开的讨论，讨论为什么他首先要做出这些改变。如果你清楚但无力地提出你的论点，他很可能会意识到他可能造成的不利。

我要小心的一件事是扼杀了这个人写好代码的热情。他显然是这样做的，因为他认为这会改善你的代码库。就像我说的那样，我认为他的态度是例外，而不是常态，听到其他想要积极改进软件的人的态度令人耳目一新。 （我确实理解与之相关的风险，但听起来可以通过一些更自动化的测试来大大减少）

希望有所帮助！

Answer 14

因为它困扰你（而且你负责），你应该至少与他谈论它。既然你有充分的理由被它打扰（它可能会破坏事情），你可能想告诉他不要这样做。如果你能让他真正理解为什么其他人不介意多个进入/退出点，并且可能真的喜欢它们，那么奖励积分。