好的，我知道这是一个愚蠢的问题，所以让我澄清一下。
我的老板认为，“到现在为止，凭借你的知识水平，你的软件中永远不会有错误”。虽然它可能是正确的，但如果使用正确的工具和适当的方法，那些永远不会被允许给我，也许是因为我不知道该怎么回答他（我是这里唯一的开发人员，所以我不喜欢什么时候有人可以转向它。）
所以，这是我的问题：您使用哪些工具和方法来减少软件中的错误？
底线：没有任何错误的代码是不可能的。但是，这是可以做的：
（经常被遗忘，但可能。很少有程序员真正使用它）
答案 0 :(得分：17)
一些想法：
我想重新强化其他人所说的关于编写无错误代码的内容 - 这是不可能的。但是，使用上述部分或全部技术至少应该有助于减少你的错误。
显然，甚至可能最重要的是，在部署/发货之前，您应该让某人测试您的软件（即不仅仅是自动化测试）。
答案 1 :(得分：6)
首先：无错软件是一个神话！
其次，工具本身取决于很多东西，但是如果你想让事情尽可能保持一般：
答案 2 :(得分：4)
对我而言，你的老板认为你必须编写无错误的代码，就像你认为你必须拥有无限的薪水一样。在“无错误”中添加“几乎”这个词并不会改变其含义。
有无错误的代码。具有0功能的代码是无错误的。但这没用。
编写计算机程序与下棋非常相似。 Tigran Petrosian是一位以其强大的防守技术而闻名的世界象棋冠军，曾经被一位不太礼貌的记者问到，为什么他有时会犯错误。答案非常简单：“因为下棋并不容易。尝试自己玩，你会看到。”
当然，只有当你的老板是一个聪明的人并且能够做到正确时，我才建议使用这个例子作为理由。否则，寻找另一份工作可能会更好。
答案 3 :(得分：3)
你真的需要把它带到你老板的头脑中，几乎不可能编写任何复杂的软件而没有错误。
只要您接受编写无错误代码是一项不可能完成的任务，您就可以开始关注实际重要的事项：使您的所有错误都易于检测
单元测试是一种很好的方法，并且随着时间的推移你会发现很多小技巧可以帮助你避免它们，虽然真的只有经验，并且知道什么样的错误< em>你很可能会。
经常引用（可能现在不相关）的例子是颠倒你的比较顺序，例如：
"bar" == foo
而不是
foo == "bar"
因此，当您打算进行比较（foo = "bar"）时，您最终不会完成作业（foo == "bar"）。如果颠倒顺序，那么错误情况（"bar" = foo）是一个容易检测到的语法错误，而不是一个难以找到的逻辑错误。但是，如果这是你经常犯的那种错误，那真的很有用。
答案 4 :(得分：2)
你的老板可以给你无差错和完整的规格，从完成它们到完成软件的那一刻都没有变化吗？当我说完成时，我不只是指一系列功能。如何处理所有功能之间的所有交互，每个可能的用户输入的行为的所有预期，环境的每个可能的条件（例如，OS，存在的文件，运行的其他应用程序，对共享资源的访问，字体大小，配色方案，键盘布局），哪些进程优先于其他进程，时间到毫秒等。
答案 5 :(得分：1)
TL; DR使用形式验证或任何形式的静态检查！
实际上，有一种方法可以使99.999％的错误免除。但是您需要完全改变编程方式。完全放弃所有测试！而是使用正式验证。您首先应该熟悉Curry-Howard函式和lambda演算。然后学习依赖类型：
或一些正式的检查器：
有些项目实际上是“无错误的”。看看：
如果您的老板希望您拥有无错误的代码，请告诉他，正式验证是您可以到达那里的唯一方法，但是制作经过验证的软件的成本是您要花费数月的时间来添加所有琐碎的功能。但这并非不可能。对于99％的软件来说，这只是不切实际的。
答案 6 :(得分：1)
也许你的老板不熟悉人为错误。话虽如此，使用单元测试，持续集成和静态代码分析等实践可以提高代码质量并减少某些类型的错误。
答案 7 :(得分：1)
Test Driven Development是一个好的开始，但这还不够。良好的实践，配对代码审查和编程，高度关注以及优秀测试人员的协作可以有效地改进错误控制。
但我认为“无差错软件”属于科幻小说......
答案 8 :(得分：1)
无错软件是一个神话。相比之下，当你的老板说你现在不应该在你的软件中有bug时，就像告诉数学家他们应该现在已经找出π的精确十进制值，或者找到所有的素数。无错软件是您接近的目标，而不是您实现的目标。
这并不是说我们不会对我们软件中的错误负责，或者熟练的开发人员不会有较少的错误发生率。但是你的老板需要对你的能力有现实的期望。没有完美的驱动程序，没有完美的经理，也没有完美的程序员。
答案 9 :(得分：0)
我同情你和你的老板。我认为值得注意的是，在这个时代，让软件“完美”将是如此昂贵，没有人愿意为此付出代价。最后，客户接受使软件价格合理的商品级别。
我将贡献一个简单的“方法”。这是零缺陷里程碑的想法。在软件项目中，谈论代表项目时间表中重要点的里程碑是很常见的。在我见过的大多数情况下，人们说他们已经完成了一个里程碑，他们已经完成了该里程碑功能代码的输入。当然，实际上，这不会让你知道完成的进展。
零缺陷里程碑不会尝试零缺陷。相反，它意味着你没有宣布你已经达到里程碑，直到你完成了一些测试，并且具有一定的信心，你知道你的所有错误。您可以选择在声明里程碑之前修复一些，或者您可能没有，但至少您知道它们是什么。您可以确定要执行的测试数量以及可接受的错误，但这些事情是事先商定的。
这种里程碑可以更好地衡量您在完成任务方面取得的进展，但令人惊讶的是您很少看到以这种方式管理的项目。我推荐它。
答案 10 :(得分：0)
从头开始是愚蠢的，不仅限于编程。只是几个反例。 我们大多数人都有他们的驾驶执照很长时间，因此他们不应再参与事故。这有多真实？
另一个例子，螺钉应该在“正常”条件下断裂，但它们仍然会发生。可能会超载，或者它们可能会开始生锈，或者有人可能认为使用更差的质量是个好主意。猜猜你没看到的，你必须说很有可能说螺钉的充电是可以的，但是你不能用力地测试它们。可能会有一些薄弱的地方，它可能是包含空气，你几乎看不到它，而不是x-raying它们。所以它一遍又一遍地说，如果这种态度听起来有点健全，我们就会生活在一个完全不同的世界......
答案 11 :(得分：0)
关于最佳实践，良好开发过程+ TTD的所有内容，但也使用... 突变测试 - 非常酷的工具来测量单元测试质量！ http://nester.sourceforge.net/
祝你好运。/ Ievgenii
答案 12 :(得分：0)
我已成功完成“早期发布，经常发布”模式，您可以在其中一次选择较少的功能，并在将这些功能包含在发行版中之前对其进行广泛测试。不符合质量标准的要素不包含在迭代中。
显然，这不是单独工作的，你需要有像Phil，Manrico，Twan和其他人提到的那样良好的开发实践......
答案 13 :(得分：0)
您的软件有哪些缺陷？
出界错误？读取非初始化变量？解除引用无效指针？这些可以通过静态分析工具检测到。
对要求的理解不完整？在这里，测试驱动的开发和审查文化有所帮助。
设计问题？同样，评论也是一个很大的帮助。
使用过时的代码？这需要版本控制。
并且：保留缺陷日志，以便了解您所犯的缺陷类型。
答案 14 :(得分：0)
JUnit（或其他一些单元测试程序）非常有用。当测试自动化并经常运行时，您可以确保您的更改不会破坏系统的其他部分。在设计棘手的类时它也很有用，因为你可以计划出你想要测试的所有（好的，很多）边缘情况并一起测试它们。
关键点是
答案 15 :(得分：0)
我认为“到现在为止，凭借你的知识水平，你的软件永远不会有错误”是不可能的。
但您可以在您的项目中使用TDD（测试驱动的开发人员），以最小化发布版本中的错误。但这不是一个完整的解决方案。一些错误非常复杂，可能是由第三方组件或其他任何内容的更新引起的。
答案 16 :(得分：0)
除非应用程序非常小，否则我认为无法实现无错误。
我认为您可以而且必须尝试通过严格的测试来限制软件中的错误数量。
答案 17 :(得分：0)
单元测试！它不是一个白银，但可以节省大量的调试时间。