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

我们有一个中间开发人员,他非常擅长他的工作,但这个钻石有一个粗略的优势.他确实坚持每个方法只有一个入口和一个出口点.

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

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

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

首先,我将与开发人员讨论这个问题,并列出过去导致重大问题的此类变更示例.

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

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

当真正的性能不是问题时,允许人们通过其他代码来重新格式化是破坏团队关系的好方法.只有在有令人信服的理由这样做时,或者如果组动态非常开放,则只更改其他代码.