关于前端工程化:构建高质量的前端工程

在过来，与大多数工程师一样，我认为前端代码的设计程度大多与工程师的能力有间接关系。但随着接手了几个多人合作的大型前端我的项目，我开始意识到，这种认知对短生命周期的小型我的项目可能实用，但对真正的大型项目，仅靠晋升工程师品质有时并不能间接晋升代码的品质。

本文将联合本人的一些理论教训，来论述本人的一个观点：构建大型高质量前端工程，正当的代码束缚与正确的团队运行机制可能更为重要。

什么是高质量的工程代码？

高质量的工程代码，并不等价于性能最优，技术最新，复用性最强的技术选型。回顾几年前的前端畛域：JQuery 时代，尽管要手动操作 DOM，但其实在那时，Google Closure 和 Ext.js 团队就曾经提供了残缺的组件化概念，甚至 Ext.js 还提供了组件冒泡这样的翻新事件机制。那时用 Zepto 保护的代码，编码速度甚至比当初写一些 React 我的项目还要快。不同的技术只是工具，怎么用工具，能把工具用到什么水平，最终取决于开发者本身，所以高质量的工程代码，更多应该从业务和工程的角度思考问题，而非技术选型。

举个例子，当整个公司都在应用 React 开发时，尽管咱们晓得 Vue 应用可能会更简略便捷，但咱们肯定不会去用，因为这个时候，尽管看起来写代码更简略了，但其他人在 React 方向积淀的教训，你无奈复用，额定还须要整个团队去学习一套全新的技术，这样的工程设计，在这个背景下，显然是不合理的。

Thenewstack 做过 2019 年的开发者数据统计，开发者 32% 的工夫用于业务开发，19% 的工夫在保护代码，也就是工程师真正能投入到研发中的工夫也只有工作工夫的一半。对于开发者来说，这个时候通过正当的代码设计，晋升代码的 可扩展性，可维护性，升高开发和保护代码的工夫，才是最强的诉求。

所以，高质量的工程代码应该是 联合业务与团队状况 ，真正可能 晋升研发效率 ， 升高我的项目保护老本 的代码。

谁决定了工程代码的品质？

这里能够用木桶实践来类比：木桶中的水位，不取决于最高的木板，而取决于最低的木板。同理，前端工程的品质，不取决于团队的均匀能力，而取决于团队教训较少的技术同学的能力。在工作压力比拟大的状况下，这些同学因为经验不足，短期又要实现需要，所以很多时候，并没有思考过工程上的问题，而是间接面向实现性能编程，基本上咱们当初面对的难以保护的代码，都是在这种条件下产生的。

咱们当然能够寄希望于教训较少的同学通过一直的成长来晋升我的项目的工程质量，但实际下来，这并不可行。起因在于，工程能力的积攒须要大量的编码教训，短少实践经验的问题并不是短期就可能迅速解决的，任何好的工程师都是在一直犯错学习的过程中成长起来的。同时，工程开发过程中很可能会遭逢人员变动，一个团队的成员不肯能永远全部都是能力很强的。

那么咱们就须要换一个策略来保障咱们的代码品质，咱们能够换个角度思考：是否能够通过一些规定，流程，编码上的 束缚，让编码能力不同的工程师，尽量写出品质绝对较高的一致性代码。

通过束缚晋升工程质量

束缚让事件变得更简略

工作没有束缚，工作中咱们就难以造成共识，也无奈判断工作做的好与坏。写代码也是一样的，没有束缚，那么咱们也无奈判断代码是否正当。在风行的库和框架中，其实到处都是束缚的影子，这里拿 Redux 和 React 的设计来举例: Redux 给出了繁多数据源，State 只读，应用纯函数来执行批改这三个根本准则，同时要求通过 Action 的形式触发 Reducer 的执行，这是 Redux 的束缚；React 也给出了单向数据流这样的束缚概念。

