优秀的软件开发工程师都会关注什么问题？发布软件时要避免这5件事

软件失败的代价可以通过不同的方式感受到。例如，在一家上市公司的股票价格上，或者在一家小公司，它可能意味着破产。

我经常看到一些组织发布软件的方式就像玩俄罗斯轮盘赌一样——拿客户的安全、私人数据和安全性做赌注，更不用说可靠性了。他们也在拿自己公司的声誉和底线做赌注。IEEE在几年前发布了一份优秀的公共故障列表，你可以肯定软件仍然在失败。

我喜欢这个有点可怕的比喻的原因是，我经常听到人们说：“那个软件已经出来很久了，没有出现过问题”或者“我们一直都是这样做的，而且行之有效”——但这仍然是一种糟糕的计划方式。一家专注于软件工程的公司正在寻找构建和发布更好的软件，减少失败的方法。这就意味着主动规划，通过做正确的事情来获得成功，即使做错的事情到目前为止已经成功了。

哈佛大学的研究人员发现，类似于二分之一的IT软件项目都会失败。别人的数字很多，这个估计并不是最高的，我们先来看看。这就像玩俄罗斯轮盘赌，枪膛里有3颗子弹——50-50的失败几率。我不喜欢这种几率，当然也不会把我公司的未来赌在上面。

让我们看看人们每天在发布软件时进行的一些讨厌的赌博。如果你愿意的话，他们轮盘赌枪里的子弹。

1. 已知的老BUG

我们都知道，我们发布的软件会有bug，因为无懈可击的软件要花上一辈子的时间来制作。但这并不是我们永远不修复我们所知道的错误的借口。关于技术债务已经用非常抽象的术语说了很多，但这是衡量你的软件中债务的一个真正实用的标准。如果那里有一个bug，而你却不去修复它，你最好有一个很好的理由来解释为什么你认为它不重要。每一个版本都要计划一些时间，不仅仅是增加新的功能，而且要普遍地把事情做得更好。花时间打磨你的软件。

2. 旧代码中的新错误

旧代码是很棘手的。我见过一些公司的政策是“无论如何都要把它清理掉”，还有一些公司的规则是“只碰必须碰的东西，而且只在有现场报告的bug时才碰”。这两种政策都很有趣，但最重要的是要明白当你在旧代码中发现一个新的bug时，其中的风险。我曾与一家硬件厂商合作，他们正在为如何处理新工具在一些旧代码上的输出而苦恼。在他们的案例中，这是一个模棱两可的范围问题，这让我至今还在想他们的编译器怎么会允许这样的疯狂。他们碰到了一个冲突——一方面他们有这个新工具，另一方面他们不应该碰旧的代码，除非有来自现场的错误报告。

了解你计划对你的遗留代码做什么是很重要的，同时也要充分了解它对组织的风险。如果代码是关键性的，年限可能没有你想象的那么重要。如果代码正在被废弃，也许你正在浪费时间测试你不打算修复的东西。

3. 将安全作为测试的一部分，而不是开发的一部分

对于组织来说，忽视安全问题是一件令人沮丧的事情。在某些情况下，他们认为他们可以在应用程序中测试安全（他们不能），而在其他情况下，他们认为安全问题不会适用于他们的代码（他们会）。为了摆脱这种不断发生安全故障的混乱局面，组织必须用坚实的AppSec最佳实践来硬化代码，正如编入静态分析工具中一样，它不仅仅是进行流程分析。如果你不知道从哪里开始，老实说，从今天开始，简单地把MISRA规则拿出来，并开始在你写的任何代码中遵循它们，也不会有什么影响。

4. 永远失败、永远通过的测试套件

我看到的一个极其常见且危险的做法是，拥有一个庞大的测试套件，并依赖一个简单的测试通过数的指标。例如，你通常有80%的通过率，所以你认为这将是好的。问题是没有办法知道今天通过的80%和昨天通过的80%是否一样。很容易有一个新的真正的失败隐藏在那80%中（有），因为有其他的东西被修复了，使得数字平衡。保持你的测试套件的干净，否则它不会告诉你什么。我会认真地质疑一个你觉得可以忽略的测试失败的价值。为什么不直接跳过那个测试——这是一个更诚实和有用的方法。

5. 在日历上发布

可能最常见的关键发布标准还是日历。人们选择了一个日期，现在他们要发布了，因为那个日期到了。诚然，有一些外部问题会影响你的发布时间表，但仅仅因为一个日期到了，并不意味着就可以把糟糕的软件推给你毫无戒心的即将成为你的合作伙伴的客户。当它准备好/安全/稳定/好的时候再发布。如果日历是一个固定的约束，请确保你的过程会让你准时到达。

总而言之......

在付出代价之前，你能这样释放多少次？用我们的俄罗斯轮盘赌来比喻，最多六次，也或许只有一次。让我们尽最大的努力，确保我们要提供最好的软件，有最好的成功机会。