作为一个现代的码农，我们难免要使用别人的脚手架，一是因为避免闭门造轮子，二是因为我们还不会造轮子。
一开始，我们在其基础上添加自己的业务逻辑；到最后，我们必须剔除我们不需要的多余代码。这时候，有两种方式：一种是渐近的剥洋葱，即移除不需要的；一种是清爽的一锅端，即保留只需要的。也就是前者的取反。
管理者和开发者的观点往往是不一样甚至完全相反的。管理者肯定会倾向第一种，因为这将大事变小，小步快跑，能够保证软件的稳定迭代，同时保证项目的其它进程。开发者肯定会倾向第二种，因为对于其来说，需剥离的代码比需保留的代码要多得多，这意味着会增加很多「不必要」的工作量。[1]
当然，码农的真实心理可能是：哪些代码是不需要的呢？能够直接做到仅移除不需要的，还需要在这讨论吗？
为什么管理者和开发者会有这种分歧呢？这其实是一个认知的问题，我们这里抛开以上纠缠的时间性的「迭代」、「进程」、「工作量」等抽象概念，通过一种直观的空间模型（拓扑）——积木和线团——来解释理解。
管理者是正确的，项目本身的设计结构是积木，拿掉一个模块并不影响系统的其它部分运行。但对码农来说，其当前并不理解积木的设计结构——也就是说，这堆积木对码农来说是一揉错综复杂的线团。移除的过程是抽线，而不是简简单单拿走一块积木。抽出一根需要的线而不打结，比抽出全部不需要的线而不打结，工作量有很大差别。
实体是积木，但这是在设计者的视角；在认知者的视角，由于实体尚未被认知，实体对其来说是一揉线团。管理者是站在设计者的视角来看待问题的，而码农则处于认知者的视角。这时就如视错觉，管理者眼中的空间结构在码农看来就是杂乱的二维线条——无法抽象的对象；码农眼中的二维线条对管理者来说——抽象到无法理解。[2]
但我想无论是管理者还是码农，无论是设计者还是认知者，大家都认可同一个大前提——极简是美的——因为极简（最小作用量原理[3]）是自然原理，而我们都是诞生于自然。
当然，还有很重要的一点：开发者渴望认知轮子的原理。 ↩︎