你可以故意制造错误吗？

我们，开发人员，经常遇到错误，这只是我们工作的一部分。因此，乍一看，“你能故意制造一个错误吗？”这个问题。可能看起来很平庸——“是的，当然，我可以写一个错误。”然而，如果你仔细想想，一切似乎都不再那么明显了。

事实上，错误与损坏的代码不同。 bug 是一个错误，通常是一个缺陷

工作计划。

有什么问题？

众所周知，世界可以通过数学公式很好地描述。公式实际上就是算法。因此，如果我们能够用数学方法描述某些现象，那么纠正所得公式以使其仅有时给出错误结果是一项艰巨的任务。尽管如此，现在还不到绝望的时候。边界条件可能会在这里帮助我们。我们都见过这些if index == 0 {…} else if index == n-1 {…} 。界限总是有问题🤷‍♀️。因此，让我们注意创建错误的第一个想法 -忽略边缘情况。

一般来说，遍历数组是潜在错误的宝库。其中最常见的是索引越界。如果你从未偶然发现过这样的事情，那么你就从未编码过。不幸的是，这个错误非常流行，以至于人们开始为数组编写安全包装器，例如array[safe: index] 。所以今天，如果没有这个东西，你的同事几乎不会批准任何代码。你可以尝试一下，但可能性不大……

常见的错误包括堆栈溢出。当没有退出条件时，递归算法可以无限递归。递归在这里似乎是可选的 - 写while true ，然后就完成了。然而，该错误的流行再次对我们不利。开发人员很清楚无限循环的潜在问题，他们的眼睛肯定会在代码审查时注意到这样的事情👮

为了仍然将你的阴险计划投入生产，请尝试使用全局变量作为退出条件，并从外部悄悄地更改它。

 var coditionCounter = 0; class A { func foo() { while coditionCounter < 10 { coditionCounter++; B.boo(); } } } class B { func boo() { coditionCounter--; } }

一般建议

有趣的是，即使是 ChatGPT 在编写错误时也拒绝提供帮助。也许我只需要高级订阅......🤔

好的一面是，人工智能提供了一套有助于编写无错误代码的通用规则：以小增量进行代码、遵循编码标准、编写单元测试以及等等。我们可以尝试做相反的事情 - 编写意大利面条式代码并忘记 SOLID。然而，这样一来，我们就失去了对我们编写的所有代码的控制。我们得到的不是优雅的精确武器，而是难以控制的混乱，这将征服我们的程序。

在解决创建错误的问题时，值得确定子任务。首先，我们需要提出一些罕见的边缘情况。其次，我们需要将错误伪装成常规代码，以便通过代码审查。第三，我们必须削弱QA部门的注意力。第四，不要立即被抓住。但这已经是可选的。

我的一般建议如下（您可以在评论中分享您的建议）：

• 操纵访问级别。要返回，请从最意想不到的地方更改重要参数的值。通过几个类来完成此操作，就像您是 VPN 一样。

• 在子类中实现一些意想不到的逻辑。简而言之，打破了 SOLID 中的 L 原则。

   class A { func decrease() { x--; } } class B: A { override func decrease() { x++; } }

• 将你的隐秘变化隐藏在更大的函数中。队伍越多越好- 迷失在人群中。

• 在拉取请求中使用相同的原则。在小PR中，被注意到的概率更高。

• 尝试将错误分解为多个部分并将它们放入不同的拉取请求中。如果可能的话，也给不同的审稿人。

• 找出 QA 的弱点并赢得他的信任。或者在检查期间通过谈话来分散他们的注意力。

顺便问一下，你听说过Heisenbug吗？这是一个在研究/调试过程中消失或改变其行为的错误。就像薛定谔的猫一样。如果修复问题不会分配给您，那就完美了。

你可以

相信你自己！历史上有一些非常严肃的公司在生产中承认错误的例子。

阿丽亚娜 5 号航班 501：最昂贵的软件错误之一发生在 1996 年，当时执行 Cluster 任务的阿丽亚娜 5 号火箭在升空后仅 40 秒就爆炸了。此次故障可追溯到火箭制导系统中的软件错误。

NASA 的火星气候轨道器： 1999 年，NASA 由于软件错误丢失了火星气候轨道器。该软件使用英制单位（磅秒）而不是公制单位（牛顿秒），导致航天器在火星大气层中燃烧。

此外，有些错误可能会成为功能，例如《马里奥》中的跳墙或《文明》中圣雄甘地的行为……可能。

开发错误是思考算法并彻底预测可能出现问题的能力。因此，即使您没有理由在代码中留下错误，它仍然值得考虑。