着相是佛家用语，指的是执着于外相偏离了本质。
仙剑奇侠传中有一个故事。讲的是一个成精了的佛珠。想要让更多的人向佛，于是施法，让这些人失去了记忆，只想一心礼佛。使人向佛，本来是好事，但强人所难，脱离了本质，便是着了相，也可以说反而是入了魔。
这个小故事告诉我们，在认知的世界里，我们很容易被表象所欺骗，忽略了本质。为此，佛家发明了这么一个名词来专门指出这种现象。
复用也是一样。复用本来是通过消除重复的方式。得到一系列可以复用的组件。从而在未来的开发工作中，更快速的响应需求变化，也就是所谓的提升响应力。
然而很多复用的结果，会造成代码是变少了，改起来却更难了。复用是增加了，可读性却下降了。考虑到软件开发是一个团队协作的工作，而我们这个行业的离职率又能到百分之二十之多。难以学习的代码确实是难以维护的，尽管你可以抱怨接手的人无能，但总之是降低了响应力，也就违背了复用的本质。
什么情况下会出现这样的场景呢？主要是因为视角的单一，只从自己单一的视角看到了重复而不是在做全局优化。这个说法可能稍微有些抽象，那我说几个相对具体的情况。
当我们只关注功能视角的时候
需求有很多的描述视角，可以只在功能角度描述，比如“网站要有任务卡，任务卡上有文字版学习内容，视频讲解、也有作业题。”也可以加入业务视角，比如“学生要报名特训营，才能参加特训营。学生进入特训营后，就看到了任务卡列表。学生在任务卡上阅读学习资料，阅读完学习资料后做题来验证他是否学到，做完后提交交由助教审阅。”当我们只看功能视角的时候，可能会忽视业务上的不同，变的在功能角度过分抽象，最后当业务变化的时候，反而响应速度比较弱。
一个简单的后台，我们看起来所有东西长得都一样，不过是列表页面，添加页面修改页面，再加点儿删除什么的功能。说穿了都是crud，干脆我把这事弄成一一个组件好了，每个页面只需要简单配置一下，就可以出来自己的一套，增删改查页面。
这种视角完全没有考虑到，不同的实体，它们其实所在的业务是不一样的，关心它们的人也是不一样的。最后，彼此的演化方向也总会出现一些不同，你把它定义成一种东西，对于我每做一个修改，都要背负着其他所有实体的特异性。于是就逐渐拖慢了我改变的速度，降低了响应能力。
无谓的自动化
有追求的程序员一定会考虑提升工作效率，通过一些自动化的手段来缩短流程，提高效率。不过有时候，这种追求也会有害。
在我们的系统里有一个面包屑功能，就是典型的“页面A / 页面B / 页面C”那种面包屑。团队成员提出，一个个页面写面包屑好烦啊，干脆做一个根据URL生成面包屑的功能吧。乍一看好像提高了效率，但实际上URL上的名词和你想显示在面包屑上的名字是可能出现不同的。
比如在我们的场景里，我们提供一个任务卡的预览功能，你的面包屑可能是“xx后台 / xx 训练营管理界面 / xx卡预览”，而学生正式使用任务卡的时候，他可能是 “ 学习中心 / xx 训练营 / xx卡 ”。而他们的url里可能都会出现'/programs/$pid/tasks/$tid'。同样的program、task翻译出来的文字完全不同。你为了支持这点不同，又要扩展一些额外功能来做这种区分，做来做去，可能还不如直接写来的方便，至多抽几个常量来简单的消除一下重复。
当我们只从代码上看重复性的时候
这个我就不举例子了，其实很多犯这个错误的人都是重构的支持者，不过学艺不太精。因为如果你仔细看的话，重构里好多怀味道都有一个跟他对立的怀味道，比如发散式变化和霰弹式修改。如果我们只看代码就会违背复用的本质——更好的响应变化。
这个跟我说的第一个场景，只关注功能视角是类似的问题，这个可能更具象一点，只关注代码。
无视上下文的时候
这个可以看作是只有功能视角的一种情况，很多功能我们觉得有重复性，提升成一个概念，然而其实根本是两个东西，他们只是刚好叫一个名字。
比如过去很多软件里，是有一个统一的用户组概念，不管你在哪个业务上下文里，你都需要扩展这个用户组的概念来管理用户的权限。这个带来的结果就是用户组变得越来越臃肿，每次修改都要改一下别的组的功能。在我们的网校数字平台里，学生学习有学习小组，老师出题有出题小组，这两个小组业务完全不一样，这个时候如果都用统一的用户组来管理的话，那就势必会造成无谓的耦合，损害响应力。
这些故事告诉我们，我们不是在真空里去做复用。我们做的软件都是有它的商业目的。我们的工程实践也都是为商业目的服务的。当我们说tech@core的时候，让我们说技术就是业务的时候。诚然，他给技术人员带来了更多的权利，然而权利越大，责任也越大。技术人员也需要跳出技术，具备更多的业务视角和体验视角。而不仅仅是沉浸在技术得自high当中。才能真正的发挥出各种实践的价值。
