在大型项目中，如何去构建高质量的前端工程，字节跳动前端研发岗这些知识点内部泄露出来了-CSDN博客

本文链接：https://blog.csdn.net/m0_57889860/article/details/136880143

规定相同的请求地址只允许在 API 层出现一次（项目接口数目多，可减少代码冗余）
不使用超过 100 行以上的 Hook 代码（强化逻辑拆分，避免过度复杂的逻辑）
在复用性和可维护性上做选择时，优先选择可维护性（避免错误封装，封装代码中耦合大量逻辑判断）
业务代码注释覆盖率必须超过 10%（提升代码可读性，方便自动化生成文档）
项目中跨组件通信必须通过 Redux （降低组件传值代码的团队理解成本）
相同功能的 npm 包不允许安装多个（避免无用依赖安装，造成维护成本增加）

这些业务的约束，并不等同于 Eslint，不同的业务对代码的要求有可能千差万别，所以业务上的约束，需要研发人员充分的沟通交流，碰撞探讨，以及坚决执行。不同团队的同学，可能讨论出的结果完全不同，但约束的结论是什么本身不重要，重要的是形成一致的开发共识。

通过机制实现约束的落地

约束本身并不难制定，对于工程侧的设计，工程师通过讨论比较容易形成博奕后的结论。但机制的落地是相对困难的一环。这里分享几个可执行的保障机制：

CodeReview（每次CR，除了对业务进行逻辑分析，也需要将是否遵循约束作为审核的一环）
通过工具自动生成部分代码（比如使用脚手架生成工程代码中的某个模块，类似 AngularCLI 中 ng g component header 这样的指令，就可以帮你约束组件创建的代码结构）
配置化生成代码（通过配置，生成逻辑或者表单代码，建立配置项标准）
零代码 / PaaS 平台（通过平台生成代码，直接将用户与编码隔离，由平台保障生成代码的质量）
负责人机制（约束落地直接与绩效相关联，成为跟进明确指标）
沉淀文档（通过文档，沉淀约束机制）

通过这样的一些机制，保障约束有效的落地，那么我们就可以抹平团队成员技术能力的差异，形成一致性的编码风格。虽然这种约束下的代码并不一定是最优雅的代码，但至少工程质量不会差。所以这里我认为，约束实际上帮助我们保障的是工程质量的下限，那么接着我们来谈如何通过技术创新，提升工程质量的上限。

在约束之上寻求创新

大家可能会有这样的问题：“项目的约束，会不会限制技术的创新”。针对短生命周期的小型项目，这可能是对的，这种项目，使用更多的新技术进行探索突破可能会带来更多的团队技术储备；但对于大型项目来说，我们每天所做的代码设计决策，都可能会影响到明天业务系统的发展进程，任何技术升级都一定要慎重，这时候，我们不应该把约束当作创新的阻碍，而应该把约束当作创新的练兵场。

如果你在大型项目中，想突破约束，使用新技术，进行技术革新，那么一定意味着你要做到以下几件事情：

对过去约束限制的背景有充分了解：背景没有改变，新技术是否能解决约束所解决的问题，同时不会带来新的问题
能够充分表述新技术所能够带来的价值：在形成共识的问题上，新技术是否能对性能，稳定性，体验，研发效率，业务提效有明显作用
能够给出技术升级的整体方案：在确认要进行技术升级时，你是否考虑到历史技术方案如何优雅的实现替换
能够说服团队认可新的技术升级方案：在当前已有技术的基础上，你是否能说服团队成员和你一同推进技术创新
能够带领团队或者自己将技术方案落地：你是否具备能力将新技术或者创新点完成落地

很多时候，我们做的技术创新，其实只是技术栈的更新，并没有为团队和业务侧带来任何的价值，但当我们想清楚这些问题，能够有信服力的证明新技术或者创新点是有价值的时候，关于系统的升级可能才是真正有价值的。

在约束上的创新，可以让工程师结合业务有更多的思考，产出真正有价值的创新。而这些有质量的思考和创新，决定了工程质量的上限， 同时也会培养出更多优秀的工程师。

如何提升已有工程质量？

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

判断你的系统是否需要改良

一个系统的生命周期，可以总结为三个阶段：

发展期：业务发展迅速
稳定期：业务情况稳定
衰退期：业务逐渐关停并转

对于发展期的系统和稳定期的系统来说，合理的工程设计未来能带来的性能，稳定性等方面的收益十分明显，这个时候，我们可以考虑对系统进行技术升级。而对于衰退期的系统，虽然短期开发维护效率不高，但无法看到未来系统的发展潜力，这时候，继续维护老系统可能是一个更好的选择。并不是每一个系统都必须要改良，精益求精固然好，但是否要做还是要回归到对业务价值的判断上。

如何进行工程改进

大型项目的工程改良，可以分为两种方式，自上而下，和自下而上。对于大型项目来说，自上而下的全部重构，成本很大，除非你对系统特别了解，否则并不推荐采用这种方法。相反，目前的主流框架，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() || {};

小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数初中级前端工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！
因此收集整理了一份《2024年Web前端开发全套学习资料》送给大家，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。