编程杂谈：从人类与软件系统的根本矛盾说起

最新推荐文章于 2022-04-05 20:43:37 发布

a60857878

最新推荐文章于 2022-04-05 20:43:37 发布

阅读量179

点赞数

原文链接：http://www.cnblogs.com/skyesx/p/11262013.html

版权

在纷繁复杂的概念满天飞舞的软件编程领域，希望能分享自己整理的一些观点，帮助大家穿透迷雾，看清问题以及解决方案的本质。

有一个说法：人的短时记忆广度平均数为7,即大多数人一次最多只能记忆7个独立的块（Magic number 7）。

有另外一个说法：当需要根据短时记忆进行信息加工时，一个成年人能处理的块的个数是4左右(Working memory)。

这些说法不一定完全正确，但我们可以肯定的是，人类处理信息、加工信息的能力是有上限的。

然而要完成一个有实际意义的软件业务系统，绝对不是处理4个变量或者7个变量就能完成的，完整的业务其所需处理的数据要大几个量级。

由此软件系统的复杂性与人类认知能力存在上限形成了一个矛盾。当复杂度超过人类可控制的范围时，我们就可以认为其失控了。

我们要怎么避免软件系统失控？或者说如何正确可控地完成一个软件系统呢？大家可以先思考10秒。

既然矛盾是两个方面的事情，那解决矛盾也可以从两个方面入手：

要进行分治的话，有也两个问题要解决

对于第一个问题的答案就是我们经常听到的

高内聚，低耦合

上述指导原则，能让紧密耦合的逻辑、数据归集到一起，能更少牵制（接口、协议）地进行内部演进。

而存在的接口、协议能让我们可以以更高维度的抽象来组织我们的逻辑。

就像我们组装电脑时，只要主板与CPU、硬盘、显卡等等的接口协议确定了，那么主板就可以不管各类组件的具体品牌，型号地组织不同部件的工作，而各个组件都可以在接口的控制下各自独立改进。

对于第二个问题，则是：

子问题规模应为单个人认知极限规模的70%左右

如上图，问题可以分解成不同的层级。上图把问题及解决方案分解成了3层，核心问题、子问题、孙问题。

之所以有层级的存在，是因为子问题的解若数量太多的话，一个人也是无法整合处理的，因此要处理的子问题解数量必须在一个人的可控范围内。但数量控制了，子问题的规模可能很大，并非一个人能求得，因此需要继续划分孙问题。

从上一段的文字我们也可以得出一个结论，子问题并非越小越好，而是尽可能的大，如此才能减少问题的层级，也减少了整合子问题而产生的消耗（也就是说微服务不是越小越好），而问题规模为个人处理极限的70%则是为了应对后续变化，需要预留一定的buffer。

总体复杂度存在一个极限最小值，其由问题域的本质复杂度决定。

然而我们的解决方案会在本质复杂度的基础上，有意无意地引入其他很多额外的复杂度：

可以说，引入复杂度的原因有千万种。而我们能做的，只有一件事情——每次引入复杂度时都认真思考其是否必要，是否利大于弊。

然而我们不能指望于每个人都有能力以及觉悟去审视这个问题，因此自上而下的设计以及监督是必须的，否则代码的整体复杂度就会不断提升，与热力学第二定律有点类似

孤立系统的熵（混乱程度）永不自动减少，熵在可逆过程中不变，在不可逆过程中增加。

一个良好设计的系统，在后续没有经过上层设计以及监督（外部系统做功）的软件系统的混乱程度会不断增加，直到系统的混乱程度变得与编码的程序员思维混乱程度一致（当然或许编码程序员的思维并不混乱，对代码也有自己的要求，这样系统或许会不再腐化，甚至进化，但我们没办法做到每个程序员都有这样的水平）。

本文的内容只是写好代码的序章，但由于规模引起的问题最终解决方向都会落到上面提到的分而治之以及总体复杂度控制上，这个是根源。

分而治之及总量控制不仅仅能在软件领域上应用，我们可以从公司人事组织架构、天体系统研究等等方面都可以看到应用。

后续文章我会尝试在上面两个方向上继续细化，将封装、抽象、多态、分层、DDD 等等思想以及面向对象语言、微服务、中台等等外功关联起来。

若本文能给你带来帮助，请点击右下角在看，若本文存在谬误，请帮忙批评斧正，谢谢！

多年金融行业经验，现为某Top2互联网银行高级搬砖工，曾在两家TOP3股份制商业银行及一家互金创业公司工作（架构、核心业务主程），EasyTransaction作者，欢迎关注个人公众号，在这里我会分享日常工作、生活中对于架构、编码和业务的思考

转载于:https://www.cnblogs.com/skyesx/p/11262013.html

关注