点我达三年前端路暨点我达前端演变过程

前言

2016年8月份，我开始了人生第一份前端工作。直到今天，快满三年，愈发有些东西不吐不快。三年的前端变化很快，感觉应该重新认清将来的方向，整理整理三年工作所得，为下一个三年谋定而后动。在点我达三年的前端生涯，同时也是点我达前端架构演变的三年，自己亲身经历了这些变化，可以说是非常幸运的。自己从一个前端菜鸟成长成能够独立负责并带领网关团队的前端老鸟，对一个创业公司如何从零基础的前端生态演变到一个比较完整的前端生态有了清楚的认识。同时也在这个演变过程中发现很多问题，这些问题必然会一直存在，直到彻底解决。

本文以点我达前端演变的过程为主线，附带提及一些想要说的感受。

1、点我达前端三年演变进程

上图简单地描述了演变的一些重要节点，从最开始的前后端紧密耦合到第一次应用nodejs，后面引入微服务化后，前端承担起网关的开发与维护，无时不刻在提醒我们：前端能够胜任的工作会越来越多~

接下来详细说说每个演变过程

1.1、原始混沌状态(2016年)

初到公司(2016年中旬)，彼时的前端页面是和java一起打包发布的，无论是开发还是发布，都透露着一种“生死都要在一起”的感觉，于是我们紧随时代潮流，开始了大刀阔斧的改革，引进Nodejs。

1.2、初尝Nodejs(2016年底)

彼时(2016年底)对于Nodejs没有太多的深入，只是拿公司官网初试牛刀。涉及到的后台数据都是在Nodejs层使用http去java端请求。这个时候开发和发布第一次和服务端解耦，第一次感觉到了“分开，对彼此都是个好事”是句真话。前端没有太多束缚，并且还能接触到一些运维上的事情，何乐而不为呢？

1.3、开始大规模应用Nodejs(2017年初)

初尝Nodejs发现开发提升的效率还是很明显的，于是开始在所有的新项目中使用Nodejs，所有的中台系统开始使用Nodejs作为网关，这个时候网关BFF的概念开始出现在我们的工作中。虽然开发效率是提高了，但是前后端在开发协作上还是暴露出很多问题。毕竟使用http接口，网关层是无法感知到java端接口的变化。但是这个问题在随着公司的整体架构变迁而随之被解决掉。

1.4、全面引入微服务，开始使用dubbo协议(2017年中旬)

引入微服务(2017年初)是一项巨大的工程，所有的java项目都需要改造，前端网关也不例外。前端网关除了需要有一个dubbo客户端之外，还需要解决上述阶段遇到的协作问题，于是解析javadoc成了后面所有项目的必经过程。在后面的演变过程，我们可以全自动地下载并解析javadoc文档成js或者ts语法格式文件，尤其使用ts之后，所有的方法、参数都可以全部自动提示，可谓是解放了一大批生产力。

1.5、传统的express网关遭弃用，转而开始使用容器理念和AOP模型(2018年初)

在传统的express网关模型中，发现了很多弊端(毕竟经验不足)，js弱类型、代码结构不合理，冗余代码太多，业务和框架没有解耦等等。于是我们开始改造，使用inversify来制造容器，使用AOP来简化所有中间流程，剩余给开发的就是纯业务扩展。在这套全新的网关框架下，我们全部使用typescript，借助ts语言的强类型特性，我们做了很多以前不好做或者做不到的事情，比如api文档的自动化，比如前后端类型的统一化等等。

1.6、网关生态以及前端开发流程再优化(整个2018年)

生命奔腾不止，折腾便不止。在当前nodejs大量应用的情况下，维护可持续的生态便成了重中之重。于是我们不断在开发业务的同时，不断加固我们的地基。从服务器性能监控到服务器告警日志监控，再到业务数据图表展示，用户行为跟踪(未做)，无不体现我们想要做好前端网关这一层的决心。

1.7、高并发的挑战-长连接网关(2018年底)

终于我们还是顺应了历史潮流，在2018年中旬的大量测试之后，开始引入了长连接网关，挑战同时10万骑手在线的压力。历史证明了，我们仅仅用了四台常规的服务器就抗住了来自rocketMq 多达400QPS的消息处理以及线上10万骑手在线的压力，当然得益于nodejs优秀的并发性能，同时我们借助redis解决了很多当时遇到的问题。

1.8、未来可期

未来，我们期望在网关生态上做更多的建设，当前在做的便是引入Kong来解决项目庞大的问题，另外还有更多待解决的问题需要我们继续折腾~

2、点我达网关生态

前端在服务器端的生态圈不如java那么齐全，很多东西也都是在摸索。经过了这么几年的打磨，多少对网关这个东西有一定的整体模型，下面的示意图便是当前点我达网关生态的模型，是当前在做以及未来要做的事情

下图是一张宽泛的网关架构图：

在当前实现的版本中，详细的生态应该是这样的，不仅有可持续发展的业务能力，也具备稳定高效地地基，同时可以提供众多能力给开发的童鞋：

3、点我达网关开发流程

话说技术的积累离不开业务的拓展，没有实际项目的实战，一切都是纸上谈兵。所以有一套完善的开发流程不仅可以改善开发体验，而且可以保障项目的质量。这几年的实战下来，为了达到上述的两个目的，我们不断优化开发流程，今后仍然会不断优化。下图便是技术开发整个流程，仅供参考：

