头图

聊聊软件工程的“内卷”

muchan92

软件工程的开发曲线极度类似 emacs 的学习曲线。

这确实令人尴尬,苦笑不得,又很是郁闷。(心中一万只……)

内卷是如何产生的?

过程式的编程方法是导致内卷的原罪

过程式的方法要求我们必须一步一步走遍软件工程的每个角落,才能看出整个工程的一点点影子。而工程规模越大,代码量越多,逻辑过程就越复杂,内卷就越严重,使人陷入其中难以自拔。

逻辑过程就是“内卷”

所以,内卷伴随在每一行代码中,是伴随每个过程、步骤的危险副作用。根本无法消除。

内卷变危险的迹象

主要有两个迹象,表明内卷已经相当严重、危险了:

  1. 看不懂
  2. 改不动

当开始看不懂的时候,意味着内卷的威力开始凸显了,此时影响还不算甚大,加把劲还能看懂。
当实在看不懂的时候,意味着内卷已经开始占上风,此时开发者开始处于被动的局面。

当开始改不动的时候,意味着内卷的杀伤力已经强悍了,可以伤到开发者了。
当实在改不动的时候,意味着开发者要被内卷团灭了,开发者可以飙脏话跑路了。

如何看“得”懂,改“得”动

要想看得懂,改得动,就要避免逻辑过程的复杂性,避免内卷。
因为按照逻辑过程组织出来的程序,也必定要由我们自己一步一步吃力走完所有的过程,
过程之间的关联和跳跃,更会加剧内卷,最后动弹不得,等待崩塌。

那么,怎么做到呢?
要想避免内卷,就要避免逻辑过程。
对于我们人类而言,所有的、事无巨细的过程并不是必须的,我们其实最关心的只是输入和结果(也即输入和输出)。
这就像跟工厂定制一个产品,但并不 care 它是怎么生产出来的,而只 care 最终的产品。要做的只是描述清楚需求。
不然,难道要造火箭,就要把涉及的所有零件制作流程都弄懂吗?这显然不靠谱。
但实际上那些内卷变危险的软件工程,使用的就是这种方法(说面试造火箭,工作拧螺丝的,你确实在造火箭,你造吗)。

我们关心的只是输入和输出,不要在意那些细节。描述清楚需求就够了。
如果有一种方法,只需描述清楚输入和输出,就能跑通程序,那就好了。
这种方法还真有,就是数据结构化编程。

数据结构化编程

链接在这里(很硬核):https://github.com/rainforest...

这种方式要求我们描述清楚预期的输入和输出的数据结构,然后填充输入数据(即:令输入准备好),就能自动获得预期结果。
这样我们就关心该关心的,忽略 no care 的。

核心思想是:期待的数据准备好了,就该获得预期结果。
这真的确实符合人类的生活习惯。

为何会有这种效力?

秘密原因之一就是,我们在一开始,就明确的描述清楚了预期的数据结构。
从这,就能完整了解程序,而不必深入其中。我们看到的就是预期的结果。

另一个原因是,数据结构是可以自洽的,它包含了输入和输出,非常棒,这就能够把自己描述清楚了。
它自己就解释了自己的意图,我们不用再去通过复杂的逻辑过程去推测意图了。

下一个原因是,数据结构是层次分明的,并且它是自洽的,所以在每个层次上都能弄懂意图。

还有一个大的、神奇的原因是,整个理论思想和以往的都不同了,无论是在认知上,还是用法上都更符合人类的习惯。
这里包含许多可以一一拿出来探讨一番的原因,限于篇幅,只简要列几项。

更符合人类习惯

  • 新认知:编程不再是去推导结果,而是为尚未准备好的输入,去填充数据。
  • 新概念:当输入数据准备好时,自动执行预期规则,获得预期输出结果的编程方式。
  • 新思维:关心数据结构描述,忽略复杂的逻辑过程。
  • 顺序无关:如果预期多个输入数据,任哪个先准备好都无所谓,只要最终都准备好。(这很赞,上手就能感受到的快乐;团队协作更友好,友爱)
  • 提前预期:不必等待数据经过逻辑过程之后,才能推导出结果,而是提前定义预期规则,静待数据准备好,就能获得结果。(试想团队协作的和谐画面)
  • 弹性规划:如果某人任务量过大,可以再次规划数据结构,将大任务逐层拆分成子任务作为输入数据,多人并行开发。(这几乎是可以无限拆分的)
  • 并行开发:Yes!
  • 自动化:回归到新认知、新概念上来,只要期待的数据准备好了,就会自动获得预期结果。不必费力主动去驱动数据。
阅读 182

雨林人

1 声望
0 粉丝
0 条评论
你知道吗?

雨林人

1 声望
0 粉丝
宣传栏