交代下背景
公司背景：有自己的业务线，类似有赞外包服务的套娃功能，提供给企业一些H5，小程序，PC和各种独立的线上业务功能。
个人背景：Vue重度用户，react轻度使用，jquery用过几年后来退休了，uni-app正在使用，其他的框架或者类库不熟悉。
近期工作（覆盖面应该来说比较广了）：
- 把使用uni-app的微信小程序项目转换成了H5项目（做兼容处理）
- 同时修改一个PC端项目，功能于H5类似，使用的是Vue全家桶作为技术栈
- 该PC项目内嵌了一部分iframe页面，该iframe页面技术栈为jquery，两个页面间有一定的交互
开发遇到的问题：
- 登录功能多端维护，需要同时维护小程序、H5、PC（jquery写法，Vue写法）的登录功能，功能类似
- 活动分享功能多端维护，小程序、H5、PC分享各不相同，各个端代码风格和技术栈都不一致，但功能类似
- 主业务功能，小程序、H5、PC代码风格和技术栈不一致，功能类似
- 不同的技术栈使用了功能类似，但风格差异的第三方轮子
同时维护多个端，各种风格迥异的代码很麻烦，虽然主要功能都大致一样，不过因为不同技术栈带来的代码风格差异和逻辑的差异，导致了各个端都在重复出现一些类似的bug。
后来想到解决办法：
1、区分各端功能的异同，抽离登录和分享和主业务线的相同功能，封装成不同的方法，通过传参或者通过构造函数来继承、递进完善功能。
2、使用原生JS来实现各个端类似的功能，这里就不用再考虑各端技术栈带来的难题，单独来维护这些公用的组件，上传到CDN供各端项目调用（或者建立自己的npm仓库）。
3、使用rollup或者webpack来打包成多种类型的代码包。
4、建立简单的说明文档，各个函数对应的功能和参数，和代码风格解释以及要求，方便其他同事阅读和理解代码。
实际开发的心得：
一份代码多端使用是理想的状态，现在社区有很多开源的库正在做这件事，类似flutter，uni-app等，他们都做好了功能的封装，一些api可以再多段调用，但不同的业务功能他们就无能为力了。
如果考虑到多端开发的话，那么业务的差异是必不可少的需要考虑的问题（典型的第三方登录方式，多端就有不同的表现和实现方式，PC可能要展示的功能也比手机端的要丰富很多，小程序和手机端H5的业务也很大可能有差异）。
比较理想的解决方式就是封装自己的业务组件库了，各个端不必去在意公用方法的差异性，而专注做自己的业务。建立组件库开始可能有些难度，需要花几天的时间去考虑拓展和打包环境以及部署的问题，不过建立之后就提供了更多的便利，磨刀不费砍柴工的道理。
公司发展更多的业务线也会提高开发效率（通用功能套娃生产），降低了维护成本，对于不同的技术栈（比如老项目还在使用的jquery代码也能马上使用到新的功能，vue、react、augular都能更好的兼容），拓展新的业务（以前没有PC功能，现在拓展了PC业务）都能更稳定的使用，提高效率且保证了功能的稳定性。
如果只专注于做一个端的项目，那维护这些组件可能就弊大于利。但可以考虑到的做业务功能时尽量少的依赖于类库，如果功能太过于依赖vue或者react，那以后全站转成angular了就太麻烦了，历史的车轮一直在转动，代码变化和更新是一直需要维护的，说不定明年前端三大框架就变成了历史的尘埃，而积淀下来的JS业务组件却可以长期的使用下去，工具终究是工具。
解决问题之后的思考
自己确实是vue的重度用户，之前考虑到做一套自己的vue组件库，现在想想意义并不大，维护自己的组件库太浪费时间了，公司做用户端的产品样式和界面展示也各不相同，各个端技术栈的展示也各不相同。做基于XXX的组件库有点局限了，换个技术栈就全盘蹦，产品换个样式和整体风格也得要半条命，如果恰好你也有做这个的想法请考虑下自己是否真的有精力去维护这些差异和技术栈的变化。
第三方库只是工具，能够使用、学习其优点，化作自己的知识才能算做进步。过度的依赖第三方工具而忽视最基本的实现原理，过几年时代变了，技术大更新，年纪也大了，混口饭吃都难了。
最后，枪会用，自己也要能打。
