前端开发与组件库
在一些小公司的项目开发中,我们可能常常听到这样的想法:
- 我们公司的需求比较特殊,用现有的组件库不够灵活,不如自己封装一套!
- 现有的组件库样式不符合我们的产品需求,我们需要统一风格和功能,不如自己开发一套组件库吧!
以前我会很天真的支持这样的想法,现在,我会给提出者一个大嘴巴子
!看似高瞻远瞩,实则全是陷阱,甚至可能成为整个团队的噩梦。
一个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注意,技术的最终目的是为业务服务!别为了凸显自己牛逼,强行开发维护一个组件库,最终只会害人害,搬起石头砸自己的脚!
小公司不要让组件库拖住脚步,把资源投入到更有价值的地方,才是发展的正确道路。
啥也不是,散会!