软件工程的开发曲线极度类似 emacs 的学习曲线。
这确实令人尴尬，哭笑不得，又很是郁闷。（心中一万只……）
内卷是如何产生的？
过程式的编程方法是导致内卷的原罪
过程式的方法要求我们必须一步一步走遍软件工程的每个角落，才能看出整个工程的一点点影子。而工程规模越大，代码量越多，逻辑过程就越复杂，内卷就越严重，使人陷入其中难以自拔。
逻辑过程就是“内卷”
所以，内卷伴随在每一行代码中，是伴随每个过程、步骤的危险副作用。根本无法消除。
内卷变危险的迹象
主要有两个迹象，表明内卷已经相当严重、危险了：
- 看不懂
- 改不动
当开始看不懂的时候，意味着内卷的威力开始凸显了，此时影响还不算甚大，加把劲还能看懂。
当实在看不懂的时候，意味着内卷已经开始占上风，此时开发者开始处于被动的局面。
当开始改不动的时候，意味着内卷的杀伤力已经强悍了，可以伤到开发者了。
当实在改不动的时候，意味着开发者要被内卷团灭了，开发者可以飙脏话跑路了。
如何看“得”懂，改“得”动
要想看得懂，改得动，就要避免逻辑过程的复杂性，避免内卷。
因为按照逻辑过程组织出来的程序，也必定要由我们自己一步一步吃力走完所有的过程，
过程之间的关联和跳跃，更会加剧内卷，最后动弹不得，等待崩塌。
那么，怎么做到呢？
要想避免内卷，就要避免逻辑过程。
对于我们人类而言，所有的、事无巨细的过程并不是必须的，我们其实最关心的只是输入和结果（也即输入和输出）。
这就像跟工厂定制一个产品，但并不 care 它是怎么生产出来的，而只 care 最终的产品。要做的只是描述清楚需求。
不然，难道要造火箭，就要把涉及的所有零件制作流程都弄懂吗？这显然不靠谱。
但实际上那些内卷变危险的软件工程，使用的就是这种方法（说面试造火箭，工作拧螺丝的，你确实在造火箭，你造吗）。
我们关心的只是输入和输出，不要在意那些细节。描述清楚需求就够了。
如果有一种方法，只需描述清楚输入和输出，就能跑通程序，那就好了。
这种方法还真有，就是数据结构化编程。
数据结构化编程
这种方式要求我们描述清楚预期的输入和输出的数据结构，然后填充输入数据（即：令输入准备好），就能自动获得预期结果。
这样我们就关心该关心的，忽略 no care 的。
核心思想是：期待的数据准备好了，就该获得预期结果。
这真的确实符合人类的生活习惯。
为何会有这种效力？
秘密原因之一就是，我们在一开始，就明确的描述清楚了预期的数据结构。 从这，就能完整了解程序，而不必深入其中。我们看到的就是预期的结果。
另一个原因是，数据结构是可以自洽的，它包含了输入和输出，非常棒，这就能够把自己描述清楚了。 它自己就解释了自己的意图，我们不用再去通过复杂的逻辑过程去推测意图了。
下一个原因是，数据结构是层次分明的，并且它是自洽的，所以在每个层次上都能弄懂意图。
还有一个大的、神奇的原因是，整个理论思想和以往的都不同了，无论是在认知上，还是用法上都更符合人类的习惯。 这里包含许多可以一一拿出来探讨一番的原因，限于篇幅，只简要列几项。
更符合人类习惯
- 新认知：编程不再是去推导结果，而是为尚未准备好的输入，去填充数据。
- 新概念：当输入数据准备好时，自动执行预期规则，获得预期输出结果的编程方式。
- 新思维：关心数据结构描述，忽略复杂的逻辑过程。
- 顺序无关：如果预期多个输入数据，任哪个先准备好都无所谓，只要最终都准备好。（这很赞，上手就能感受到的快乐；团队协作更友好，友爱）
- 提前预期：不必等待数据经过逻辑过程之后，才能推导出结果，而是提前定义预期规则，静待数据准备好，就能获得结果。（试想团队协作的和谐画面）
- 弹性规划：如果某人任务量过大，可以再次规划数据结构，将大任务逐层拆分成子任务作为输入数据，多人并行开发。（这几乎是可以无限拆分的）
- 并行开发：Yes!
- 自动化：回归到新认知、新概念上来，只要期待的数据准备好了，就会自动获得预期结果。不必费力主动去驱动数据。
