同样做前端,为何差距越来越大?

由于历史原因,开发框架同时基于 React 和 Angular,考虑到产品的复杂性、人员的短缺和技术背景各异,我们尝试了各种方法打磨工具体系来提升开发效率,以下分享五点。

一、基于 Redux 的状态管理

从2013年React发布至今已近6个年头,前端框架逐渐形成 React/Vue/Angular 三足鼎立之势。几年前还在争论单向绑定和双向绑定孰优孰劣,现在三大框架已经不约而同选择单向绑定,双向绑定沦为单纯的语法糖。框架间的差异越来越小,加上 Ant-Design/Fusion-Design/NG-ZORRO/ElementUI 组件库的成熟,选择任一你熟悉的框架都能高效完成业务。

那接下来核心问题是什么?我们认为是状态管理。简单应用使用组件内 State 方便快捷,但随着应用复杂度上升,会发现数据散落在不同的组件,组件通信会变得异常复杂。我们先后尝试过原生 Redux、分形 Fractal 的思路、自研类 Mobx 框架、Angular Service,最终认为 Redux 依旧是复杂应用数据流处理最佳选项之一。

庆幸的是除了 React 社区,Vue 社区有类似的 Vuex,Angular 社区有 NgRx 也提供了几乎同样的能力,甚至 NgRx 还可以无缝使用 redux-devtools 来调试状态变化。

无论如何优化,始终要遵循 Redux 三原则:

这三个问题我们是通过自研 iron-redux 库【1】来解决,以下是背后的思考:

如何组织 Action?

  1. action type 需要全局惟一,因此我们给 action type 添加了 prefix,其实就是 namespace 的概念;
  2. 为了追求体验,请求(Fetch)场景需要处理 3 种状态,对应 LOADING/SUCCESS/ERROR 这 3 个action,我们通过 FetchTypes 类型来自动生成对应到 3 个 action。

如何组织 Store/Reducer?

  1. reducer 和 view 不必一一对应,应用中同时存在组件树和状态树,按照各自需要去组织,通过 connect 来绑定状态树的一个或多个分支到组件树;
  2. 通过构造一些预设数据类型来减少样板代码。对于 Fetch 返回的数据我们定义了 AsyncTuple 这种类型,减少了样板代码;
  3. 明确的组织结构,第1层是 ROOT,第2层是各个页面,第3层是页面内的卡片,第4层是卡片的数据,这样划分最深处基本不会超过5层。

最终我们得到如下扁平的状态树。虽庞大但有序,你可以快速而明确的访问任何数据。

Redux 状态树

如何减少样板代码?

使用原生 Redux,一个常见的请求处理如下。非常冗余,这是 Redux 被很多人诟病的原因:

使用 iron-redux 后:

代码量减少三分之二!!

主要做了这2点:

  1. 引入了预设的 AsyncTuple 类型,就是 {data: [], loading: boolean, error: boolean} 这样的数据结构;
  2. 使用 AsyncTuple.handleAll 处理 LOADING/SUCCESS/ERROR 这 3 种 action,handleAll 的代码很简单,使用 if 判断 action.type 的后缀即可,源码【2】。

曾经 React 和 Angular 是两个很难调和的框架,开发中浪费了我们大量的人力。通过使用轻量级的 iron-redux,完全遵循 Redux 核心原则下,我们内部实现了除组件层以外几乎所有代码的复用。开发规范、工具库达成一致,开发人员能够无缝切换,框架差异带来的额外成本降到很低。

二、全面拥抱 TypeScript

TypeScript 目前可谓大红大紫,根据 2018 stateofjs【3】,超过 50% 的使用率以及 90% 的满意度,甚至连 Jest 也正在从 Flow 切换到 TS【4】。如果你还没有

使用,可以考虑切换,绝对能给项目带来很大提升。过去一年,我们从部分使用 TS 变为全面切换到 TS,包括我们自己开发的工具库等。

