谈谈前端流行病：胖组件

　　"屎山"这个词虽然流行，但过于情绪化，难以准确描述技术债务问题。我更愿意将其比作沉重的包袱：开发者必须背负它前行，连呼吸和思考都受其拖累——这才是技术债务的真实体验。闲话到此，下面分享我在前端项目重构中的实践心得。

　　“胖组件”是我给不合理使用组件式框架产生结果取的名字，简单说就是项目里全是组件，除此之外的代码很少，这种情况通常意味着组件存放着很多代码，就像吃了太多到肚子里的大胖子，不能灵活行动，而我的观点是：胖组件难以被复用。看到这里我想很多前端开发者会觉得这个结论武断，先别着急辩论，我们一起看个例子。

　　例子1，将接口调用放到组件中，如果没有别的需求用到该组件似乎是合理的，虽然咱们都无法预测未来是否有这样的需求，但不难推测一旦出现这种需求，为了复用就要先从原组件中抽离出接口调用代码，再调整组件外观（可能需要），所以保险起见还要测试之前用了此组件的地方，这里抽离接口产生了超出预期的开发和测试工作，算作影响复用很合理吧。

　　有人说我才不会把接口调用写组件里面，但我不觉得胖组件会影响复用，首先我得表扬你，因为你没有将输入数据和组件耦合，让组件可以适用于更多的数据输入场景。其次我得说，咱再看一例。

　　例子2，我把接口响应后的数据转换/计算处理放组件里。你看这回没在组件调用接口吧，但是同一接口未来用于其他组件时用到相似响应数据处理，是不是就得先抽离出响应处理逻辑，这时候又会增加非预期的开发和测试成本。哎，你说万一没这样需求，我预先把它抽离出去不就白做了嘛。这和上次咱说的一样，我们谁都无法预知未来，先抽离属于是未雨绸缪，好比出门带伞的习惯。

　　有人可能会说，你举例都举不到我这来，干嘛说胖组件影响复用。咱接着举例，这回是打开文件，前置条件是文件格式，文件大小，然后上传符合条件的文件到服务器，你说这都写到上传组件合适吧。对了，咱这回把上传接口给它先抽出去，输入数据不和组件耦合，输出数据也不耦合，没毛病吧。假设未来做个打开文件预览的功能，前置条件一样，要想复用检查逻辑。有人说等会儿，就那两句还复用啥，我说它如果用文件内容的魔术数字更精准判断格式呢。有人会说我抬杠，那我要说咱都无法预测未来，需求真来了，要抽离代码，这又是非预期的开发/测试工作量，这我算影响复用不勉强吧。

　　有人还会说，抱歉先打断一下，这次多举些例，减少反复模拟对话。比如说：同样数据在PC和移动端呈现不一样；同样数据处理完后保存在idb中；队列缓冲数据依次处理；定时加工队列数据；自定义排序算法；扁平化树结构；状态数据转换；依据状态计算样式属性对象或字符串……

　　这么抽下来你会发现项目代码越多，非组件代码越多，扩展时非预期工作极少，组件复用看外观和基础数据结构，没有奇怪的内部数据处理或控制逻辑影响，除此之外还有大量预先抽离的公共函数任意挑选、组合，是不是比起文章开头称为“屎山”项目维护起来轻松。

　　当然还有人会告诉我，他用胖组件不预先抽取公共函数，新的类似需求来了，复制粘贴原来组件代码再改改，不会出现非预期的开发/测试工作量，还能提高代码产量，你说机灵不机灵。要我说他这种迷宫构造家是有大智慧的，毕竟代码和他总有一个能功成身退，他一跑，这由他种下因就会变成接替者的果，属实把佛家因果报应学说想明白了。

　　总的来说胖组件项目的终极形态就是复制粘贴流的极致，正印证那句“做大做强，再创辉煌”，今朝的一个胖组件，待明日就是后来人头上的一座山，至此我们仅能送出祝福“要无条件相信后来人的智慧”，解决了它就是智慧，后来者会深深记住胖是福气，是他智慧迸发的源泉，至此，再次感谢胖组件和它们创造者。