框架之所以是可能复用，可能失去推广，就是因为它们进行了封装，仅仅提供无限的束缚能力供大家应用，这样大家能力造成统一的理念，编写相互可能读得懂的代码。了解了这一点，咱们再来看业务工程的代码，实际上要进步开发效率和扩展性，无非也是要提供正当的束缚。

工程代码的束缚，更多带有肯定的工程属性，如：

• 规定雷同的申请地址只容许在 API 层呈现一次（我的项目接口数目多，可缩小代码冗余）
• 不应用超过 100 行以上的 Hook 代码（强化逻辑拆分，防止适度简单的逻辑）
• 在复用性和可维护性上做抉择时，优先选择可维护性（防止谬误封装，封装代码中耦合大量逻辑判断）
• 业务代码正文覆盖率必须超过 10%（晋升代码可读性，不便自动化生成文档）
• 我的项目中跨组件通信必须通过 Redux（升高组件传值代码的团队了解老本）
• 雷同性能的 npm 包不容许装置多个（防止无用依赖装置，造成保护成本增加）

这些业务的束缚，并不等同于 Eslint，不同的业务对代码的要求有可能千差万别，所以业务上的束缚，须要研发人员充沛的沟通交流，碰撞探讨，以及坚决执行。不同团队的同学，可能探讨出的后果齐全不同，但 束缚的论断是什么自身不重要，重要的是造成统一的开发共识。

通过机制实现束缚的落地

束缚自身并不难制订，对于工程侧的设计，工程师通过探讨比拟容易造成博奕后的论断。但机制的落地是绝对艰难的一环。这里分享几个可执行的保障机制：

• CodeReview（每次 CR，除了对业务进行逻辑剖析，也须要将是否遵循束缚作为审核的一环）
• 通过工具主动生成局部代码（比方应用脚手架生成工程代码中的某个模块，相似 AngularCLI 中 ng g component header 这样的指令，就能够帮你束缚组件创立的代码构造）
• 配置化生成代码（通过配置，生成逻辑或者表单代码，建设配置项规范）
• 零代码 / PaaS 平台（通过平台生成代码，间接将用户与编码隔离，由平台保障生成代码的品质）
• 负责人机制（束缚落地间接与绩效相关联，成为跟进明确指标）
• 积淀文档（通过文档，积淀束缚机制）

通过这样的一些机制，保障束缚无效的落地，那么咱们就能够抹平团队成员技术能力的差别，造成一致性的编码格调。尽管这种束缚下的代码并不一定是最优雅的代码，但至多工程质量不会差。所以这里我认为，束缚实际上帮忙咱们保障的是工程质量的上限，那么接着咱们来谈如何通过技术创新，晋升工程质量的下限。

在束缚之上寻求翻新

大家可能会有这样的问题：“我的项目的束缚，会不会限度技术的翻新”。针对短生命周期的小型我的项目，这可能是对的，这种我的项目，应用更多的新技术进行摸索冲破可能会带来更多的团队技术储备；但对于大型项目来说，咱们每天所做的代码设计决策，都可能会影响到今天业务零碎的倒退过程，任何技术升级都肯定要谨慎，这时候，咱们不应该把束缚当作翻新的妨碍，而应该把束缚当作翻新的练兵场。

如果你在大型项目中，想冲破束缚，应用新技术，进行技术革新，那么肯定意味着你要做到以下几件事件：

1. 对过来束缚限度的背景有充沛理解：背景没有扭转，新技术是否能解决束缚所解决的问题，同时不会带来新的问题
2. 可能充沛表述新技术所可能带来的价值：在造成共识的问题上，新技术是否能对性能，稳定性，体验，研发效率，业务提效有显著作用
3. 可能给出技术升级的整体计划：在确认要进行技术升级时，你是否思考到历史技术计划如何优雅的实现替换
4. 可能压服团队认可新的技术升级计划：在以后已有技术的根底上，你是否能压服团队成员和你一起推动技术创新
5. 可能率领团队或者本人将技术计划落地：你是否具备能力将新技术或者翻新点实现落地

