本文转自公众号：阿里科技作者：视频攻略前端应用越来越复杂，技术框架也在不断变化。如何成为一名优秀的前端工程师，应对更大的挑战？今天，阿里巴巴前端技术专家慧影结合实际工作经验，积累了五个重要的方法，希望对你的职业发展和团队合作有所启发。过去一年，阿里巴巴新零售事业群支撑的数据相关业务实现了跨越式增长。两大核心平台级产品代码量快速增长，协同开发者增加至数十人。由于历史原因，开发框架同时基于React和Angular。考虑到产品的复杂性、人员的短缺和不同的技术背景，我们尝试了各种方法对工具系统进行打磨，以提高开发效率。这里有五点。1、基于Redux的状态管理从2013年React发布至今已经将近6年，前端框架逐渐形成了React/Vue/Angular三足鼎立的格局。几年前还在争论单向绑定和双向绑定的优缺点。现在三大框架都选择了单向绑定，双向绑定变成了纯粹的语法糖。框架之间的差异越来越小，加上Ant-Design/Fusion-Design/NG-ZORRO/ElementUI组件库的成熟，选择自己熟悉的任何框架都可以高效的完成业务。那么下一个核心问题是什么？我们将其视为状态管理。对于简单的应用，在组件中使用State是方便快捷的，但是随着应用复杂度的增加，你会发现数据分散在不同的组件中，组件通信会变得异常复杂。我们尝试了原生的Redux、Fractal的Fractal思想、自研的Mobx框架、AngularService，最终相信Redux仍然是复杂应用数据流处理的最佳选择之一。幸运的是，除了React社区，Vue社区也有类似的Vuex，Angular社区也有提供几乎相同能力的NgRx。甚至NgRx也可以无缝地使用redux-devtools来调试状态变化。不管怎么优化，都必须始终遵循Redux的三个原则：我们通过自研的iron-redux库[1]来解决这三个问题。以下是背后的思考：如何组织Actions？action类型需要全局唯一，所以我们给action类型加了前缀，其实就是namespace的概念；为了追求体验，请求（Fetch）场景需要处理3个状态，分别对应LOADING/SUCCESS/ERROR这3个action，我们使用FetchTypes类型自动生成对应3个action。如何组织Store/Reducer？reducer和view不需要一一对应。应用中同时存在组件树和状态树，根据各自的需要组织起来，通过connect将状态树的一个或多个分支绑定到组件树上；通过构建一些预设数据类型的样板代码来减少数量。对于Fetch返回的数据，我们定义了AsyncTuple的类型，减少样板代码；清晰的组织结构，第一层是ROOT，第二层是每个页面，第三层是页面中的卡片，第四层是卡片中的数据，所以最深的划分基本不会超过5层。最后我们得到如下扁平化的状态树。大而有条理，您可以快速、清晰地访问任何数据。如何减少样板代码？使用原生Redux，一个常见的请求处理如下。非常冗余，这也是Redux被很多人诟病的原因：使用iron-redux后：代码量减少三分之二！！主要做这两点：引入默认的AsyncTuple类型，就是{data:[],loading:boolean,error:boolean}这样的数据结构；使用AsyncTuple.handleAll来处理LOADING/SUCCESS/ERROR这三个action，handleAll的代码很简单，就是用if判断action.type的后缀，源码[2]。React和Angular曾经是两个很难调和的框架，我们在开发上浪费了很多人力。通过使用轻量级的iron-redux，充分遵循Redux的核心原则，我们在内部实现了除组件层外几乎所有代码的复用。约定开发规范和工具库，开发者可以无缝切换，将框架差异带来的额外成本降到很低的水平。2、全面拥抱TypeScriptTypeScript目前非常流行。根据2018stateofjs[3]，其使用率超过50%，满意率90%。甚至Jest也在从Flow转向TS[4]。如果你还没有用过，可以考虑换用，肯定会给项目带来很大的提升。在过去的一年里，我们从部分使用TS转为完全使用TS，包括我们自己开发的工具库等等。TS最大的优势在于提供了强大的静态分析能力，结合TSLint，可以对代码实施更严格的检查约束。由于传统的EcmaScript没有静态类型，即使使用ESLint，它也只能做非常基本的检查。有些错字问题可能要等到线路上出现bug时才会发现。下图是前端应用常见的4层架构。代码和工具全面拥抱TS后，实现了从后端API接口到View组件的全链路静态解析，具有完善的代码提示和校验能力。除了上面提到的iron-redux，我们还引入了Pont[5]来实现前端访问，可以自动将后端API映射到前端可以调用的请求方法。Pont实现原理：（法语：bridge）是我们开发的一个前端接入层框架。对接的后端API使用JavaSwagger，可以提供所有API的元信息，包括请求和响应类型格式。Pont解析API元信息生成TS访问函数。这些访问函数是完美类型的，挂载在API模块下。最终代码中取号的效果如下：Pont实现如下效果：根据方法名自动匹配url和方法，完美对应prams和响应类型，并能自动提示；后端API接口更改后，前端关联的请求会自动报错，不用担心后端在前端不知情的情况下悄悄更改接口；无需前后端接口协议文档，通过代码保证前端接入与后端接口定义完全一致。另外，iron-redux可以接收Pont接口响应数据格式，推导出整个Redux状态树的静态类型定义，Store中的数据有完善的类型提示。效果如下：最终，TS让代码更加健壮，尤其是对于大型项目。编译通过几乎就意味着运行正常，也为重构增加了很多底气。3.回归Sass/Less2015年开始实践CSSModules，包括后来的styled-components等，到了2019年，css-in-js的方案还在争论中。虽然确实解决了一些CSS语言固有的问题，但是也增加了很多成本，对新手不够友好，全局样式覆盖成本高，伪类处理复杂，与component结合有坑AntD等库。与此同时，Sass/Less社区也在快速发展，尤其是Stylelint[6]的成熟，可以通过技术约束避免CSSBadParts。全局污染：约定每个样式文件只能有一个顶级类，如.home-page{.top-nav{//},.main-content{//}}。Stylelint规则可用于检测并警告是否存在多个顶级类。依赖管理不彻底。借助webpack的css-loader，就足够了。JS和CSS变量是共享的。关于JS和Sass/Less变量的共享，我们找到了自己的解决方案：在scss文件中，可以直接引用变量：4.开发工具覆盖全链路2019年，你想开发React/Angular几乎不可能/Vue级框架，无需像Ant-Design/Fusion-Design/Ng-Zorro那样重新造轮子。没有机会了吗？当然还有很多机会结合自己的产品研发过程。下面是一个常规项目的开发流程图。任何一个环节只要挖深了，就有提升的空间。如果能通过工具减少一个或多个环节，带来的价值会更大。单看【开发】环节，可扩展的场景有很多：一个有代表性的例子就是我们开发了国际化工具kiwi[7]。它还具有TS的完美类型和非常强大的复制提示。另：VSCode插件kiwilinter【8】，自动将中文文案标记为红色，若已有翻译文案可自动完成替换；翻译后的文案分批提交给译员；Codemod脚本以极低的成本自动将旧的国际化方案迁移到Kiwi。除了以上三点，未来还计划开发浏览器插件检查漏文，在git提交前使用Husky自动对漏文进行机器翻译等。未来如果只提供代码库，其价值将非常有限。大家可以参考上图开发相应的扩展来丰富生态。如果是新手，建议学习一下编译原理和相应的扩展开发规范。5.严格彻底的CodeReview在过去的一年里，我们总共进行了1200+CodeReview（CR）。有了别人的Review，CR就成了大家的习惯。通过CR，项目中的任何一行代码都被至少两个人接触过，减少了大部分低级错误，提高了代码质量。这也是帮助新人成长最快的方法之一。CodeReview的几个技巧：没有魔法；显式而非隐式；覆盖比深度更重要，覆盖率100%；频率比仪式更重要。坐在公交车上，蹲在厕所里，打开手机就可以审查别人的代码，不需要组织专门的会议；粒度尽量小，可以采用一种组件一种方法，可以结合GitFlow；24小时内可以处理，没有问题可以直接合并。如果有问题，您必须发表评论并提供操作；对于急需上线，不能及时review的代码，可以先合并上线，上线后再添加Review；需要自上而下的推进，有完善的规范，定期总结Review经验，丰富开发规范；CR不只是找错，看到好的代码，不要吝啬你的表扬；其实质是鼓励开发者之间多交流，互相学习，营造技术文化氛围。总结以上5点肯定不是我们技术的全部。另外，我们也实践过移动端开发、可视化图表/WebGL、WebWorker、GraphQL、性能优化等，不过这些还停留在技术层面，以后会做一定程度的分享。如果你也在准备或正在开发复杂的前端应用，团队成员技术背景多样，可以参考以上5点，使用Redux实现标准化、清晰可预测的状态管理，深耕TypeScript提升代码的健壮性和可维护性。借助各种lint工具，回归简单便捷的CSS，不断打磨自己的开发工具，确保高效的开发规范，严格彻底的实施CodeReview，促进人们的交流和改进。关于本文八个参考教程链接，欢迎在评论区留言或私信我！欢迎关注公众号：fkdcxy疯狂程序员，获取更多前端教程！
