1996年6月24日，欧洲航天局的无人驾驶阿丽亚娜5号火箭在发射后仅37秒就爆炸了。3.7亿元的投资和十几年的心血瞬间化为泡影。为什么？一个简单的软件错误。它试图将可以表示数十亿个潜在值的64位浮点变量存储为只能表示65535个潜在值的16位整数。也就是说，为了让火箭进入太空，需要分配更多的存储空间。这告诉我们，小错误后果严重，潜在危险最大，为此付出的代价也最大。大象不咬人，它们只是想和你做朋友当编程出错时，几乎所有明显的错误都会出现在代码中。这些错误会导致明显的编译器或运行时错误，这些错误会在用户界面或编译器中显现出来。开发人员很清楚这些问题需要立即修复，因此这些错误几乎不用担心。最有可能的是，开发人员会在发现错误后立即修复错误，从不承诺半成品或编写不符合预期目标的代码。大象不咬人，因为它们很容易被凭直觉驯服。从长远来看，他们不会造成任何麻烦，也不会造成任何伤害（除非被命令这样做）。他们很容易辨认，通常会说：“看着我！跟着我，我会向你展示我的爱，你不会后悔的。”蚊子会成群结队地咬你，给你带来莱姆病，甚至杀死你的大象的反面是蚊子——看似微不足道、不明显的代码部分，作为隐藏数据隐藏在看似有效代码的次要位置。他们随时准备攻击和破坏代码。由此产生的错误包括：逻辑错误、设计问题、混乱的代码和有缺陷的非优化算法。阿丽亚娜5号发射的问题在于研究人员复制了之前成功发射的阿丽亚娜4号的工作代码。研究人员显然认为这些代码也适用于阿丽亚娜5号，但这些代码不符合阿丽亚娜5号火箭的环境需求，无法应对新环境。图片来源：unsplash最小的错误导致最大的问题逻辑错误会导致产品处理问题和产品信息显示问题，影响预期功能，并影响用户体验。即使开发人员没有发现任何与应用程序工作方式相关或立即可识别的问题，也可能会导致用户流失。设计不当会导致阿丽亚娜5号火箭爆炸等问题。这种设计下的代码可以在低计算环境下工作，但不能在高计算环境下工作。忽略相关事项会导致系统故障，因为系统不是为处理大规模操作而设计的。此类问题通常出现在旨在尽可能对系统施加压力的精心编写的测试代码中，但如果不编写测试来处理这些情况，则可能会发生令人震惊的黑天鹅事件，从而导致严重的后果。混乱的代码使识别代码中的错误和问题变得更加困难。最重要的是，随着代码变得更难以扩展和修改，开发成本会急剧增加。这使得代码更容易出现常见错误。当出现乱码时，应立即提高警惕，进行代码重构。在计算密集型情况下，未优化的算法会影响性能。特别是对于不习惯重构代码以更好地执行算法的程序员来说，这个细节很容易被忽略。当遇到长时间加载、超时或节流时（尤其是使用云后端时），通常会注意到此细节。有些代码单独运行良好，但在编程时，要意识到仅仅因为它自己运行良好并不意味着它可以与大型数据集和其他组件一起运行。如果忽略这些小问题，结果将是惊人的。好消息是，有一些方法可以减少和最小化这些错误的影响。使用驱虫剂！不注意小问题最终会导致最大的问题。在某种程度上，阿丽亚娜5号的程序员值得同情。但是像这样的事件说明了在广泛的压力测试和测试驱动开发的支持下仔细编写代码的重要性。编程不仅仅是编写有效的代码，它还需要仔细和周到的思考：代码不是乱七八糟的，许多程序员，无论新老，都只是将代码拼凑在一起，就像试图将圆柱体放入方孔中一样。虽然列可以适合，但它没有意义，而且在任何情况下都不安全。来源：unsplash因此，在编写代码时最好牢记这些问题：代码是否太复杂？如何简化？是否为代码编写了严格的测试类，这些测试类具有强大的断言和测试功能，以应对多种不同的数据饱和和高计算场景？代码的局限性是否被理解？是不是功能太少了？大函数的方法可以应用到小函数吗？变量、类和函数的名称是否清晰明确？光看名字就清楚代码的作用了吗？是否有太多重复的方法可以在许多不同的流程中重用并具有共同的功能？复制方法是否绝对必要？有不同的功能情况吗？如何处理错误？是否使用try-catch块抛出错误，并对变量运行null检查？是否有特定的流程来确保在发现错误时功能顺畅？代码是否易于扩展和扩展？如果进行了修改，我是否需要担心任何依赖性？代码是否能够优化以处理大量数据？代码在压力下运行时是否会抛出错误或超时？当然，还有很多问题要问自己，足以让assembly列出一个详尽的清单，上面的问题可能是最重要的，但不够重视。通过限制未知错误的可能性来降低代码中出现任何错误的风险，让不确定的事情为人所知，而不是先观察再知道。这些大错误不应该是一个长期的问题，因为大错误很容易纠正和修复。小的、日常的错误和不一致才是真正的问题。
