2019 给前端的五个建议

来源：南京网页设计培训学校时间：2019/3/27 15:24:26

　　019 农历新年即将到来，是时候总结一下团队过去一年的技术沉淀。过去一年我们支撑的数据相关业务突飞猛进，其中两个核心平台级产品代码量分别达到30+万行和80+万行，TS 模块数均超过1000个，协同开发人员增加到20+人。由于历史原因，开发框架同时基于 React 和 Angular，考虑到产品的复杂性、人员的短缺和技术背景各异，我们尝试了各种方法打磨工具体系来提升开发效率，以下是节选的5项主要方法。

　　一、基于 Redux 的状态管理

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

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

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

　　如何组织 Action?

　　action type 需要全局惟一，因此我们给 action type 添加了 prefix，其实就是 namespace 的概念

　　为了追求体验，请求(Fetch)场景需要处理 3 种状态，对应 LOADING/SUCCESS/ERROR 这 3 个action，我们通过 FetchTypes 类型来自动生成对应到 3 个 action

　　如何组织 Store/Reducer?

　　reducer 和 view 不必一一对应，应用中同时存在组件树和状态树，按照各自需要去组织，通过 connect 来绑定状态树的一个或多个分支到组件树

　　通过构造一些预设数据类型来减少样板代码。对于 Fetch 返回的数据我们定义了 AsyncTuple 这种类型，减少了样板代码

　　明确的组织结构，第1层是 ROOT，第2层是各个页面，第3层是页面内的卡片，第4层是卡片的数据，这样划分深处基本不会超过5层

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

　　如何减少样板代码?

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

　　Pont 实现的效果有：

　　根据方法名自动匹配 url、method，并且对应到 prams、response 类型，并能自动提示

　　后端 API 接口变更后，前端相关联的请求会自动报错，再也不担心后端悄悄改接口前端不知晓

　　再也不需要前后端接口约定文档，使用代码增加前端取数和后端接口定义完全一致

　　三、回归 Sass/Less

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

　　全局污染：约定每个样式文件只能有一个类，如 .home-page{ .top-nav {/**/}, .main-content{ /**/ } }。如果有多个类，可以使用 Stylelint rule 检测并给出警告。

　　依赖管理不彻底。借助 webpack 的 css-loader，已够用。

　　JS 和 CSS 变量共享。关于 JS 和 Sass/Less 变量共享，我们摸索出了自己的解法：

　　四、开发工具覆盖全链路

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

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

　　五、严格彻底的 Code Review

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

　　Code Review 的几个技巧：

　　No magic

　　Explicit not implicit

　　覆盖度比深度重要，覆盖度追求

　　频率比仪式感重要，坐公交蹲厕所打开手机都可以 Review 别人代码，不需要专门组织会议

　　粒度要尽可能小，一个组件一个方法均可，可以结合 Git Flow

　　24h 小时内处理，无问题直接 merge，有问题一定要留 comment，并且提供 action

　　对于亟待上线来不及 Review 的代码，可以先合并上线，上线后再补充 Review

　　需要自上而下的推动，具有完善的规范，同时定期总结 Review 经验来丰富开发规范

　　CR 并不只是为了找错，看到好的代码，不要吝啬你的赞美

　　本质是鼓励开发者间更多的沟通，互相学习，营造技术文化氛围

尊重原创文章，转载请注明出处与链接：http://www.peixun360.com/459/news/831/违者必究！ 以上就是南京网页设计培训学校 小编为您整理 2019 给前端的五个建议的全部内容。