鲁棒是Robust的音译，也就是健壮和强壮的意思。


鲁棒性（robustness）就是系统的健壮性。它是在异常和危险情况下系统生存的关键。比如说，计算机软件在输入错误、磁盘故障、网络过载或有意攻击情况下，能否不死机、不崩溃，就是该软件的鲁棒性。所谓“鲁棒性”，是指控制系统在一定（结构，大小）的参数摄动下，维持某些性能的特性。根据对性能的不同定义，可分为稳定鲁棒性和性能鲁棒性。以闭环系统的鲁棒性作为目标设计得到的固定控制器称为鲁棒控制器。

什么叫“鲁棒性”呢？就是，你的程序是否把所有的因素（包括异常因素）都考虑进去了，并且对可能的异常因素采取的规避、补救措施。比如：

1、我们要让一个变量做递增运算，每次+1，达到某一个阀值时清零。那么你在做阀值判断时，是判“等于”，还是判“大于等于”？（正确答案：判“大于等于”）

2、我们要根据一个变量去查表，或散转，假设这个变量正常范围=0~7。那么你有没有考虑过，如果该值大于7后，程序该怎么办？ （答案：先屏蔽（剔除）无效值，再去查表，或散转）

3、我们要让某个IO口输出“高电平”去驱动外部电路（比如说，继电器）。那么你是否只输出一次“1”就认为完事了？（答案：开辟输出缓存，定期刷新输出口）

4、串口接收数据，假设收到“0X00”时执行动作A，收到“0X01”时执行动作B。那么，你有没有考虑过，如果收到的是其他数据，该怎么办？（答案：参考第2例）

这样的例子不胜枚举，每一个细节中都存在陷阱。如果在程序设计中予以考虑，则可以规避；否则，很难说你的程序运行过程中会发生什么事情。

因此，一个好的程序，定义应该如此：“在正常情况下，可以得到正常的结果；在异常情况下，可以得到意料中的结果。”

而不是：“在正常情况下，可以得到正常的结果；在异常情况下，得到不可意料的结果。”

匠人的一些同事（新手）往往会跟匠人来犯犟。强调曰：“我的程序没有BUG啊，是输入不正常导致的。”，云云。确实，这些细节上的疏忽，不能称为BUG。我们只能称之为“鲁棒性”差！

再扩展开来看，在整个系统中，不光是软件需要考虑“鲁棒性”，硬件也同样需要考虑。

举个例子：假设系统工作电压为5V，那么当电压低于5V时，会发生什么事情？考虑过吗？OK，你说你有复位电路，电压跌落时会复位。那么匠人再问：电压快速跌落时可以复位，但如果电压缓慢下降，你的复位电路还能正常工作吗？或者，电压波动时，又会如何？

这样的细节还有很多，贯穿在整个设计过程中。对于有准备的人来说，只要事先预想到了并采取规避措施，都不是问题。对于没有准备的人来说，调试将是一场艰苦的跋涉。因为前进的道路上，“坑”太多了，指不定在哪里跌倒。

本文转自网络。