前端目前的问题和2021的计划
问题
资源一定是永远不够的；如果能感觉到资源过剩，那就会出现裁员了。
资源不足的情况下，业务方肯定是不满于开发进度的，这种情况下，我们做的东西一定要考虑好如何做量化的价值体现，否则做了说不清，等于白做，业务方只会感觉开发一直都不靠谱。
基建问题
基建不完善，没有形成一个完整体系，涵盖整个产品开发和运行周期
我们的基建都很散，很多都是针对某个具体的小点的，而没有形成一个系统。我们去年之前，连一个大家达成共识的基建架构图都没有；后来有了架构图，但是里面也有很多东西还没实现，且可能部分内容也过期了。
这样会导致我们的基建比较零散，缺乏整体目标，东搞搞西搞搞，头痛医头脚痛医脚。最终发现好像投入了不少精力，但是整体的情况并未得到很大的改善。
就像去年年初我们针对前端问题的改进，也做了一些事情，但是好像也并未带来很大的改变。
基建不够智能化、工具化、自动化
现在每个组的很多基建和经验，都是绑定在人或者文档上面的，接入成本高，且容易过期或者丢失。
我们应该把基建中的很大一部分，绑定在我们的开发流程和发布流程中不可跳过的一些环节。比如代码规范，完全可以通过 git hooks 在提交的时候保持一致性；代码质量和安全检查，也可以在 CI/CD 环节自动处理掉。这些其实早就有人提了，但是一直没有真正落实下去。
像我们的各种组件库(UI 组件、业务组件、可视化组件、SDK)，也完全可以通过 VSCode 插件在项目初始化的时候就进行推广使用。
非专人推进和开发，资源不稳定
我们都是业务优先，业务需求比较紧张的时候，负责基建的人就去搞业务了，导致进展非常缓慢。这种情况从组件推进上就能很清晰的感觉到。
缺乏前瞻性
我们探索性的内容很少，基本上都是外面有了成熟的，我们再引入进来；这样当业务和规模高速发展的时候，就会感觉技术的提升速度跟不上业务的扩展速度了。
高手太少
业务开发之外的能力较差
从我们前端平时的一些分享也能感觉到，有厉害的人，但是前端人员整体的水平确实有待提升。
人员流失严重
技术稍微好一点的人员，频繁流失。
跳不出“前端”的限制
后端有很多开发都了解或者会一些前端，但是反过来，前端开发人员绝大部分都局限于前端，对于后端的内容基本不了解，对于整体的业务和技术架构也不了解。
形成对比的就是阿里的前端，不只是前端，更是“工程师”。
没有前端驱动的“产品”，导致前端受重视程度不高
参考阿里设计体验部，由前端驱动产出了各种产品(ToC 的语雀、ToB 的 DataV、面向开发人员和运营人员的 ice work、设计语言和组件库 Ant Design 等等)。
2021 可以做的事情
基础组的人员吸收机制
从业务开发中，发现有潜力、有想法、感兴趣的人，加入基础组(虚拟组也行)，逐渐专职进行基础工具平台的开发和推广。
否则我们有那么多想法，没人做，也没用。
从今年组件推广的过程中，是能感知到有一些同事是对基建感兴趣的(比如基金的胡佳磊、猎金的周继源等)，只是由于组内业务开发的压力较大，抽不出来太多精力做。
统一的知识搜索工具
这是为了解决两个问题：知道与一致性。
知道是指每个人遇到问题的时候，都能够快速找到解决方案或者至少明白该从哪里、从谁那里寻找答案。
一致性是为了让大家知道我们已经有哪些轮子了，都采用一致的规范、组件、工具、平台，避免大家自己重复去造轮子。
我们可以不限制文档的编写工具，但是提供一个统一的搜索平台，可以接入公司不同文档系统的搜索功能；另外可以考虑统计常用的搜索问句，这些常用的问题应该就是我们要优先解决的问题。
这里有个案例：我们组的新同事有一些项目遇到了移动端兼容性问题，然后处理起来非常头疼，没有一个地方能找到高质量的、完善的和公司业务结合的移动端兼容性问题的解决方案(常见问题有哪些、出现问题该怎么定位、该用什么工具平台调试、这些工具平台该怎么用等等)，顶多能找到零零散散的一些文档，而且就这也还得靠运气。
基建
脚手架/VSCode 插件
做这些的目的主要还是解决一致性问题，包括编码规范、组件应用等等。
编码是开发人员跳不过的一个东西，我们可以用这个做很多事情，比如项目初始化、规范嵌入、组件和工具的推广、更新提醒、自定义的检查等等。
组件库
这是前端提效和提质性价比最高的内容。去年年初我们就已经分析讨论过了。
四大组件分类(UI 组件、业务组件、可视化组件、各端 SDK)。
这个可以找一找去年分的类别。
这块经过去年的努力，虽然还不完善，但是也算有一定基础了，2021 年肯定要继续重点做下去。
发布流程
这一块也是不可跳过的环节，很多内容可以放这里执行。
目前已经有了，只是在易用性和规则上，还需要完善。