最近公司里事儿比较多，项目也比较杂，但是因为公司的项目主要是聚焦OA方面，很多东西可以复用。
比方说：表单、表格、搜索栏等等，这部分现阶段大部分都是各写各的，每个项目因为主要的开发不同，各自维护自己的一份。
但是领导现在觉得还是维护一套组件库来的比较方便，一来是减少重复工作量，提升开发效率，二来是方便新人加入团队以后尽量与老成员开发风格保持一致。
另外还有一个原因是项目内现在有的用AntDesign，有的用ElmentPlus，这些库的样式和UI设计出来的风格不搭，改起来也非常麻烦。
我听见这个提议以后后背冷汗都下来了。
我再跟大家强调一遍，不要封装组件库！
咱们说说为什么：
抬高开发成本
大部分人都感觉封装组件库是降低了开发成本，但实际上大部分项目并非如此，封装组件库大部分时候都是抬高了开发成本。
项目不同，面对的客户不同，需求也就不同，所以无论是客户方的需求还是UI设计稿都存在一定的差别，有些时候差距很大。
针对项目单独进行开发虽然在表面上看起来是浪费了人力资源，重复了很多工作，但是在后期开发和维护过程中会节省非常多的时间。
这部分都是成本。很多时候组件的开发并不是面对产品或者团队的，而是面向项目和客户的。
这也就导致了组件的开发会存在极大的不确定性，一方面是需求的不确定，另一方面是组件灵活度的不确定。
很多时候开发出来的组件库会衍生出N多个版本，切出N多个分支，最后在各个项目中引用，逐渐变成一个臃肿的垃圾代码集合体。
我不相信有人会在自己的项目上改完以后，还把修改的部分根据他人的反馈再进行调整，最后合并到 master 分支上去。
我从未见过有这个操作的兄弟。
技术达不到封装水平
团队内部技术不在一个水平线上，事实上也不可能在一个水平线上。
有些人的技术好，封装出来的组件确实很契合大多数的业务场景，有些人技术稍逊，封装出来的组件就不一定能契合项目。
但是如果你用他人封装的组件，牵扯到定制化需求的时候势必会改造，这时候改造就有可能会影响其他项目。
尤其一种情况，老项目升级，这是组件库最容易出问题的时候。可能上个版本封版的组件库在老项目运行的非常完美，但是需要升级的项目引用新的组件库的时候就会出现很多问题。
大部分程序员其实都达不到封装组件库的水准。
如果想要试一试可以参考ElmentUI老版本代码，自己封装一下Select、Input、Button这几个组件，看看和这些久经考验的开源组件库编码程序员还差多少。
技术负债严重
承接上一个问题，不是团队内每个人的水平都一样，并且每个人的编码风格也都是不一样的。(Ts最大的作用点)
可能组件库建立初期会节省非常多的重复工作，毕竟拿来就用，而且本身就是封装好的，简直可以为自己鼓掌了。
照着镜子问这是哪个天才编写的组件库，简直不要太棒了。
但是随着时间的推移，你会发现这个组件库越来越难用，需要考虑的方面越来越多，受影响的模块越来越多，你会变得越来越不敢动其中的代码。
项目越来越多，组件库中的分支和版本越来越多，团队中的人有些已经离开，有些人刚来，这时候技术负债就已经形成了。
更不要说大部分人没有写技术文档的习惯，甚至是连写注释的习惯都没有，功能全靠看代码和猜，技术上的负债越来越严重，这个阶段组件库离崩塌就已经不远了。
新项目在立项之初你就会本能的排斥使用组件库，但是对于老项目呢？改是不可能改动的，但是不维护Bug又挂在这儿。
那你到底是选择代码能跑，还是选择...
对个人发展不利
有些兄弟觉得能封装组件库，让自己的代码在这个团队，这个公司永远的流传下去，简直是跟青史留名差不多了。以后谁用到这个组件都会看到author后面写着我的名字。
但事实并非如此！
封装出的组件库大部分情况下会让你"青💩留名"，因为后面的每个人用这个组件都会骂，这是哪个zz封装的组件，为啥这么写，这里不应该这么写嘛？
如果你一直呆在这个公司，由你一手搭建的这个组件库将伴随你在这个公司的整个职业生涯。
一时造轮子，一辈子维护轮子！
只要任何人用到你这个组件库，遇到了问题一定会来找你。不管你现在到底有没有在负责这个组件库！
这种通用性的组件库不可能没有问题，但是一旦有了问题找到你，你或者是解决不了，又或者是解决的不及时，都将或多或少的影响你的同事对你的评价。
当所有人都对你封装的这个组件库不满意，并且在开组会的时候提出来因为xx封装的组件库不好使，导致了项目延期，时间一长你的领导会对你有好印象？
结语
希望兄弟们还是要明白，对于一个职场人来说，挣钱最重要，能升上去最重要。其他的所有都是细枝末节，不必太在意。
对于客户和老板而言，能快速交付，把钱挣到手最重要，其他也都是无所谓的小事。
对于咱们自己来说，喜欢折腾是程序员的特质，但是要分清形势。
