前端技术选型及背后思考

7,099 阅读6分钟

前端技术选型及背后读思考

《美团点评金融平台Web前端技术体系》 笔记整理

参考文章:

构建技术体系读基本原则

1. 业务出发

  • 选型要针对业务形态特点,注重业务场景匹配度
  • 具有一定读业务前瞻性

2. 团队出发

  • 考虑团队规模,成员技术特点和偏好
  • 考虑现有项目和技术迁移成本

3. 以简驭繁

主张使用简单读技术手段解决复杂读问题

4. 标准化

尽可能让上下游衔接形成标准,并在标准下构建质量和效率工具。

例如在组件库 Vix 的研发上,我们与 UED 形成一致的、强同步的标准,从而大大减少界面搭建的时间消 耗。

5. 自动化

用技术连接技术,用技术简化步骤,解决工具到使用者读最后“一公里”问题。
eg: 自动化流程测试,自动化继承,自动化接口测试

6. 现有复用

选型上尽量使用公司已有的系统和工具,从而更好的与业务、团队结合。

美团点评金融平台Web前端技术体系:

美团点评金融平台Web前端技术体系

前端技术选型涉及到技术单元:

1. 视图&组件库

美团点评金融平台在移动端使用Vue生态,在桌面版使用Vue生态或React生态。

选择Vue的考虑:

  • 体积小,复杂度低
    • 业务上移动端项目占比 70% 以上,Vue 的体积小,网络性能角度相比 React 更适合移动端
    • 移动端一般巨型项目很少,从代码结构上来讲,使用 Vue 实现更符合我们的场景复杂度, React 更适合大型相对更复杂的 SPA
  • 上手成本和迁移成本低
    • Vue 的学习和上手成本相对更低,团队成员对于 Vue 的认可度和热情也比较高
  • 组件内双向绑定、数据依赖收集
    • 组件内支持双向绑定,更方便的去进行组件内的数据响应与交互
    • 独有的数据依赖收集模式使其默认的数据响应和渲染效率都要比 React 高一些

React的使用主要考虑一下原因:

  • 有一部分现有后台项目采用 React 技术栈,迭代和维护较少,老的项目如果没有足够的迁移价值则不额外投入资源
  • 保留很小的一部分 React 技术生态也可以一定程度上保持一些技术多样性

2. 组件库

组件库的选择是前端技术栈选型的一个重要部分,直接影响到研发效率、软件质量、以及交互体验。

组件库可划分为基础组件、复杂组件、业务组件。

PC端内部系统研发的4个特点:

  • 无产品,要求高:几乎没有产品经理跟进,以完成功能需求为主,但功能流程一定要完善,最好能支持手机端使用
  • 无设计:几乎没有设计跟进,面对内部用户设计收益不高
  • 无测试:几乎没有测试跟进,收益不高,功能验证通过即可
  • 要快:大多数是配合用户端产品的管理系统迭代,也可能是新系统的搭建,对研发速度都有要求,往往这方面的估时较短

因此,在内部系统的研发上有四点要求:

  • 组件设计合理,组件数量大而全,最好支持移动端使用
  • 组件库本身要有不错的设计,用户量虽少,但活跃度超高,界面体验需要保障
  • 组件库本身的质量要高,要从工具层面保障质量减少出错
  • 组件库要能够快速拼装出功能

3. 语言

强类型语言的作用:

  • 在开发期间或编译期间进行强类型检查
  • 使用类型系统让代码可控性、扩展性更强,协作更方便
  • 避免 something is undefined 的空指针问题

语言选择:

  1. Typescript, 微软出品
  2. Flow, Facebook出品

选择 TypeScript 是因为以下几点:

  • RoadMap 清晰,方向以贴合 ECMAScript 为核心,在其之上构建类型系统,传言 ES8 也会增加类型系统
  • TypeScript 是 JavaScript的超集,其作用只在开发阶段发挥,其生成的代码不包含任何类型代码,但由类型系统保障
  • IDE 支持极好,除了自家的 VSCode 集成度超高,用户增长飞速,TypeScript 还支持市面上几乎所有主流 IDE
  • 社区庞大,周边工具丰富
  • 当时已经有几个大型的开源项目在使用,例如 Angular 和 Express
  • 研发团队活力和积极性都很高,很多开源生态均快速推进集成

TypeScript 包括 类型守护、联合类型、类型推导、严格非空检查等功能。

使用Lint 工具保障代码风格和质量。

4. 协作解耦

协作解耦就是让前后端的开发工作不互相依赖,从而优化研发效率。

工具推荐:

  • RAP是一个可视化接口管理工具 通过分析接口结构,动态生成模拟数据,校验真实接口正确性, 围绕接口定义,通过一系列自动化工具提升我们的协作效率。

前端与后端协作提升开发效率的一个很重要的方法就是减少沟通:能够形成纸质的文档就不要口头沟通、能够把接口文档写清楚也不要口头沟通(参数、数据结构、字段含义等)。

5. 自动化测试

6. 用户体验

7. 离线化技术

  • Application Cache:实现上各个平台各个浏览器有一些差异,即使把“无法更新的坑”踩过还是会有很多“无法离线”的坑,PASS

  • Service Workers:Service Workers 是团队一直跟进的技术,目前在测试已经接近正式发布,只是在 iOS 上还 无法大范围使用,长期看好,暂时 PASS

离线加载技术要考虑以下问题:

  • 是否解决了首次加载问题?
  • 离线化方案的首次加载问题是一个很难的技术领域,我认为其最核心的问题是何时加载,提前加载会不会用户在很长一段时间内都不会用到导致浪费流量?
  • 使用包含首次加载优化的离线化技术的项目多了会不会造成加载拥塞?
  • 是不是需要分析用户行为数据去更精准的进行离线包的提前加载?

8. 增量更新方案

9. 监控日志系统

异常监控、性能监控、网络监控

10. 安全方面

安全方面在前端我们使用:

  • HSTS: 防 SSLStrip 攻击的标准解决方案
  • CSP: 防跨站脚本攻击的标准解决方案 同时在核心接口上使用网页请求签名方案,在一定程度上保障请求是从我们的客户端中正常发出的。