浅谈“过度封装”

干了很多很多所谓的“敏捷”开发的项目之后，对于封装组件有了新的看法，在这里和大家分享一下

为什么要封装组件

封装组件可以复用共通的代码，增加可读性，可以统一UI样式，可以十分方便的管理代码结构。这是所有同学都知道的封装代码的好处，特别是当公司遇到需要“敏捷”开发一个项目，封装组件可以帮助我们提高效率(为了绩效)

往往我们就会选择开源的成熟的好用的组件库（element-ui、ant design等）这些组件库帮助我们开发的同时，也帮助我们更加高效的完成任务。

但是每个人对使用组件库的理解都不一样，很多可以使用组件库中的组件的地方自己反而会手动实现，虽然看上去像是实现了效果，但是严重的破坏了代码结构，极大的增加了后续的维护工作量，对于这些封装往往都是“过度封装”

浅谈“过度封装”

“过度封装”在不同的项目组同学中都有不一样的理解，但是很难有一个标准，我封装的这个组件到底算不算“过度封装”呢？

以上是我对一个组件是否是“过度封装”的理解，也可以判断一个方法是不是“过度封装”

对与项目中已有的组件做二次封装的封装可以算是“过度封装”

当我作为后续开发接手一个快要离职的同事的代码时，往往会在components文件夹里看到很多针对element-ui（antd、等其他的组件库）的table组件做的二次封装

这类的封装往往伴随着一些不够灵活的问题。当一些特殊的页面需要不一样的table设置时，往往需要修改组件的带啊才能支持使用，当这个table支持了很多不同页面的个性化需求之后，大量的props没有一个文档说明后续开发人员要阅读这个封装的组件的源码并熟悉之后快速使用。后续维护产生了大量的工作量，十分不友好。

手动实现一个组件库中存在的类似的组件在项目中使用可以算是“过度封装”

有时候设计稿中出现一个组件和组件库中的很像，但是存在差别的时候，我们需要思考一下，组件库中的组件是否完全支持我们的功能（可以多看看文档上的props，或者打开在线编辑器，调试一下看看），而不是看着有一点点的差异就手动实现一个，比如：tag标签组件、image图像组件等等在项目中基本不去使用，往往直接使用原生标签就手动开发了。

不仅仅是组件当中存在这类问题，封装方法的时候也存在这里问题，明明项目导入了lodash、momentjs、dayjs等库，反而在utils中手动实现formatDate、formatTime、节流防抖、深拷贝等方法，实在令人费解。

关于样式封装

关于组件的样式是最难封装的地方，往往开发到最后每一个文件里面就会出现一大堆的修改样式的代码

就算是在统一的样式文件中同意修改还是不免出现超长的修改颜色的各种代码

对于element-ui实在硬伤，摊牌了、我不会了🤷🏻‍♀️

所以我推荐使用naiveUI开发，对于样式的处理绝对的一流，加之vue3使用hooks配合组件，开发体验也很不错😎，（arco Design、antd 现在处理统一的样式风格也是很棒了）

总结

简单聊了一下“过度封装”，希望这种代码不会出现在大家的代码当中，不要去封装 my-button、my-table 这种组件，世界会更加美好。(^▽^)