前端开发与组件库
在一些小公司的项目开发中，我们可能常常听到这样的想法：
- 我们公司的需求比较特殊，用现有的组件库不够灵活，不如自己封装一套！
- 现有的组件库样式不符合我们的产品需求，我们需要统一风格和功能，不如自己开发一套组件库吧！
以前我会很天真的支持这样的想法，现在，我会给提出者一个大嘴巴子！看似高瞻远瞩，实则全是陷阱，甚至可能成为整个团队的噩梦。
一个loading组件引起的生产事故
我先讲一个我们公司因为组件库导致的财产损失生产事故！
之前，我们业务有实现过一个表格，由于接口非常快，我们并没有增加loading样式。
代码实现也非常简单：
<template>
<section class="table-section">
<m-table :columns="columns" :data-source="tableData">
</m-table>
</section>
</template>
<script setup>
const tableData = ref([]);
const columns = []
const getTableData = async () => {
// ...接口调用逻辑
queryManageList()
};
// 获取表格数据
getTableData();
onMounted(() => {
// 动态设置表头数据
columns = []
});
</script>
m-table是我们公司的内部表格组件，上面的代码在生产稳定运行。随着数据的增多，接口有些慢了，于是客户希望加个loading。
我们公司的Loading组件模仿自Elemnet Plus，api的调用也非常相似
参考文档，代码的更改也就非常容易
<template>
<section class="table-section">
<m-table :columns="columns" :data-source="tableData">
</m-table>
</section>
</template>
<script setup>
const tableData = ref([]);
const columns = []
const getTableData = async () => {
loadingInstance = Loading('.table-section');
// ...接口调用逻辑
await queryManageList()
loadingInstance.destroy
};
// 获取表格数据
getTableData();
onMounted(() => {
// 动态设置表头数据
columns = []
});
</script>
代码看着严丝合缝，十分完美，然而，部署生产后，发现columns直接没了！
经过线上排查，发现loadingInstance = Loading('.table-section')这段代码直接替换了section标签内部的所有dom元素，造成表格的vue实例出现异常，onMounted钩子根本没有执行！
反观Element PLUS，人家直接是在section标签下生成的遮罩层，就不会存在这个问题！
小公司开发的组件，由于开发者技术参差不齐，很容易出现线上问题啊！这种问题在我们的日常开发中非常常见，害人啊！
为什么小公司不要轻易封装组件库
通过上面的案例，可以看出：小公司的开发人员技术参差不齐，组件库的质量也就无法得到保证。当然，技术还不是主要原因，毕竟技术是可以提升的，但下面的几个问题才是真要命的！
资源不足：人力和时间的双重消耗
封装组件库并非单纯的开发任务，它需要大量的人力和时间投入。对小公司而言，团队往往规模有限，开发资源紧张。
- 开发人员：为了封装一个组件库，原本负责业务开发的人员必须抽出精力进行组件封装工作，业务开发的进度被迫拖延。
- 时间成本：开发一个组件库不仅仅是写几个按钮或者表单，还涉及到设计体系、文档编写、单元测试、性能优化和浏览器兼容性处理等，这是一项长期工程。
就拿我们公司举例，我们一遍要写业务代码，一遍要维护组件，非常消耗时间！
就这，公司还不断地给我们加任务，把我们当牛马，直接开启996！
加班费没有我们就忍了，996一次不够，还梅开二度！
业务开发都没时间，还维护组件库，这不是自己坑自己么？ 小公司没钱没实力，再别开发组件库了，来来回回坑自己人！
维护成本高：一时造轮子，一世修轮子
自己封装组件库容易，但长期维护它却很困难。随着项目的迭代和需求的变化，组件库也需要不断更新和优化。
- 需求增加： 业务需求多样化导致组件库功能膨胀，原本简单的组件变得复杂不堪。
- Bug 修复： 自己封装的组件库缺乏大规模使用的验证，隐藏的 Bug 往往在上线后爆发，修复工作耗费大量时间。
- 兼容性问题： 浏览器兼容、新技术支持（如 Vue 3、React 18）的适配工作更是让人头疼。
我们的组件库更新非常频繁，因为随着产品的迭代，要增加很多新功能。有时候，为了使用组件的新功能或者样式，我们不得不升级组件版本。然而，有一次升级后，组件库内部存在严重bug，导致我们原有的许多界面崩溃，造成了重大生产事故！
这种组件升级导致的页面问题时常发生，加了一个功能，导致一个隐藏bug，后续为了解决这个隐藏bug，又引入其他bug，最终一个小功能要发好几个组件版本才能解决。我已经无力吐槽，害人啊！
而且，由于组件的功能不完善，经常要花费非常多的沟通成本
技术负债：短期便利，长期拖累
自建组件库在开发初期可能感觉很“顺手”，但随着项目规模扩大，组件库的缺陷会逐渐显现，成为团队的技术负债。
- 缺乏标准化： 自建组件库的规范不够完善，不同开发者在实现同一功能时可能写出风格完全不同的代码。
- 文档不足： 由于时间和人力限制，自建组件库的文档往往不完善，后期新成员加入时难以上手。
- 升级困难： 自建组件库的每次升级都可能影响到现有业务，增加维护和测试成本。
员工离职风险：组件库成孤岛
小公司人员流动较为频繁。
如果负责组件库开发的员工离职，组件库很可能会变成“孤岛”，无人维护，直接影响到项目的可持续性。
经济形式不好，我们公司近几年也裁了不少员，导致一些组件直接没人维护了，直接影响项目进度。
所以，资金、时间不充足，咱小厂还是别学大厂维护组件库了，要钱没钱，要时间没时间，来来会会坑的都是自己！
总结
封装组件库对小公司来说是一个高风险、高成本、低收益的选择。本人建议如下：
- 优先选择成熟的开源组件库： 如 Ant Design、Element Plus 等，它们功能完善且生态丰富，能够快速适配业务需求！
- 定制而非重造： 如果开源组件库无法完全满足需求，可以在其基础上进行二次封装（各位leader注意看，组件库基本都支持样式定制的！） ，而不是从零开始构建。
- 聚焦业务： 小公司开发团队的首要任务是满足业务需求，组件库的开发应该是锦上添花，而非拖慢进度的负担。
各位Leader注意，技术的最终目的是为业务服务！别为了凸显自己牛逼，强行开发维护一个组件库，最终只会害人害，搬起石头砸自己的脚！
小公司不要让组件库拖住脚步，把资源投入到更有价值的地方，才是发展的正确道路。
啥也不是，散会！
