我们有一位中级开发人员，他擅长做什么，但这块钻石有一个粗糙的边缘。他坚持认为每种方法只有一个入口和一个出口点。处理一些灰色代码风格问题
我正在采取的做法是不要为他写的代码做太大的处理（除非有严重的清晰度问题）。令我困扰的是，他开始重构其他代码，因此它只有一个入口和出口点。这是已经过测试的代码（但并不总是用于自动化测试），因此存在风险。
我是团队中的高级开发人员，所以我有权在代码基础上定义规则。但是，在这里遵循的正确途径是什么？我应该让他继续重构其他代码吗？如果不是，处理这种情况的最佳方式是什么？
总之，不，除非你在编码标准中有明确的规则（你有一个，对吧？）。为了它而改变代码只是要求麻烦（和团队中的紧张）。首先，我会和开发人员讨论这个问题，并举出过去引起重大问题的例子。
此外，这是代码审查可能会有所帮助的一种情况。如果开发人员需要实际发布代码审查，并将此更改明确给团队的其他成员，那么他很可能不会打扰他，或者代码会被同行拒绝。
如果代码评论不可行，那么您可以决定强制执行代码所有权，因为如果您要更改代码库中的内容，您需要咨询模块的主开发人员。
如果你是定义规则的人，并且你认为它没有意义，那么告诉他他没有付费用HIS方式重构代码，而是完成一个项目。
当真实表现不成问题时，允许人们通过其他代码来重新格式化是破坏团队关系的好方法。只有在有强制性理由时才更改其他代码，或者如果组动态对其开放。
询问他是否允许他人在方法上有所不同。如果他做出这样的让步，你可以简单地指出他重构的每一行都可能会出现，并将代码恢复到原来的样子，因为他们的意见不同。因此确保一个我们都知道的巨大的无限循环是不好的！ :)
告诉他一个任务是保持代码更改到最低限度。你不应该改变与当前任务无关的代码。最主要的原因是：
让他浏览代码审查他所做的一切改变和它触及的一切。我不喜欢使用代码审查作为惩罚的想法，但他必须了解他在做什么的深度。
然后，我会让他坐在QA上，向他们解释他如何改变比他需要的更多的功能。他们完成了一段时间的殴打后。然后把他带到项目经理那里，让那个人解释他是如何影响计划的。
如果这样行不通，就揍他直到他哭。
我有点困惑。这是否意味着他在每种方法的所有代码周围放置了一个try {} catch (...){}（或您的语言的等价物）？如果不是，则例外将被视为该方法的替代路径。
而坦白说，这正是他们所设计的要做的。否则，一个简单的退出代码可以达到同样的目的。
如果确实是在窃听人们，那么可能需要经常性地撤销他所做的任何没有任何功能影响的更改。如果你没有陷入被动攻击的行为，那就把它放在他的绩效评估上。听起来可能有些tick，，但我已经有了一些愚蠢的东西。
其他的代码
如果您认为社区代码所有权，没有这样的事情。
灰色的代码风格
在没有社区编码规则的，我会/必须开发自己的编码规则。我不期望别人来做出同样的决定。我会重构我正在努力遵守我的规则的代码，如果我注意到它，并且重构执行起来很便宜。
我个人的规则有两个代价。
“我的时间”
我可以做一些其他的编程任务的进度。如果我没有另外的编程任务，那么我的时间是免费的，这只是一个很好的工作。
“的代码基础振荡”
如果您还有其他重构我的重构，然后有一个社区编码规则显然需要。规则可能如此简单：两种方式都被接受 - 不要重构这种情况。此声明必须明确，否则将无法执行。
这是一个已经过测试（但不总是与自动测试）代码。
啊哈，一个编程任务。这应该被分配。
我以前一直处于这种特殊情况，尽管我认为你的中级程序员可能是个例外，而不是规范 - 问题在于大多数程序员除非必须接触其他代码。
很可能，如果你的中间人正在这样做，那么他之前就会咬他，而且他知道在原则上改变代码可能不是最好的想法。我会提出一个坚定但公开的讨论，讨论他为什么要首先做出这些改变。有机会，如果你清楚而不强硬地陈述你的论点，他会意识到他可能造成的损害。
我会小心的一件事是扼杀这个人编写好代码的热情。他显然是这样做的，因为他认为这会改善你的代码库。就像我说的那样，我认为他的态度是例外而不是常态，并且听到其他人想要主动改进他们的软件令人耳目一新。 （我的确了解与之相关的风险，但听起来像是一些可以通过更多自动化测试大大减少的东西）
希望有所帮助！
既然它困扰着你（你负责），你应该至少跟他谈论它。既然你有一个可以打扰它的坚实理由（它可能会破坏事物），你可能想告诉他不要那么做。奖励点数，如果你能让他真正理解为什么其他人不介意多个进出点，并可能真的喜欢他们。
谁在你的店里开船？有人更好。如果是你，那么就直接跟这个好伙伴一起拍，然后向他解释你的店里是如何运作的。可能没有真正的好处，实质上相当于繁忙的工作。人们可以争论一个方法和一个单一退出的多个退出，但问题是，如果允许他改变他想要的东西，那么在那里你会遇到严重的流程问题。
绝对是一个'人'的问题，可以通过告诉他事情如何快速解决。没有必要是讨厌的，只是诚实。
此外，谁有时间混淆别人的代码？他显然没有被完全分配任务。 :)
你可能想指出，但要小心你如何说。每当你拉上“我是对的，因为我是高级人员”，你就失去了可信度，你将会杀死士气。不要紧，如果你的权利，它不会被认为是这样。
他可能不应该重构/重新格式化没有经过积极测试的代码，但是在同一时间点，如果你对待他就像他不能做任何事情一样，那么他很可能会结束戒烟。最后，这很可能会使公司花费更多的额外qa时间（特别是如果他真的在清理糟糕的代码）。我并不是说你不应该提及他，只是试着从他的角度来看，并让他在你所说的话中半路见你。
我以前曾经有过两次类似的情况。
在第一种情况下，我们有一个人对One True Brace Style的感觉与其他团队不同，他在阅读代码时对其进行了修改。我们中的大多数人要么忽视它，要么放回去。在他的情况下，他太好了，不能让他轻易放弃这么小的事情。没有什么大不了的，只是很烦人。
在第二种情况下，我们有一位工程师在不同的时区远程工作，他的确像鞋匠的精灵。用一堆FIXMEs实现了一半的东西神奇地完成和美丽。在他的情况下，他显然使事情变得更好，并且只对他所分配的东西起作用，所以对我们来说没问题。
在你的情况，这不是他的分配，这样就可以
这样的事情是不可接受的。如果没有设置编码标准/风格/布局，那么程序员应该模仿现有的代码和风格，避免重构任何东西。
如果此程序员有时间重构所有内容，那么显然他/他需要分配更多工作。
另外，这里有一个关于“单一出口点”理论的讨论：http://stackoverflow.com/questions/36707/should-a-function-have-only-one-return-statement#36839 – 2008-10-20 18:06:40