编程行为可以量化建模

develop, test, debug
三种行为，越往后代价越高。假设程序员一边写码，一边同时写测试码，不分。
简化成develop和debug两种行为。

debug不仅仅代价高。而且不是经验可以线性积累的技能。
可以说debug 行为，给人带来的技能增值不高。

所以要额外努力增加前面两个行为的工作量，
减少后面一个行为的工作量。这种额外的努力，起个名字，叫做防御增量。

但是，如果防御增量过多，会导致代码和测试代码的行数大幅增加。
行数多，则debug的可能性会增加。这就是通常说的over engineering。

既然两个趋势冲突。所以可以用简单的U曲线描述。

最优的结果是：

软件预期总行数较小的时候，少防御。
---就算写的很垃圾，出现corner cases也不会明显影响debug的工作量。

软件预期总行数较大的时候，多防御。
---一旦出了问题，会和别的问题累加起来，
debug变成多项式甚至指数搜索。

以上，是我看了百页左右《programming practice》一书的感想。
我用总行数代替“复杂度”，是为了阐明原理所做的简化。
单一领域写码，例如web service，我认为可以量化建模。要是我在jira之类的公司，
可以据此原理写个proposal，考虑加个马工行为分析的feature。
越大的组，这种分析越有意义。

对单个项目来说，用LOC替代软件复杂程度，以及假设LOC越多导致的bug越多，
当然是过度简化的假说。
但是多个项目拼接，不同的U形线组合起来的情况下，这个假说可能是够用的。
bug的扩散影响，是组合数学，情况会非常多。所以大数定律
可以起作用。

这就好比传染病的SIR模型。人与人之间的连接分支越多，R0越有效。
整个动力系统越类似于分子运动论。

看着眼熟， 您这不会是参考顾老的文章吧 ？