很多时候，咱们做的技术创新，其实只是技术栈的更新，并没有为团队和业务侧带来任何的价值，但当咱们想分明这些问题，可能有服气力的证实新技术或者翻新点是有价值的时候，对于零碎的降级可能才是真正有价值的。

在束缚上的翻新，能够让工程师联合业务有更多的思考，产出真正有价值的翻新。而 这些有品质的思考和翻新，决定了工程质量的下限，同时也会造就出更多优良的工程师。

如何晋升已有工程质量？

对于一个全新的大型项目，咱们能够通过上述的形式，分阶段进行架构设计和优化。然而，大多数状况下，咱们接手的我的项目，可能在接手时就会发现其工程质量较低，那么咱们应该如何对已有代码进行改进呢？

判断你的零碎是否须要改进

一个零碎的生命周期，能够总结为三个阶段：

• 发展期：业务倒退迅速
• 稳定期：业务状况稳固
• 衰退期：业务逐步关停并转

对于发展期的零碎和稳定期的零碎来说，正当的工程设计将来能带来的性能，稳定性等方面的收益非常显著，这个时候，咱们能够思考对系统进行技术升级。而对于衰退期的零碎，尽管短期开发保护效率不高，但无奈看到将来零碎的发展潜力，这时候，持续保护老零碎可能是一个更好的抉择。并不是每一个零碎都必须要改进，精益求精诚然好，但是否要做还是要回归到对业务价值的判断上。

如何进行工程改良

大型项目的工程改进，能够分为两种形式，自上而下 ，和 自下而上 。对于大型项目来说，自上而下的全副重构，老本很大，除非你对系统特地理解，否则并不举荐采纳这种办法。相同，目前的支流框架，React，Vue 都是能够对部分 DOM 进行托管的，所以自下而上的逐渐降级可能是更好的策略，这种办法有两个劣势： 成本低，危险小。举个本人工程中的例子，咱们须要把 JQuery 降级至 React，采纳了这种形式，逐层向上的对 JQuery 中的 Backbone 代码进行替换：

export default View.extend({
  componentName: 'AuctionDetailContainer',
  initialize(options) {const { dataSchemaV1, pageSchema} = options;
    this.ref = React.createRef();
    this.dataSchemaV1 = dataSchemaV1;
    this.children = pageSchema.getChildren()[0];
    this.attributes = pageSchema.getAttributes() || {};
  },

  render() {
    ReactDOM.render((
      <AuctionDetailContainerWithRef
        ref={this.ref}
        taskFields={this.dataSchemaV1}
        attributes={this.attributes}
        crossTableData={this.children}
      />
    ), this.$el[0]);
    return this;
  },

});

每一次替换，咱们只有测试替换局部的逻辑即可，不会影响内部的其余逻辑，这样逐层替换，在保障稳定性和系统升级的双向要求下，做到了很好的均衡。同时，在接手新我的项目的时候，这种降级的办法还能够逐渐帮你梳理分明业务的逻辑，理解业务。

在这样的逐渐替换过程中，联合之前说到的编码束缚，咱们就能够将零碎的代码品质逐渐实现晋升。而之后，则能够通过翻新的形式，进一步对我的项目优化欠缺，从而实现整个重构过程。

在这个过程中，有一些工具也能够帮忙到咱们，举几个例子：

• CommintLint + SemVer 语义化版本号管制标准：帮忙团队明确重构可能带来的危险，节约沟通老本
• 前端自动化测试工具：通过单元测试保障工程质量，升高回归谬误产生概率
• Chrome Coverage：代码执行状况剖析工具，帮忙你找到无用代码，梳理我的项目逻辑

结语

本文波及到的具体编码内容不多，心愿从另一个方面可能给你带来一些工程测的启发和思考，一些观点抵触也欢送大家沟通探讨。

文章可随便转载，但请保留此原文链接。
十分欢送有激情的你退出 ES2049 Studio，简历请发送至 caijun.hcj@alibaba-inc.com。