健壮性最佳实践

Question

我刚刚遇到了关于初始化局部变量的这个问题。许多答案都讨论了简单性/可读性还是健壮性。作为(远程部署的)嵌入式系统的开发人员，我总是支持健壮性，并且倾向于遵循几条看似相互冲突的规则：

• 尽您最大的能力处理每一个错误，使设备能够继续运行。
• 在编程或发生致命错误后，尽快将代码设计为失败。

我们都接受过验证输入的培训，以防止设备因用户(或其他外部)输入而中断；始终假设数据可能无效并进行相应的测试。

为了确保健壮性，您还遵循了哪些其他特定的实践？示例很有帮助，但我也对普遍适用的技术感兴趣。

Answer 1

我实现了各种防止错误并从错误中恢复的方法：

1)处理所有例外情况。正如你所说，“处理每一个错误”。如果用户单击窗体上的按钮，应用程序就不可能从未处理的异常中消失("poof")。出于这个原因，我将事件处理程序包装为一个通用的尝试捕获。

2)具有完全堆栈跟踪的日志错误。当我重新抛出一个异常时，我总是创建一个新的异常，并将捕获的异常添加为一个内部异常。我的日志代码递归地打开了消息，这给出了比我本来想要的更多的细节。

3)决定您的类是否可以重用。如果不把它记录下来。考虑在代码中实现一个接口，比如IRestartable或IReusable。任何没有实现它的对象都必须在使用过一次之后被丢弃。

4)不要考虑线程安全。我已经了解到.NET是非常多线程的。许多事件是在任意线程上处理的。一个用.NET编写的应用程序可以同时执行多个线程，并且没有一行代码显式地创建一个线程。

5)尽可能缩小可变范围。实例化使用对象的位置附近的对象，而不是在方法开头的大块中实例化它们。您可能会缩短对象的生存期，并且不会忘记位于类或方法顶部的巨大块中的不需要的或重用的变量。

5)很简单，但我仍然看到它在发生。避免像瘟疫这样的全球性疾病。我见过数百个未使用/重用变量的代码。弄清楚和重构是个烂摊子。

Answer 2

我喜欢"务实的程序员“中描述的技术。我还使用TDD，而不是DBC，因为我发现它更灵活、更有效率。例如，在“语用”中描述的一些技术包括：

• 经常考试。早点测试。自动测试
• 不要重复你自己
• 使用破坏者测试您的测试
• 对异常问题使用例外情况
• 别活在破碎的窗户里
• 不要使用手动程序

它们似乎都是常识，但令人惊讶的是，团队在面对最后期限时偏离这些基本原则的速度是如此之快。

Answer 3

我喜欢第二种眼睛方法:在我编写和测试了一些关键代码之后，我有时会要求同事专门检查它，目的是寻找打破它的方法。

用这种方式激发人们的创造力是很有趣的。:-)