是佛教用语，指执着于表象而偏离本质。仙剑奇侠传中有一个故事。讲的是一颗已经炼化的佛珠。为了让更多的人拜佛，他们施法让这些人失去记忆，只想一心一意拜佛。使人皈依佛是好事，若难为人，那就是脱离了本质，就是执着了，或者说是成魔了。这个小故事告诉我们，在认知的世界里，我们很容易被表象所蒙蔽而忽视本质。为此，佛教徒发明了这样一个名词来专门指出这种现象。重用也是如此。重用最初是通过消除重复来实现的。获取一系列可重用的组件。因此，在以后的开发工作中，我们可以更快的响应需求的变化，也就是所谓的响应能力的提升。但是，由于多次重用，代码会减少，而且更难更改。重用增加，但可读性降低。考虑到软件开发是一个团队工作，我们这个行业的离职率高达20%。难学的代码确实很难维护。虽然可以抱怨接手的人不称职，但是降低了响应性，违背了重用的本质。什么情况下会出现这样的场景呢？主要是视角单一，我只从自己的单一视角看重复，没有做全局优化。这个说法可能有点抽象，我说几个比较具体的情况。当我们只关注功能角度时，需求有很多描述角度，只能从功能角度来描述，比如“网站必须有任务卡，任务卡上有文字版的学习内容，视频讲解，和家庭作业问题。”也可以添加业务角度，比如“学员必须先报名参加特训营，才能参加特训营。进入特训营后，学员会看到任务卡列表。学员阅读任务卡上的学习资料，看完学习资料做题验证，学过没有，交助教审核。当我们只看功能视角的时候，我们可能会忽略业务的差异，从功能视角变得过于抽象。***当业务发生变化时，反而响应速度比较弱。一个简单的背景，一切看起来都一样对我们来说，却是一个列表页面，添加页面，修改页面，添加一些删除的功能，说白了，都是crud，所以我就一个一个的做成组件，每个页面只需要简单配置一下，然后就可以搞出一套自己的增删改查页面，这个角度没有考虑到不同的实体其实有不同的业务，关注的人也不同***，彼此的进化方向总会有一些差异，你把它定义为一个东西，而我所做的每一次修改都承载着所有其他实体的特殊性。所以逐渐减慢了我改变a的速度并降低了响应能力。不必要的自动化有抱负的程序员肯定会考虑提高工作效率，使用一些自动化的手段来缩短流程，提高效率。但有时，这种追求可能是有害的。我们的系统有一个面包屑功能，就是典型的“A页/B页/C页”那种面包屑。团队成员建议一个一个写面包屑太烦人了，干脆创建一个根据URL生成面包屑的函数吧。乍看之下，似乎是提高了效率，但实际上，URL上的名词和你要在面包屑上显示的名字可能看起来不一样。比如在我们的场景中，我们提供了一个任务卡片预览功能，你的面包屑可能是“xx后台/xx训练营管理界面/xx卡片预览”，而当学生正式使用任务卡片时，他可能是“学习中心/xx训练营/xx卡”。并且'/programs/$pid/tasks/$tid'可能出现在他们的url中。同一个程序和任务的翻译文本是完全不同的。为了支持这种区别，你需要扩展一些额外的功能来进行这种区分。做了之后可能不如直接写方便。顶多抽出几个常量来简单消除重复。当我们只从代码上看重复的时候，我就不举例了。其实很多犯这个错误的人都是重构的支持者，只是他们的技术不是很好。因为如果你仔细看，重构中的很多味道都有一种和他相反的味道，比如发散变化，霰弹枪修改。如果我们只看代码，我们就会打败重用的本质——更好地响应变化。我告诉我的第一个场景，只关注功能的角度是一个类似的问题。这个可能更像是，只关注代码。在忽略上下文的情况下，这可以看作是一种只有功能视角的情况。很多功能我们认为是重复的，提升为一个概念，但实际上它们基本上是两个东西，只是刚好重名而已。比如在过去的很多软件中，都有一个统一的用户群体概念。无论在哪个业务场景中，都需要扩展用户组的概念来管理用户权限。这样做的结果就是用户组越来越臃肿，每次修改都要更改其他组的功能。在我们的网校数字平台中，有一个学生学习小组，一个老师提问小组。这两个集团的业务完全不同。如果此时都由一个统一的用户组来管理，难免会造成不必要的问题。耦合，损害响应能力。这些故事告诉我们，我们不会在真空中重复使用。我们制作的软件有其商业目的。我们的工程实践也服务于商业目的。当我们说tech@core时，可以说技术就是业务。诚然，他给技术人员带来了更多的力量，但力量越大，责任也越大。技术人员也需要跳出技术，拥有更多的业务视角和体验视角。不仅仅是从高处沉浸在技术中。才能真正发挥各种做法的价值。【本文为专栏作者“ThoughtWorks”原创稿件，微信公众号：Thinkworker，转载请联系原作者】点此查看该作者更多好文
