2018 前端技术架构图
一、回顾过去的2018
写下来，更多是为了自我的总结。已经去掉一些敏感信息，项目信息。
2018年即将过去，回顾一年的前端技术建设的投入，所经历的一年，带着我这原来的8号兄弟姐妹，变成16个人的前端团体。从上年的前端救火队，变成今年的固定前端技术团队。新的2019年，也许挑战更多，任务更重。然，毫无退缩，作为leader，既要带着向前冲，同时解决各种遇到的困难。
平时都很忙，而且时间有限，用最快的速度交付，就选择了这种简单有效的方式。
1、Talk is Cheap,Show me The code 历史包袱
2018年初，刚接手前端团队的时候，历史留下的问题是巨多。所以图上灰色地带，就是我们前三个月还的技术债。由于以前大部分系统都没有分离，规范也错中复杂，api接口格式 也是“五花八门”，对于 git分支 管理，也是十分混乱。前端发布，也是全是手工部署，手工移交。面对前后端比例，接近1:5的比例，面对大量的业务系统，自然是一团乱麻。
1.1 自动化构建
实现了自动化jenkins自动化构建，每次不用等待编译，不用手工部署，代码合并分支，代码review通过，就自动发布。
部分项目签约到gitlab ci上，实现k8s的部署等。
减少每天项目，因为手工发布打包，每次耗时10 - 20分钟的人工操作。
修改bug发布测试或生产环境发版，都是 自动化构建 或者 一键构建 完成，在开发效率上提升。
1.2 git分支规范
实现了git分支规范，按feature管理功能，实现单独发布，组合发布都是可以的。
以前一个分支，哪个功能测试不通过，还得注释代码的，还得评估影响。即使线上功能有问题，单独回滚某个分支也是可以的。
实现 git分支管理，可以实现单独功能点的发布，回滚，线上问题的跟踪管理。减少定位问题的时间与提升效率。
1.3 changelog
实现了提交日志，版本的发布内容的自动抽取，实现了版本功能的更新日志化。
通过这个版本changelog日志，自动管理每个版本的代码变更点与需求点的管理。
1.4 https
安全原因，实现内网的全https化,当然证书是内部的，在内网dns解析对接，接入kong层等。
1.5 eslint静态检查化
技术栈一致，统一了代码的检查规则，实现代码在不同的系统风格是一致的，人员在各项目流动，能快速上手，并且规则一致。
1.6 api接口规范
与后端约定，api的接口规范，统一了java，.net及其他后端（go,ruby,python等等）语言的差异，都统一一样的接口标准，在对接过程实现标准统一。统一使用swagger作为文档接入。
特别是，.NET方面的后端团队，对接接口都是大写开头，接口文档都以原来.net团队的工具，接口对前端而言，需要转换一层适配，非常不合适。所以统一标准后，统一在后端服务层解决接口规范。
1.7 错误的监控
所有的前端系统，都接入线上sentry的错误监控，监控线上的问题点排查，结合用户的反馈的点，周期梳理问题，反馈到开发质量上的。
1.8 webpack编译优化
从webpack版本从3.x全线十几个前端系统，升级到webpack 4.x，统一编译脚手架，抽离dll，缓存，本地开发编译提速接近40%。
以上，历史问题点的修改，还有很多细节点。快速调整前端团队，围绕 前后端联调 的需求快速交付，版本管理，接口的文档的管理。 快速调整团队的前后端开发模式，各团队的工作协调性，保证了交付的速度，交付质量，安全性得到基本可控，逐步走上正轨。
实践证明，以上一些措施是比较有效、快速解决以前遇到痛点，不规范，在前后端配合上，减少扯皮，交付速度，质量上得到明显的提升。
2. 2018 重点打造
2.1 引入React，antd等开发生态
以前的痛点，通常是纯vue开发，但是紧急项目阶段，借调一些其他部门人员，往往都react为准，技术沉淀，对设计还原度高，非管理，流程性质的系统，那么年初逐步采用react + antd的开发，做设计还原类的门户，网站，活动，甚至内部系统。
我提出双轨制，两个技术栈同时并行，vue以基于已有技术积累，前端团队快速开发，react有良好的社区生态，公司其他部门沉淀。技能上，必须同时掌握两门以上实际项目开发经验，对接手项目，开发新项目的选型，起到基础作用。
从效果看，还是不错的，从0到60%以上的团队的同学都同时具备vue + react两种开发技术栈的实际项目经验。
2.2 重点打造配置化表单，门户类脚手架，抽象业务组件等，重点投入数据可视化
2.2.1 配置化表单
更多为了解决重复性问题，相似度高，4月份开始设计、实现一套配置化的表单功能，通过配置化，通过后端约定好规范文档，最快半个小时即可配置好表单功能，即可上线。
从以前1-2人天开发，缩短到1-2个小时表单，报表类开发时间，满足基本60% - 70%的基本表单服务需求。
2.2.2 门户类脚手架
对于设计还原度高，各种业务有需要外部网站门户类，引入外部流量的部分，抽象出一套门户类前端工程脚手架。
按照统一的UI视觉规范，可以达到根据脚手架，直接开发业务，减少设计还原的时间，满足设计规范，响应式支持 PC 与 移动端，快速上线。在各类业务的服务，偏向公共项，经过我们抽象提升，抽离到脚手架上，减少门户类的框架搭建重复投入，聚焦业务点，提升开发效率。
2.2.3 业务组件库
前端开发除个别没有前后端分离的项目，已经95%以上采用组件开发，组件都是开源并且经过众多使用方的验证，组件的质量已经通过检验可靠。这也是前后端分离后的带来的组件化开发的好处。
然，很多业务上的，某一类系统特别适用频发的，而且有一定业务逻辑的，例如查找选择某个人账户，例如审批记录，流程记录，附件上传的统一业务组件等等，都是可以抽象的，并且抽象都业务组件库，与同类型的系统通用的。例如快速配置化的表单等等。
通过业务组件库，可以减少一些各项目相似业务的重复开发，避免重复踩坑。
2.2.4 前端运行平台，F系统
我把它命名为Ferret系统，下称为F系统，并且投入开发。 针对各项目都是前端都是部署在后端的服务器，或者nginx静态目录下。那么前端通用的gzip压缩，自动化部署平台，需要开通各类的前端web服务器的静态目录测试环境，生产环境写入权限与防火墙。
那么，重复开通，并且重复的配置的问题就非常频繁了，来一个系统开一个系统，开多个防火墙。配合k8s 的部署容器化部署改造。
- 解决方式，通常有容器化解决与集中化解决。
- 需要解决几个统一的痛点：
1. 前端的部署问题
2. 前端的线上的多语言翻译对接
3. 反向代理，网关的api对接转发，result结果, 配置Redis缓存
4. 安全header头如 CSP 等header统一设置,例如 xxs 拦截，csrf的拦截
5. jwt的登陆与SSO登陆统一验证
针对以上痛点，构建了F系统的前端运行平台，而且 k8s 容器 docker 镜像化，并且全部实现配置化，通过配置，实现功能点的可用。同时，开发给所有系统接入，部署。针对内部流量不高，稳定性可靠，数据不落地等特点，F系统很好地解决以上问题，已经在逐步推广阶段。
2.2.5 业务指标的数据可视化，数据的挖掘，层层下钻，促进精细化管理。
这个是个业务系统点，这里从技术的角度分享。以前做数据可视化，更多系统通过各种图形，折线图，柱状图，饼图等，显示数据指标，业务关键指标，清单，报表。
数据化G项目，更多系统从数据业务指标，大屏幕上墙展示，通过宏观的业务指标数据，一层层下钻到下层，再下层汇总统计，一直到找到具体的问题点，分析数据统计的变化。
从宏观业务关键指标，下钻到具体问题点数据下钻，层层数据挖掘，找到问题点，问题单，再链接具体系统查看，通过设置，业务红线，触发相关的管理动作，不再人工统计业务业务关键指标，都通过系统自动每天计算分析得到数据指标。通过这种数据化的项目，通过按项目，按周月日，各种维度查看业务指标，下钻到业务具体的问题点，触发相关管理流程与管理动作。该项目最多从一个指标触发点，下钻下面五层业务数据，再查到具体的业务数据，单据。
2.2.6 建设内部easy-mock平台。
针对开发过程的中后端定义接口，快速开发前端demo，与用户，业务方过设计方案等痛点，内部建立easy-mock平台，模拟接口反馈，促进前端在开发demo或者业务流程阶段，可以完全脱离后端服务进行。
- 开发阶段，前端对接easy-mock, 减少了开发阶段对后端服务api的依赖程度。
- 开发阶段，内部网关对接easy-mock，减少了内部网关接口联调，多系统造测试关联系统数据的痛点。
三、 团队的建设
3.1 前端Team的梯队构成
前端团队从原来8个前端，年重点补充中级的支撑力量，建立起人员梯队，到目前16个前端,其中2个生宝宝，实际负责14个前端团队。
- 第一梯队，重点解决业务架构上，技术选型，难点技术攻关，大项目前端把控，4人。
- 第二梯队，重点解决快速交付，保证重要需求的交付。6人
- 第三梯队，更多解决需求的实现。6人
人数增加了一倍前端，但应对8大项目团队，支撑35+个大小业务系统，人均负责2.5个前端系统的开发工作量,仍面对1:5的前后端人数比例。在每年HC有限的情况下，通过以上技术的手段，前端资源集中协调，支撑了公司级几大改革项目。
14个人支撑35+个系统，应对8个业务team的前端任务，这放以前，是不可想象的，但是前端团队扛下来了，也是靠着技术线的统一资源协调，灵活调配人手，共同努力，依赖各种自动化,团队规范的保质保量达成的。
特别自豪的是，虽然加班特别多，经常凌晨深夜，0离职率。靠的是团队的氛围，互相帮助，共同的目标，共同的追求，当时还有公司及组织上整体的团队保障。
用最少的资源，通过技术手段，管理手段，实现公司价值的最大化。
3.2 对内的品牌建立
建立团队的品牌名称，建立团队空间，建立团队技术博客，技术输出
3.3 前端Team的技术培训
建立对内的技术分享直播平台，参与前端的技术分享会，组织参与技术分享活动。
3.4 前端Team的团建活动
组织了多次吃吃喝喝的活动。省略。
四、2019重点方向
4.1 重点打造前端的交付速度与交付质量
交付速度，将原来的配置化报表，配置化表单升级，覆盖更多场景;投入业务逻辑组件库，继续投入人力，将覆盖度提升，并且推广，更轻松的完成现有或未来业务的快速发展。
交付质量上，增加code review，将试验的前端代码的单元测试推广，提升自测通过率，提升单测代码覆盖率。
4.2 All in TS（Typecript）
typescript在中大型项目的开发，特别对数据强类型校验，使用装饰模式增强现有功能点，接口方法强类型，IDE提示方面，增强对js的语言等特性，对数据敏感类的项目，能解决我们在开发的一些数据格式的痛点，应该是未来一个趋势。
结合vue-cli 3.0与vue 3.0等方面结合是未来的趋势，各大类库都是用ts重构，所以新项目都推荐“all in ts”模式。
目前这一规划，已经实现vue-cli 3.0 与ts的结合，针对内部的使用场景定制化的开发前端脚手架。
4.3 在数据可视化，特别是WebGL的3D化的数据可视化
针对数据需要做更细致化的挖掘展示，下钻展示，组合式展示。对一些实际的智能化领域，智能设备领域，数字化指标，数字化监控类场景，3D化的数据可视化场景会越来越多。从平面化展示，逐步走向WebGL为方向的3D展示数据指标，监控指标，实际场景3D布局等。
- 推进精细化管理。
- 业务指标的层层下钻，数据挖掘找到业务的中的问题点，具体单据，加以改进，促进管理提升。
- 通过数据指标的设置，触发管理指标的红线，触发管理动作。
- 提升业务决策的准确性。
- 通过数据指标的监控，减少设备管理的风险性，提前预判损耗或者设备的利用率
五、最后
2018年即将过去，从技术建设层面，看2018年，从荒芜，凌乱到有序,到稳定输出，从团队8个人，到人数翻了一倍。团队战斗力，技术体系建设，人员梯队建设，交付速度都有了很大程度的提升。
从业务的角度，团队经历了公司改革的几大公司级的“三大战场”的改革项目，顶住了压力，完成了项目的交付。2018年更多是从无到有，还有很多模块还没做好，没有做完善，需要继续投入精力。
展望2019，更多的是“从有到优，从优到精”的过程，重点在“交付速度，交付质量”上，引入更多的更好的技术手段，技术工具，进一步提升生产力，提升开发效率。
核心主要矛盾在哪，我们就在那部署重兵，一举攻破。
记录更多为了自我总结，自我提升，欢迎邮件交流: johnsonliang@aliyun.com
