数据结构化编程之思维解放运动

尊敬的读者，如果你觉得这值得传播，就广泛传播介绍给周围的人，越多人和我们在一起，就越容易获得解放。如果有其他意见，也请批评指正。谢谢~

开始之前，我们应该认可这个概念：

起因

程序是人类构建的最复杂的工程之一，需要多人协作。
这引起一个有趣的共知：开始我们以为代码是写给机器执行的就好了，可事实上是写给其他人阅读和理解的，需要其他人能看懂！
至此，我们终于理解并要求所有人都能做好这件事。
因为这能减少沟通成本。

发现沟通瓶颈

除去真正的编码时间，其他时间大都花在沟通上面了。
因为总要和其他人沟通对接才行。
一个很好的例子是，前端和后端因为有清晰的界限可以很好的划分明白，对接清楚。
不过对于各端的内部小组成员之间，因为大都没有清晰的界限可以划分，所以一般根据功能模块来划分，这也不错，看样子能工作的很好了。

随着时间的演进，系统越来越大，越来越复杂。Code Review 的时候发现，当各个模块搭建起来组成一个整体时，还是两眼懵。
已经很精心的设计每个模块和对接方法了，为什么还是会这样？
因为虽然每个模块是独立开发的，但最终总会按各种逻辑杂糅在一起，复杂度突然又冒出来了。

引起复杂的本质

划分，然后沟通对接。这个流程没毛病。
前后端的协作沟通就工作的很好。即使系统很复杂我们难以厘清各个内部模块的对接，但我们总能很简单清晰地弄清楚前端和后端的对接部分。这很奇怪。
难道是因为前后端总会保留有接口文档，而内部模块之间往往不会吗？这是表象，即使有文档，情况也不会好多少。

这是因为各个内部模块之间组织对接的方式导致的。
内部模块之间对接的特点是杂糅，各个模块按逻辑过程安排在一起工作，需要小心翼翼。耦合又神奇的出现了，它们又变成了复杂的一大坨。

我们总是错误的以为系统复杂的原因是因为耦合。
其实耦合不是引起复杂度的主因。因为，前后端总是需要耦合在一起的，却依然能够保持简单。

分模块的效用是隐藏过多的逻辑过程，但模块拼接时还是需要按逻辑过程一环套一环来咬合出整个程序系统。像许多复杂的齿轮一般咬合。
这也正好验证了，模块划分时很开心，但最后组合到一起时头疼恶心的真实现象。
我们经常乐此不疲的重复这一过程。

解决办法

还是从前后端的沟通对接来思考，为什么这里能工作的这么好呢？
这是因为它们之间不是使用过程来沟通对接的，而是使用的 数据结构。
前后端总是通过数据结构来沟通，这就直接避免了组织复杂的逻辑过程。不引入本质复杂的过程，自然就能保持原本数据结构的简单清晰明了。
这又恰好回溯验证了前后端和谐沟通的事实。

所以，内部模块划分开发，最后提供对接的部分应该是 数据结构，而不再是过程。