TS 最大的优势是它提供了强大的静态分析能力,结合 TSLint 能对代码做到更加严格的检查约束。传统的 EcmaScript 由于没有静态类型,即使有了 ESLint 也只能做到很基本的检查,一些 typo 问题可能线上出了 Bug 后才被发现。

下图是一个前端应用常见的4层架构。 代码和工具全面拥抱 TS 后,实现了从后端 API 接口到 View 组件的全链路静态分析,具有了完善的代码提示和校验能力。

前后端协作简图

除了上面讲的 iron-redux,我们还引入 Pont 【5】实现前端取数,它可以自动把后端 API 映射到前端可调用的请求方法。

Pont 实现原理:(法语:桥) 是我们研发的前端取数层框架。对接的后端 API 使用 Java Swagger,Swagger 能提供所有 API 的元信息,包括请求和响应的类型格式。Pont 解析 API 元信息生成 TS 的取数函数,这些取数函数类型完美,并挂载到 API 模块下。最终代码中取数效果是这样的:

Pont 实现的效果有:

  1. 根据方法名自动匹配 url、method,并且对应到 prams、response 类型完美,并能自动提示;
  2. 后端 API 接口变更后,前端相关联的请求会自动报错,再也不担心后端悄悄改接口前端不知晓;
  3. 再也不需要前后端接口约定文档,使用代码保证前端取数和后端接口定义完全一致。

另外 iron-redux 能接收到 Pont 接口响应数据格式,并推导出整个 Redux 状态树的静态类型定义,Store 中的数据完美的类型提示。效果如下:

最终 TS 让代码更加健壮,尤其是对于大型项目,编译通过几乎就代表运行正常,也给重构增加了很多信心。

三、回归 Sass/Less

