mbrfix修复拒绝访问

当某些东西无法按预期工作时，存在一个错误。 漏洞修复基本上是对现有代码库的补丁（拉取请求），旨在解决问题并确保“某些操作”按预期工作。 通常，这样的修补程序可以修复一件事，但会破坏许多其他问题。 我认为有时候为了保护项目免受更大的问题，有必要拒绝一个错误修复程序，并要求其作者重新做补丁。 根据我的经验，有一些正当的理由会拒绝这样的邮件。

艾尔·克里米亚（El Crimen Perfecto）（2004）

它会降低代码覆盖率

这是一种非常普遍的情况：在一个地方进行更改后，单元测试在另一个地方失败。 该错误已修复，但是一些可能不相关的单元测试开始报告失败。 在压力下或仅仅因为我们很懒，我们没有解决它们； 我们只是删除测试或将其标记为暂时“跳过”。 问题解决了，构建很干净，所以让我们合并补丁并称之为“天”吧？ 错误！

即使我赞成尽可能多地偷工减料 ，但我不建议您切掉这个拐角。

正是在这里进行了单元测试，以防止我们在压力下损坏产品。

显然，在某些情况下，单元测试是错误的，因此我们必须删除它们。 在这种情况下，不要忘记创建新的。

在某些情况下，必须在几分钟内修复该错误以使系统恢复在线状态，并且修复所有单元测试将花费一个小时。 这种情况是有力的信号，表明您的产品已经覆盖了测试范围，因此情况非常糟糕。 毫无疑问，我们必须进行修复，并要求我们的测试关闭一段时间。 但是在这种情况下，请确保在发布错误修复后，您的团队正在处理的下一个任务是更正那些禁用的单元测试。 我建议阅读Michael Feathers 撰写的《有效处理旧版代码》 ，其中涉及到这个主题。

它不会重现问题

有时，整个系统可能仅由于一行代码中的拼写错误而停机。 一个明显的错误修复是删除错字，但是如果我们关心它的质量，那不是我们期望的一个好项目。 问题不是拼写错误，而是缺少在部署阶段会捕获拼写错误的单元测试。

真正的问题是在代码的此特定部分中缺少测试代码的覆盖范围。 通过消除错字，我们不会以任何方式帮助该项目。 此外，我们正在这样做，这对我们是有害的-我们正在隐藏真正的问题。

因此，无论问题的大小如何，其错误修复都必须包含一个额外的测试，该测试首先会重现该错误。 如果没有这样的测试，则错误修复将浪费项目的资金。

此外，如果没有单元测试重现该问题，则不能保证我们的错误修复不会引入更多的错误。 我什至要说，我们修复的错误越多， 熵就越高。 减少这种不确定性的唯一方法是使用单元测试覆盖代码。 如果不进行测试，则错误修复会给代码库带来更多混乱。

太大了

错误修复不是功能 ; 他们必须小而专注。 对于程序员而言，这是一个非常典型的错误，它在修正错误时会发疯，并在修正时引入一些重构。 结果是补丁变得相当大且难以理解。 我不反对重构。 对于项目而言，这是非常重要且积极的事情，但是在修复并合并错误之后 ，请分开进行 。

修复错误时无需重构！

创建一个新的单元测试，重现该错误，然后提交。 修复现有代码库中的错误，无论它多么难看。 创建新的错误，要求团队使用丑陋的代码库改善情况。 如果有兴趣，请将这些错误分配给自己。 也许其他人可能会对修复它们和重构代码感兴趣。 但是所有这些将在以后的其他请求中通过新的代码审查和新的合并发生。

这不是关于懒惰和不愿修复看起来不好的东西。 这是一门学科，这比善意更重要 。

它解决了一个以上的问题

始终一次解决一个问题-就这么简单。 没有例外。 当错误修复补丁包含可解决多个问题的代码更改时，很难理解要测试的问题，重现的问题以及它们之间的关系。 将多个错误修复程序组合到一个请求请求中是非常糟糕的做法。

无论修补程序多么简单，都应使其独立于其他程序。 分别检查，测试和合并。 这还将增加更改的可追溯性。 总是很容易理解是谁进行了修复，谁审查了代码以及何时合并（和部署）了代码。

翻译自: https://www.javacodegeeks.com/2015/07/a-few-valid-reasons-to-reject-a-bug-fix.html

mbrfix修复拒绝访问