中庸，是中国儒家思想的四书之一，其最浅薄的理解是做事不偏不倚恰到好处。中华文化上的中庸的讨论非常的多，叹为观止。有的把中庸划分成几个层次。有的则升华到哲学的高度。但是总的来说，中庸的思想继承了中华文化传统思想的套路，模糊性高，可操作性不强。

作为一个写程序多年，又做过一些架构的人来说，我觉得中庸所代表的含义对于每个码农都很重要。但是直到我这些年因为人工智能兴起，自学人工智能相关知识，再次捡起概率论与数理统计之前，我一直都没找到一个好的表达方式，去聊聊所谓不偏不倚的恰到好处对软件开发是什么意思。

统计学上假设检验有著名的第一类错误(Type one error)，也就是假阳性错误(false positive)和第二类错误(Type two error)，也就是假阴性错误(false negative)。以一种检测癌症的技术为例，前者是把非癌症病人识别成癌症病人的错误率，后者是把癌症病人识别成非癌症病人的错误率。

统计学告诉我们，假阳性错误和假阴性错误是密切相关的，减少了一种犯错可能性，就会导致另外一种犯错可能性的增加。举个例子来说，以交道人品好，学识好的朋友为目标，张三的策略是，交友谨慎，只有确定了这个人满足人品好，学识好的条件才交友。李四的策略是，先不管三教九流阿猫阿狗都交上朋友，一直到某个人证明了自己要么人品不好，要么学识不好。

这两种策略的前者，显然每个交到的朋友都是人品好学识好的，但是张三也会因此错过了很多人品好，学识好的朋友。后一种策略，李四不可能错过人品好，学识好的朋友，但是也因此交了很多其实人品或者学识不好的朋友。

这是事请的两个极端，我们在具体现实生活里，很少会在这两个极端里选一个，更多的是在这两者之间的某个点做平衡。而这种恰到好处的平衡因事情不同而不同。回到上述例子，如果是检测癌症的技术，把不是癌症的人识别成癌症，最多病人受点惊吓，再多做几个检查，总能确诊的。而如果把是癌症的病人识别成了健康的人，病人会因此错过最佳治疗时机，甚至丧命。因此在这个情况下假阳性错误可以很高，但是假阴性错误一定要非常低。相反的情况也很容易找到。

具体到软件开发和架构设计里，有很多这样的取舍的问题。什么是恰到好处的取舍，很考验一个人的经验。在软件代码质量和功能实现的时间之间就有取舍。在测试完善程度和上线以后bug的数目之间也有取舍。在需求和设计花费的时间和代码开发花费时间之间也需要取舍。可以说恰到好处的中庸之道，遍布软件开发的整个流程。

但是一般来说，人要么是凭经验进行取舍，要么是拍脑袋做决定。比如说我见过一位微软的领导，他的名言就是，如果写的代码只是重构，而不带来新功能的话，这位领导一律拒绝。结果呢，他带的组往往一开始很生猛，迅速的交付了很多东西，但是过一段时间以后，代码就再也无法轻易的添加任何新功能了，一碰就倒。这就是完全没有理解中庸之道的领导。

在我看来，统计学上的第一类错误和第二类错误的思维方式，对于具体情况下如何做到恰到好处的中庸选择，提供了一定程度的量化思考的能力。一个人可以通过考虑两个极端情况下分别会导致什么样的现象，从而做出比较合理的选择。

文章的最后，老司机也需要留一点干货，运用这种第一类错误和第二类错误的思维方式，在恰到好处的做出中庸决策的时候，我有如下三条锦囊：

代码重构的事不过三原则。我对于代码重构是不是要的问题态度是这样的。我第一次看到这段代码觉得要重构的时候，加个注释放过，第二次看到这段代码觉得要重构的时候，继续放过。第三次看到觉得还要重构的时候，毫不犹豫的重构了。这个原则的原因在于，一段不常用的代码，写的不好也不需要费心费力去重构。

软件测试抓小放大原则。我对软件测试的态度是单元测试要尽可能的完善，越是大规模的整合测试，系统层面的测试，就越应该注重关键链路，而不是面面俱到。背后的原理是很好理解的，小东西就应该尽可能挑错，成本低性价比高。大东西要找出所有的链路的问题来，成本高不值得，所以应该关注重点。

软件开发的自底向上原则。对于软件开发过程中，越是被别人依赖的多的所谓底层模块，比如商业软件的存储层，比如说给其他人用的类库，越需要花费更多的时间在设计，测试，越需要稳定，越不可以随便破坏兼容性。对于顶层的比如用户界面的设计，就越可以敏捷开发尝试。其中的原理也我想从第一类错误和第二类错误的思维方式也很容易推导出来。换句话说，如果软件开服的人明白这个道理，可能就不会有随意为之的错误了。

锦囊就写到这里，站在统计学的思维，以第一类错误和第二类错误为指导，可以有效的帮助码农在复杂多变的开发和设计环境下把握中庸之道的精髓。大家不妨尝试一下。

【本文为51CTO专栏作者“徐飞”的原创稿件，转载请通过作者微信公众号“飞总聊IT”获取联系和授权】