前端5年了，依然小白，总结一下，欢迎交流。
成长之路
15年开始做前端，最开始就是商城，从0到1的经历，非常痛苦，也成长迅速，摸熟了研发的整个链路。
刚开始，还是juqery，开始用requirejs、seajs、fix这些模块化工具，有了模块的概念。
后来，就开始学习各种框架，先从angular开始、再react、然后vue、最后是各种衍生框架。
再后来，学习TS、Graphql、Mico Frontend、Serverless...
一点思考
前端需要关注的东西越来越多了，新的技术层出不穷。要想在旧的业务线落地使用，成本是极高的，重构项目就要有复杂的框架、配置升级，一个项目可以慢慢改，很多个呢，成本可想而知。可以用cli自动升级，但是不同项目能保证稳定运行不遗漏隐藏bug么。特别是在基础设施不完善的时候，没有测试，没有场景验证，怎么保证项目重构不是在引入新的bug呢。
所以，作为一个前端，我该怎么做？
一些框架
这里是对一些框架的学习和应用，绝无评论的意思，框架的形成依赖于实际的业务线，不了解实际情况就不适合点评。
团队人力充裕可以自己维护脚手架、组件库、cli甚至研发系统，但是对于前端小团队，这些成本显然太高，于是使用现成的就是主流了。
首先是nextjs，经过了很多人的检验，还是很方便的，省去了不必要的时间去研究webpack配置、babel、ts等等，能满足所有的业务需求，也支持了serverless，对于微服务也能实现（虽然只是类似nginx的转发）。
但是对于一些使用上总会有些限制，举个例子：
- nextjs 9.0对tsconfig有强制要求，mudule比如是esnext，但是当我同一个项目还有node实现的server层的时候就比较头疼，只好给这个server单独的tsconfig配置了；
- 再比如当我把pages移到别的目录的时候，static静态文件放到哪里都不能正常访问。
- nextjs有个默认meta配置允许移动端可缩放，所以当我不管怎么在_document里配置都没作用，原来是要body里配置才能覆盖掉
总之，瑕不掩瑜，它带给我的遍历远比带来的烦恼多，让开发更加顺畅。
后面说一下Umijs，这是个我非常看好的框架，虽然用的不多，但我非常喜欢他的开箱即用的block和umi ui的理念，让开发环境搭建修改非常便利，也让模板共享很顺畅，对于中台类开发简直就是神器。当然也有一个不足，文档不够体系化，有些默认配置可能都不能从文档里找到，因为有太多的约定没能很好地检索查看。
总之，这个方向非常棒，如果你需要一个antd pro的开箱即用的框架，那么选umijs没错了。
再看看uni-app，随着跨平台成为主流之后，移动端小程序遍地开发，人人都想退出自己的小程序轻应用。对于开发者来说就是个噩梦一样，就像当年微软退出IE一样吧，大家都自己定制标准了，随来迎合这些不同的标准，肯定是开发者了。所以就有了很多跨平台框架，我也就用过wepy、Taro、Electron和这个uni-app，最后可能还是更喜欢uni-app，挺方便的，能省不少事，不足可能就是不能用厂商提供的serverless，太过依赖本地开发工具和环境。
也用过其他衍生框架，主要是vue和react两个系列吧，这里只说这么多了，框架真正的好坏还是要看业务需要了。
一些工具
前端一个人的时候可以尽情造，自己挖坑自己挑。当有一堆人的时候，怎么更好的协同，首先要有规范，再借助一些列工具让协作更流畅。
首先是规范，前端肯定是eslint了，通过一系列配置，约束代码编写方式，培养良好的编程习惯是必不可少的。开始我们用fecs，后来发现并不是很好用，经常格式化乱码，然还有还有一些比较诡异的约束条件。所以后来切换到eslint，开发流畅了很多，但是有依然有问题，就是类似代码，eslint不能保证风格统一。于是引入了prettier，真香系列，代码格式化出来都是一样的，结合eslint做一些规则warning，还是很方便的。再结合ghook提交前验证让提交到repo的代码基本没有格式问题。
再就是文档，文档是沟通的基础，有了好的文档，沟通事半功倍。前后台沟通一直是个痛点，经历过很多API文档工具，wiki、eolinker、swagger、yapi，最后定格在yapi上，私有化，二次开发，然后推广到公司内部。虽然yapi也有很多场景无法满足，但至少摸索出了一套行之有效的文档方案，让开发沟通效率极大地提升。当然除了API文档，还有项目文档、框架文档、使用文档等等，方便新人学习沟通，也能让个人总结提升。
然后呢，框架、CLI么，是的这些都是标配了，不管团队大小有希望有自己的脚手架、CLI，只是适应不同的业务需求各自有侧重点，就没必要拿出来标榜。我想说的是如何实现跨项目组件/页面共享，打造属于自己的研发系统。
那么bit.dev出场了，通过方便的导出方式，把项目中已有的组件/页面导出到仓库，可以在其他项目中方便的引入，导出的时候默认会统计依赖，以方便通过compiler编译产出，当然我还没有探索那么深入，只是共享组件源码而已。至少这是一个非常可行的方案，可以让我方便的在不同的项目更新同一份组件/页面的代码，以实现跨项目共享。
当然，bit提供的能力远比这强大得多，针对组件共享、渲染、测试都有一系列的支持。我还没有尝试过，但就这个对于组件的管理方式，还是很有棒的，也将会继续探索。
再说一下piral，这是我理想中研发系统的雏形，针对项目维度的中台管理，对于组件/页面维度的Feed Service，让微服务、Serverless开箱即用变得不再遥远。个人认为，与其对项目单独管理维护迭代，不如对组件/页面进行更加聚焦的开发测试迭代。让框架消于无形，针对组件可以有更大的发挥空间，可以不同的框架、语言、代码，但是殊途同归，都是要放到相同的环境中运行的（也就是项目的环境）。
这个，还没有成熟的实践，只是探索阶段，分享只是表达理念。
一些想法
关于前端，技术迭代比较快，项目越做越大，想要重构升级越来越难，推翻重做可能也不太现实。如果能方便的有一套研发系统，迁入进去，针对组件/页面做更小粒度的重构升级，会不会更加顺畅。
我是一个前端，希望能给这个职业带来一些改变。
