通过代码审查调和童子军规则和机会主义重构
我坚信童子军规则： 始终要比在检出时检查模块中的清洁剂。”不管原始作者是谁，如果我们总是花点力气，不管大小如何，以改进模块。结果是什么？我想所有人都遵循这个简单的规则，我们将会看到软件系统不断恶化的终结，相反，随着系统的发展，我们的系统将逐渐变得越来越好。我们还将看到团队关心整个系统，而不是整个系统。不仅仅是个人照顾自己的一小部分。 我也是机会重构相关思想的坚定信奉者： 尽管在某些地方可以进行一些计划内的重构工作，但我还是鼓励将重构作为一种机会主义活动，它需要在任何时候，任何地方需要清理代码的人（无论谁）进行。这意味着在任何时候，只要有人看到一些不尽如人意的代码，他们都应趁此机会立即将其修复，或者至少在几分钟内 特别注意以下来自重构文章的摘录： 我对任何可能导致机会重构产生冲突的开发实践都保持警惕。我的感觉是，大多数团队都没有进行足够的重构，因此，请注意任何阻碍人们进行重构的事情，这一点很重要。为了避免这种情况的发生，请注意任何时候您都不愿意进行小规模的重构，您肯定只需要一两分钟。任何此类障碍都是应该引起对话的气味。因此，请记下该挫折并与团队联系。至少应该在下一次回顾中讨论它。 在我工作的地方，有一种开发实践会引起严重的摩擦-代码审查（CR）。每当我更改不在“任务”范围内的任何内容时，我的审核员都会对我感到bu异，因为我正在使更改难以审核。当涉及到重构时，尤其如此，因为这使得“逐行”差异比较变得困难。这种方法是这里的标准，这意味着很少进行机会性重构，并且只会进行“计划的”重构（通常太少，太晚）。 我声称这样做的好处是值得的，并且3名审阅者会更加努力（实际上要前后理解代码，而不是仅仅关注变更范围的狭窄范围，因此，审阅本身会更好一些） ），以便接下来的100个阅读和维护代码的开发人员将受益。当我向审阅者提出这个论点时，他们说只要我不在同一CR中，他们的重构就不会有问题。但是我声称这是一个神话： （1）大多数时候，您只有在从事作业时才意识到要重构的内容和方式。正如马丁·福勒（Martin Fowler）所说： 在添加功能时，您意识到要添加的某些代码与某些现有代码包含某些重复项，因此您需要重构现有代码以清理问题……您可能会工作，但意识到如果更改了与现有类的交互，则更好。在您认为自己已完成之前，抓住这个机会。 （2）没有人会喜欢您发布您不应该做的“重构” CR。CR有一定的开销，您的经理不希望您在重构上“浪费时间”。当它与您应做的更改捆绑在一起时，此问题被最小化。 Resharper加剧了这个问题，因为我添加到更改中的每个新文件（而且我事先无法确切知道哪些文件最终会更改），通常充满错误和建议-其中大多数都是应有的且应有的定影。 最终结果是我看到了可怕的代码，然后就把它留在那里了。具有讽刺意味的是，我觉得修复这样的代码不仅不会提高我的声誉，而且实际上降低了我的声誉，并将我描绘成一个“无专心的”家伙，他浪费时间去修复那些没人关心的事情而不是去干他的工作。我对此感到难过，因为我确实鄙视错误的代码，无法忍受观看，更不用说从我的方法中调用它了！ 关于如何纠正这种情况有什么想法？