2015 年我们就开始实践 CSS Modules,包括后来的 styled-components 等,到 2019 年 css-in-js 方案依旧争论不休,虽然它确实解决了一些 CSS 语言天生的问题,但同时增加了不少成本,新手不够友好、全局样式覆盖成本高涨、伪类处理复杂、与AntD等组件库结合有坑。与此同时 Sass/Less 社区也在飞速发展,尤其是 Stylelint 【6】的成熟,可以通过技术约束的手段来避免 CSS 的 Bad Parts。

  1. 全局污染:约定每个样式文件只能有一个顶级类,如 .home-page{ .top-nav {//}, .main-content{ // } }。如果有多个顶级类,可以使用 Stylelint rule 检测并给出警告。
  2. 依赖管理不彻底。借助 webpack 的 css-loader,已够用。
  3. JS 和 CSS 变量共享。关于 JS 和 Sass/Less 变量共享,我们摸索出了自己的解法:

在 scss 文件中,可以直接引用变量:

四、开发工具覆盖全链路

2019 年,你几乎不可能再开发出 React/Angular/Vue 级别的框架,也没必要再造 Ant-Design/Fusion-Design/Ng-Zorro 这样的轮子。难道就没有机会了吗?

当然有,结合你自身的产品开发流程,依旧有很多机会。下面是常规项目的开发流程图,任何一个环节只要深挖,都有提升空间。如果你能通过工具减少一个或多个环节,带来的价值更大。

单拿其中的【开发】环节展开,就有很多可扩展的场景:

一个有代表性的例子是,我们开发了国际化工具 kiwi【7】。它同样具有 TS 的类型完美,非常强大的文案提示,另外还有:齐论电商  淘宝学习网

  1. VS Code 插件 kiwi linter【8】,自动对中文文案标红,如果已有翻译文案能自动完成替换;
  2. Shell 命令全量检查出没有翻译的文案,批量提交给翻译人员;
  3. Codemod 脚本自动实现旧的国际化方案向 Kiwi 迁移,成本极低。

除了以上三点,未来还计划开发浏览器插件来检查漏翻文案,利用 Husky 在 git 提交前对漏翻文案自动做机器翻译等等。

未来如果你只提供一个代码库,那它的价值会非常局限。你可以参照上面的图表,开发相应的扩展来丰富生态。如果你是新手,推荐学习下编译原理和对应的扩展开发规范。

五、严格彻底的 Code Review

过去的一年,我们一共进行了 1200+ 多次 Code Review(CR),很多同事从刚开始不好意思提 MR(GitLab Merge Request,Code Review 的一种方式) 到后来追着别人 Review,CR 成为每个人的习惯。通过 CR 让项目中任何一行代码都至少被两人触达过,减少了绝大多数的低级错误,提升了代码质量,这也是帮助新人成长最快的方式之一。

[其中一个项目MR截图]

Code Review 的几个技巧:

  • No magic;
  • Explicit not implicit;
  • 覆盖度比深度重要,覆盖度追求100%;
  • 频率比仪式感重要,坐公交蹲厕所打开手机都可以 Review 别人代码,不需要专门组织会议;
  • 粒度要尽可能小,一个组件一个方法均可,可以结合 Git Flow;
  • 24h 小时内处理,无问题直接 merge,有问题一定要留 comment,并且提供 action;
  • 对于亟待上线来不及 Review 的代码,可以先合并上线,上线后再补充 Review;
  • 需要自上而下的推动,具有完善的规范,同时定期总结 Review 经验来丰富开发规范;
  • CR 并不只是为了找错,看到好的代码,不要吝啬你的赞美;
  • 本质是鼓励开发者间更多的沟通,互相学习,营造技术文化氛围。

总结

以上5点当然不是我们技术的全部。除此之外我们还实践了移动端开发、可视化图表/WebGL、Web Worker、GraphQL、性能优化等等,但这些还停留在术的层面,未来到一定程度会拿出来分享。

如果你也准备或正在开发复杂的前端应用,同时团队人员多样技术背景各异,可以参考以上5点,使用 Redux 实现规范清晰可预测的状态管理,深耕 TypeScript 来提升代码健壮性和可维护性,借助各种 Lint 工具回归简单方便的 CSS,不断打磨自己的开发工具来保证开发规范高效,并严格彻底实行 Code Review 促进人的交流和提升。

原文地址:https://www.cnblogs.com/qilun/p/12708162.html

时间: 04-15

同样做前端,为何差距越来越大?的相关文章

做前端好还是Java好?

做前端好还是Java好?看这三方面 转载 2017年11月14日 00:00:00 1047这几年来伴随着互联网的迅速发展,新兴互联网产业的兴起,传统行业也逐渐开始互联网化,使得互联网职业在这样的背景下成了备受瞩目的热门职业,其中"前端开发"和"Java开发"就是热门职业其中之二,两者在关注度和热度上不分伯仲,但外界对他们得评价也是褒贬不一,随着互联网的继续发展,前端,Java工程师人才缺口大的现状也日益显著,在发展前景和薪资的吸引下,不断有刚毕业的大学生,或者有一

为什么做前端要做好SEO

我就挑干货说啦 SEO可能听起来很高大上,其实翻译成中文就是“搜索引擎优化",它只是通过一定的方法在网站内外发布文章.交换连接等,最终达到某个关键词在搜索引擎上获得好的排名. 我有幸接触SEO是将近三年前,当时也是刚刚加入前端这个行业,当时只认为做好看的网页,做好交互,做好用户体验就是一个合格的前端技术人员,可后来了解到SEO之后才知道SEO对网页的影响真的很大很大,官方文档比较难以理解,下面我来谈一下SEO是什么,以及怎么做好它. 记得刚开始接触SEO的时候感觉好简单啊,随便发发文章,找各大论

LVS集群--->做前端调度器搭建使用

LVS集群--->在这里做前端调度器搭建使用,工作模式用的LVS-nat和LVS-dr. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++集群:一组通过高速网络互联的计算组,并以单一系统的模式加以管理,服务的是同一网站 集群目低:增加可靠性 提高性能 降低成本 提高可靠扩展性 集群分类:高性能计算集群HPC(工作中用的少):通过以集群开发的并行应用程序,解决复杂的科学问题|(主要是单

你做前端多久了?为什么要选择做前端?

作为入行不久的一枚前端妹子,由于急于成为前端大拿,最近也结交了不少前端朋友,有真正的大拿,有跟我水平相当的同僚,也有刚入行的小白. 我跟很多人问过大家做前端多久了?为什么选择做前端这样的问题,大家经验不一,有的几个月,有的半年,有的两年,有的甚至八年,选择做前端的理由也是不尽相同,有的之前做后端,觉得加班太多太累,所以转到了前端,有的觉得前端前途无量,所以选择了前端,有的只是因为个人爱好,所以就做了前端,而我,之前做设计,觉得只做平面过于枯燥,并且想尝试一下新事物,所以学习了前端. 我跟刚入行的

如何快速做一个山寨的实时“大数据”处理

前言为啥写这篇文章?因为我现在做的这套实时计算系统在公司里很难玩下去了.去年年初来到ctrip,主要就是做两个实时应用,一个是实时报警,功能是做出来了,但应用效果不好:一个是XXX(敏感应用,不敢写出来,以XXX代替),也是实现了功能需求,但想继续按自己的思路往下走是不可能了,我捉急的表达能力很难让上头去理解实时计算和传统的request-response方式的应用不同点在哪里,为啥要这么干,也很难明白上头喜欢的系统是什么样的,真是挠破头.我的方式看来是做不下去了,但总觉得还是有点价值,所以写下

SQL Server 2008 R2占用内存越来越大解决方法

最近开发sql server数据库项目的过程中发现了这么一个问题,后台网站内存占用95%,通过任务管理器查看占内存的进程sqlserver.exe,是因为SQL Server 2008 R2运行越久,占用内存会越来越大. 因为sql server 2008 本身内存回收机制做的不好 所以只能这么强制设置.现在明白了,原来是微软R2系列的服务器&数据库问题的通病. 方法: 进入Sql server 企业管理器,在数据库服务器名称上点击[右键],选择[属性],然后,找到[内存]选项,在右边的[使用A

毕业 3 年,为何技术能力相差越来越大?——转自阿里技术人生

为什么你的知识积累不了? 有些知识看过就忘.忘了再看,实际碰到问题还是联系不上这个知识点.这其实是知识的积累出了问题,没有深入理解好,自然就不能灵活运用,也就谈不上解决问题.大家一起看相同的高考教科书但是高考结果不一样,问题出在了理解上.每个人的理解能力不一样(智商),绝大多数人对知识的理解要靠不断地实践(做题)来巩固. 同样实践,效果不一样? 同样工作一年碰到了 10 个问题(或者说做了 10 套高考模拟试卷),但是结果不一样,那是因为在实践过程中方法不够好.或者说你对你为什么做对了,为什么做

做前端也被鄙视?

每一个程序员应该都听说过程序员鄙视链,做c的看不起做c++的,做c++看不起做java的,做java看不起做.net的,这些所有都看不起搞前端的,可以说,前端程序员应该处于程序员鄙视链的底端. 前端在行业中,之所以被鄙视的原因,完全是因为,入门简单,早期的前端俗称美工.切图仔,每天的工作就是切图.写写html.写写css,在java亦或者c语言开发者眼中,就是渲染一下网页,没多大难度. 然而,在现在的工作中,前端工程师已经不仅仅是切切图,在一定程度上,我甚至认为前端比后端更难.更重要. 前端工程

前端什么技术越来越重要,哪些前端框架有前景

前端什么技术越来越重要?哪些前端框架有前景?近年来,Web前端市场前景火爆吸引了很多人加入其中,"低端饱和.高端紧缺"的市场行情要求人们不断提升自己的专业技能.互联网更迭迅速,未来前端有哪些技术会越来越重要呢?下面就给大家分享几个比较有前景的前端框架. 1.Vue Vue是一套用于构建用户界面的渐进式框架.与其它大型框架不同的是,Vue被设计为可以自底向上逐层应用.Vue的核心库只关注视图层,不仅易于上手,还便于与第三方库或既有项目整合.另一方面,当与现代化的工具链以及各种支持类库结合