积木与线团

为一个现代的码农,我们难免要使用别人的脚手架,一是因为避免闭门造轮子,二是因为我们还不会造轮子。

一开始,我们在其基础上添加自己的业务逻辑;到最后,我们必须剔除我们不需要的多余代码。这时候,有两种方式:一种是渐近的剥洋葱,即移除不需要的;一种是清爽的一锅端,即保留只需要的。也就是前者的取反。

管理者和开发者的观点往往是不一样甚至完全相反的。管理者肯定会倾向第一种,因为这将大事变小,小步快跑,能够保证软件的稳定迭代,同时保证项目的其它进程。开发者肯定会倾向第二种,因为对于其来说,需剥离的代码比需保留的代码要多得多,这意味着会增加很多「不必要」的工作量。[1]

当然,码农的真实心理可能是:哪些代码是不需要的呢?能够直接做到仅移除不需要的,还需要在这讨论吗?


为什么管理者和开发者会有这种分歧呢?这其实是一个认知的问题,我们这里抛开以上纠缠的时间性的「迭代」、「进程」、「工作量」等抽象概念,通过一种直观的空间模型(拓扑)——积木和线团——来解释理解。

管理者是正确的,项目本身的设计结构是积木,拿掉一个模块并不影响系统的其它部分运行。但对码农来说,其当前并不理解积木的设计结构——也就是说,这堆积木对码农来说是一揉错综复杂的线团。移除的过程是抽线,而不是简简单单拿走一块积木。抽出一根需要的线而不打结,比抽出全部不需要的线而不打结,工作量有很大差别。

实体是积木,但这是在设计者的视角;在认知者的视角,由于实体尚未被认知,实体对其来说是一揉线团。管理者是站在设计者的视角来看待问题的,而码农则处于认知者的视角。这时就如视错觉,管理者眼中的空间结构在码农看来就是杂乱的二维线条——无法抽象的对象;码农眼中的二维线条对管理者来说——抽象到无法理解。[2]

但我想无论是管理者还是码农,无论是设计者还是认知者,大家都认可同一个大前提——极简是美的——因为极简(最小作用量原理[3])是自然定律,而我们都是诞生于自然。


  1. 当然,还有很重要的一点:开发者渴望认知轮子的原理。 ↩︎

  2. https://en.wikipedia.org/wiki/Impossible_object ↩︎

  3. https://en.wikipedia.org/wiki/Principle_of_least_action ↩︎