2.6.1　度量可靠性

评估可靠性至少需要检查下列软件工程实践和技术属性。

●应用程序架构实践

　■多层设计一致性

　■耦合度

　■组件或模式重用度

●编程实践

　■错误和异常处理（包括所有层：GUI、逻辑和数据）

　■与面向对象和结构化最佳编程实践的一致性（适用时）

●复杂度

　■事务复杂度

　■算法复杂度

　■编程实践复杂度

　■不当编程（dirty programming）

无论何时，一旦违反了好的实践，要保持应用程序的稳定性以及确保其在运行环境中遇到异常事件时能有效运行，就会变得更加困难。糟糕的可靠性增加了应用程序失效的风险并导致业务亏损。可靠的、能自恢复的应用程序必须保证，在外部失效或错误输入等异常情况下不会产生不可预测的结果或中断。

例如，缺乏或滥用分层架构会导致应用程序更加复杂，更不可靠。层次确保了关注点的分离（http://en.wikipedia.org/wiki/Separation_of_concerns），如当所有的数据库访问路径被集中到一个组件时，数据完整性就很容易执行。层次间的交互也应当小心地检查以保证只允许必要的交互。

在组件层次上，降低组件间的依赖度和耦合度将有助于提高应用程序的健壮性。事实上，如果应用程序中的一个组件被太多的其他组件使用的话，那么其实现或修改中的缺陷将会影响到应用程序中相当大的部分，从而增加了它引起故障的可能性。此外，更多的高度耦合组件能极大地增加了测试需求，并且在有限的时间和资源下，测试可能无法检测应用程序里复杂的失效方式。复杂度和易于出错组件间的相关性已经被多次证明（Curtis，1979）。

要使应用程序可靠，就需要对其进行防御式编码来避免已知的会引起灾难性故障的问题。最新的错误和异常处理过程，应当使应用程序能在遇到意外的、错误的或罕见但合理的事件时自我恢复，这可以通过采取纠正措施或者至少提供有意义的信息来让支持团队识别并矫正问题。其他形式的防御式编码应当提供超时、断路器和防灾隔墙等方法，以确保系统组件中的问题在引起故障前不会扩散（Nygard，2008）。

可靠性的完整评估需要一些分析，这些分析对于特定编程范式中已知的问题很敏感。例如，某些面向对象特性（如继承或多态）的错误使用或过度使用，还有强大的编程技术（如动态实例化）的使用，导致技术团队在应用程序投入使用前无法完全评估其行为。这让面向对象技术在安全性至关重要的应用程序中变得难于使用。事实上，随着系统可预测性的降低，系统的可测性也降低了。这是为什么某些生产与生命息息相关的软件的行业（参见发动机行业软件可靠性协会[MISRA]：http://www.misra.org.uk）在其标准中禁止使用一些这类的编码技术。