而技术开发流程离不开各种各样的评审，比如上述中的代码评审，从PM的角度来阐述这个流程可能是这样的：

4、移动端技术栈

这里的移动端包括了移动端Hybrid H5和网关，这条技术栈包含了主要的技能点，每个技能点都有对应的知识库在内部分享。里面的技术栈也会随着业务的演变和迭代进行微调。虽然说大部分是网关开发，但是我们也承担移动端H5页面的开发，目前点我达骑手端和商家端，仍然嵌入不少的H5页面。有兴趣的童鞋可以自行下载体验一番(如何区分是H5页面还是非H5页面，这里就不用说了吧？)

5、团队管理

这是我第一次谈及团队管理。之前没有太多的经验，但是随着从2018年初开始负责移动端网关之后，我自己就经常反思，如何负责好移动端网关？虽然没有明确的title，但是自己的思想发生了很大的转变，做需求不再是单纯做需求了，会考虑需求的合理性，需求与同时期需求的关联与冲突。每次需求排期，都要考虑好需求适合开发的人选，以及如何管理大家的任务？遇到大的项目，考虑的东西更多，什么兼容性、发布流程、技术方案选择，都会和开发人员讨论一番并在即将上线前再检查一遍。

有的人可能会说，这不是事无巨细地忙活吗？那还有时间开发吗？其实这些东西因为有了一套完善的开发流程，很多事情在流程上都被解决掉了，并不会花太多时间。技术毕竟还是我的第一选择，在职的两年多，除了关注这些之外，还会和大家一起发现问题，一起解决问题，一起造轮子。我们从无到有，不断给前端开发添砖加瓦~

5.1、分析团队以及当前开发遇到的问题

因为不是凭空进入这个团队，所以对于团队成员和团队项目有着很多了解，这对于我来说是幸运的？然后除了分析大家的技能点之外，就是寻找影响大家开发体验的一些问题，于是有了这么一张图：

每过一个季度，我们都会将这个季度遇到的问题再次重新更新一遍，哪些解决了？哪些解决了但是还不够完善？哪些是新增的问题？以此给大家一个”人人为我，我为人人“的积极心态。让大家彼此知道我们团队的发展情况，有一种主人翁的意识去工作。经过一年多的改进，变化还是很明显的：

5.2、输出统一的目标

在负责网关之后，建立的钉钉群里，公告上我就提出了团队的核心目标是“打造质量可靠、开发速效的前端网关团队”，而我们一直追求的也是这样的一个节奏。没有可靠的质量保证，一切皆惘然。所以我们在开发流程中植入了很多环节去保证这个目标可以有条不紊地实现，比如加入技术方案评审，在项目初期排除有风险的问题点，在分支测试环节，进行代码review，检查代码规范以及逻辑是否有问题，在灰测阶段，使用A/B测试来检查项目是否有别的问题，层层保障只为了每个需求都可以交付一份满意的答卷。

保障质量的同时，我们也希望能够提高开发效率，能够机器完成的事情绝不要人为去做。包括一些检查，自动化测试等等，有了这些自动化行为，我们才能体会到开发的丝滑顺柔，才能有时间去做些我们自己想做的事情，而不仅仅是业务。

如此二者正向循环，互补互惠，可以给团队带来极大的能量。

5.3、规范化开发流程

规范化开发流程是指从拿到需求到需求上线，这个流程在上面的图已经表达过了。曾经就有故障因为流程的某个环节缺失，导致bug直接反馈在线上，所以保证规范化开发流程是很有必要的。

5.4、输出并维护团队共有的知识库

自从全组推行使用Notion软件之后，团队的协作变得更加顺畅。在Notion上我们单独开辟出一个专栏，叫做“前端知识库”，上面可以放置你写的博客，也可以引用你看过的某篇非常有意思的文章，并形成分类，这些知识库也是对现有技术栈的学习。除了这些，我们还会将各种前端规范、入门手册、项目介绍等等信息都维护在这里，不仅方便团队成员查阅，更可以帮助新成员快速融入团队并上手项目。如图所示：

5.5、鼓励团队技术与业务创新

除了正常的业务迭代需求，内部时常会有一些新的系统需要开发。在新项目开发上，鼓励大家使用最新技术，比如小程序的使用、GraphQL的使用等等。而那些正常迭代的项目，也可以对某些模块进行升级，不断优化。在业务上，可以有形成自己的领域模型，帮助产品更好地规划需求的重构等等。团队毕竟不是独立存在的，我们需要协作的第三方很多，有了自己的一套新技术基础，我们才可以在面对需求的时候，抉择最佳的方案。

5.6、定期鞭策团队

前端知识变化太快，标准一年一次迭代。所以我们为了更快成长，需要不断地更新旧有和新加的知识，于是我们定期组织大家进行考试。是的，你没听错，就是像学生时代那样的考试。每个人可以从各个渠道上搜罗题目，然后形成一份综合性试卷，这些题目要求和现有技术栈紧密贴近，可以很基础，也可以很开放。每次考试题目都会维护起来并分门别类，给大家有空的时候翻翻看。每次会议的时候，我都会这么跟大家说这样的一句话“将来万一你真的想离开团队去寻找更好的平台，这些知识或许可以帮助你面试通过，而不用去疯狂刷题背题，因为我们每天都在面试”。

6、最后

好了，闲扯了这么多，最后欢迎关注我的个人博客：豆米的博客