6.1 健壮性与正确性

1 什么是健壮性和正确性？
健壮性：“系统或部件在无效输入或压力环境条件下能够正常工作的程度”
面向健壮性的编程：一种专注于处理意外终止和意外操作的编程风格。它需要代码通过显示准确和明确的错误消息来优雅地处理这些终止和操作。这些错误消息允许用户更容易地调试程序。

健壮性原则：
偏执狂（Paranoia）–程序员假设用户正在破坏他们的代码，并假设自己编写的代码可能会失败或工作不正常。总是假定用户恶意、假定自己的代码可能失败
▪ 愚蠢-程序员假设用户会尝试错误、虚假和格式错误的输入。把户想象白痴，可输何东西–因此，程序员向用户返回一个明确、直观的错误消息，不需要查找错误代码。–错误信息应尽可能准确，不会误导用户，以便轻松解决问题。返回给 用户的错误提示信息要详细、准确、无歧义
▪ 稳健性原则（Postel’sLaw）：在你所做的事情上保持保守；在你从别人那里接受的事情上保持宽容

▪ 危险的实现-用户不应访问库、数据结构或指向数据结构的指针。应该对用户隐藏这些信息，这样用户就不会意外地修改它们并在代码中引入错误。–当这些接口正确构建时，用户使用它们时不会发现修改接口的漏洞。–因此用户只关注自己的代码。
▪ 无法发生-代码被修改，可能会导致“不可能”的情况发生。考虑极端情况，没有“不可能”–因此，不可能发生的情况被认为是极不可能发生的。–开发人员考虑如何处理不太可能发生的情况，并相应地实施处理。
▪ 正确性定义为软件根据其规范执行的能力。
▪ 稳健性与正确性：在天平的两端。
–正确意味着从不返回不准确的结果；没有结果比不准确的结果更好。
–robustness意味着总是试图做一些可以让软件继续运行的事情，即使这会导致有时不准确的结果。
▪ 健壮性增加了对常见错误和非关键错误的内置容忍度，而正确性则在遇到任何不太完美的输入时抛出错误。

稳健性与正确性的比较
▪ 健壮性使用户和第三方开发人员的生活更轻松。–通过建立一个经过深思熟虑的灵活性，它将为客户不太符合要求的用户提供第二次机会，而不是将他们踢出冷门。
▪ 正确性使开发人员的工作更轻松。–他们可以专注于保证所有假设的单一模型，而不是陷入检查/固定参数和处理奇怪的边缘情况。–因此，可以忽略主成功路径之外的任何状态—生成更简洁、更易于理解和维护的代码。

稳健性与正确性的比较
▪ 外部和内部：外部接口（UI、输入文件、配置、API等）主要用于服务用户和第三方。让他们变得强壮，并且尽可能的适应，期望人们会输入垃圾。
–应用程序的内部模型（即域模型）应尽可能简单，并且始终处于100%有效状态。使用不变量和断言来做出安全的假设，只要遇到不正确的事情就抛出一个大的异常。
–在将无效输入传递给内部模型之前，使用反腐败层保护内部模型不受外部接口的影响，该层在可能的情况下映射并更正无效输入。
▪ 使您的外部接口健壮，并使您的内部模型正确-如果您忽略用户的需求，没有人会想使用您的软件。
–如果忽略程序员的需求，就不会有任何软件。

▪ 安全关键应用程序倾向于纠正性而不是健壮性。–不返回结果总比返回错误结果好。
▪ 消费者应用程序倾向于从可靠性到正确性。–任何这样的结果通常都比软件关闭要好。
▪ 可靠性。系统在规定条件下执行其所需功能的能力，无论何时需要，平均无故障时间很长。
▪ 可靠性=稳健性+正确性

▪ 错误是在软件系统开发过程中做出的错误决策。
▪ 缺陷是软件系统的一种属性，它可能导致系统偏离其预期的行为
▪ 一个错误：错误或缺失代码中的函数。
▪ 故障是执行过程中故障的表现，是软件系统在执行过程中偏离其预期行为的事件。

Error → Fault → Failure
▪ 错误：将“+”写入“-”
▪ 错误/缺陷/错误：语句的错误结果。
▪ 执行将显示失败。
▪ 程序员犯了一个错误，导致软件源代码的缺陷。
▪ 如果执行此缺陷，在某些情况下，系统将产生错误的结果，从而导致故障。

▪ 并非所有的软件缺陷都是由编码错误引起的。
–昂贵缺陷的一个常见来源是需求缺口，例如，导致程序设计者遗漏错误的未识别需求。
▪ 并非所有的缺陷都必然导致失败。
–例如，死代码中的缺陷永远不会导致失败。
▪ 当环境发生变化时，缺陷会变成故障。
–这些环境变化的例子包括正在新计算机硬件平台上运行的软件、源数据的更改或与不同软件的交互。
▪ 单一缺陷可能导致广泛的故障症状。

提高稳健性和正确性的步骤
▪ 步骤0：使用断言、防御性编程、代码评审、形式验证等以健壮性和正确性为目标的代码编程
▪ 步骤1：观察故障症状（内存转储、堆栈跟踪、执行日志、测试）
▪ 步骤2：识别潜在故障（错误定位、调试）
▪ 步骤3：修复错误（代码修订）

2如何衡量稳健性和正确性？
▪ 平均无故障时间（MTBF）是系统在运行期间固有故障之间的预计运行时间。
–MTBF计算为系统故障之间的算术平均（平均）时间。
▪ MTBF的定义取决于被视为系统故障的定义。
–对于复杂的、可修复的系统，故障被认为是那些使系统停止工作并进入修复状态的超出设计条件的故障。
–在本定义下，如果发生的故障可以保留或保持在未修复的状态，并且不会使系统停止工作，则不视为故障。

▪ 平均无故障时间（MTBF）表示可修复系统的两次故障之间的预期时间，而平均无故障时间（MTTF）表示不可修复系统的预期故障时间。
▪ 剩余缺陷率是指每个KLOC中的“软件发布后遗留的缺陷”：
1-10个缺陷/KLOC：典型的行业软件。
–0.1-1缺陷/kloc：高质量验证。Java库可能会达到这种正确性级别。
–0.01-0.1缺陷/kloc：最好的安全关键验证。NASA和Praxis这样的公司可以达到这个水平。
▪ 对于大型系统来说，这可能会令人沮丧。
–例如，如果您发布了一百万行典型的行业源代码（1个缺陷/kloc），这意味着您遗漏了1000个错误！