--- title: 01-2022年Web前端开发流程和学习路线（详尽版） --- > 本文的最新内容，更新于 2022-06-27，会在[GitHub](https://github.com/qianguyihao/Web/blob/master/17-%E5%89%8D%E7%AB%AF%E7%BB%BC%E5%90%88/01-2022%E5%B9%B4Web%E5%89%8D%E7%AB%AF%E5%BC%80%E5%8F%91%E6%B5%81%E7%A8%8B%E5%92%8C%E5%AD%A6%E4%B9%A0%E8%B7%AF%E7%BA%BF%EF%BC%88%E8%AF%A6%E5%B0%BD%E7%89%88%EF%BC%89.md)上同步更新，欢迎 star。大家完全不用担心这篇文章会过时，因为随着前端领域的技术更新，本文也会随之更新。 ## 前言 前端侧重于人机交互和用户体验，后端侧重于业务逻辑和大规模数据处理。理论上，面向用户的产品里，所有问题（包括产品、设计、后端、甚至看不见的问题）的表现形式，都会暴露在前端，而只有部分问题（数据问题、计算问题、安全问题等）暴露在后端，这就意味着前端起到了至关重要的承载和连接作用。 前端技术的更新日新月异；前端框架的技术选型百家争鸣；视觉审美的潮流不断更替；可视化效果酷炫无比；用户的运营体系逐渐精细化；适老化、无障碍化、青少年人群的诉求浮出水面；智能设备的升级和适配无穷无尽。所有的这一切，对前端领域和前端同学就一个要求：要折腾，爱折腾，反复折腾。 ## 一、前端开发流程 ### 需求分析 - 需求背景和业务价值 - 需求点分析 - 业务流程和业务逻辑 - 原型和交互设计 - 输出PRD ### 需求评审 > 一般在做需求评审时，PRD里只有交互稿，尚未有视觉稿。需要在评审结束并达成一致后，再输出视觉稿。 1、需求分析：需求点逐一讨论、需求合理性、交互评审、逻辑梳理，以及可能遗漏的部分。 提示：逻辑梳理的过程很花时间，贯穿开发始末。 2、涉及渠道/环境： > 渠道和环境，往往是需求盲点，也是影响技术选型和开发进度的关键因素。 - App：App原生页面、**App内嵌H5**、App内嵌小程序。 - 小程序：技术栈视角：小程序原生页面、**小程序内嵌H5**、App内嵌小程序。 - 普通H5：微信H5、M站（即普通浏览器环境） - B端：运营管理平台等等 3、可行性分析：是否有技术上的实现难点，是否有其他的依赖条件。 数据来源：哪些是调接口，哪些是做成**可配置**，哪些是前端写死；可配置的部分，是前端读取，还是接口读取然后返给前端。提示：可配置的灵活性与风险正相关。 异常流设计：容错、容灾、兜底、降级、回退机制、风险可控。prd一般只写了正常流的逻辑，异常流往往需要研发同学配合做全盘考虑。 6、需求变更：如有需求不明确、改需求、加需求、砍需求、加时间、改时间、加人力等等，需要提前预判风险。 ### 视觉评审 1、进度跟进：**视觉稿是分批交付，还是一次性给到**？这是要首先考虑的。 按照历史经验，前端项目进度的延误，有一半的概率依赖于视觉稿的进度；因为一个新页面的开发，前端有30%~50%的工作在做页面构建。 2、视觉稿的文件格式： - Sketch 原型设计软件：.sketch 格式。一般用来画**视觉稿**。 - Figma 原型设计软件：.fig 格式。 - Axure 原型设计软件：：.rp 格式。Axure 一般用来画**交互稿**。如果是输出高保真的视觉稿，推荐用 Sketch 或 Figma。 - Photoshop 软件： .psd 格式。专门做**图片处理**。当然，有些CP外包人员的技能单一，喜欢用PS输出视觉稿。 - Adobe Illustrator 软件（简称AI软件）：.ai格式。制作矢量图。 - Adobe After Effects（AE） 软件：.aep 格式。制作动画。 备注：Sketch 是Mac平台独有的原型设计软件，最为知名和常见。[Figma](https://www.figma.com/community/file/1038450359694759149) 是最近比较火的全平台原型设计软件，有取代 Sketch 的趋势。 【划重点】交付视觉稿时，需要视觉同学输出“**带尺寸标注**”的视觉规范文件。 3、检查需求：是否覆盖需求和交互设计中的全部设计点。 4、检查视觉规范： - 样式和配色，是否符合页面和产品的整体风格。 - 尺寸规范：移动端的视觉稿宽度是750px。 - 排版、对齐、一致性。推荐阅读书籍《写个大家看的设计书》，了解基本的设计原则。 - 字体：字号大小（一般是12px以上，特别小的是10px以上）、字重（注意bold属性值为700），以及有哪些**特殊字体**。尤其要注意字体的版权问题。 5、哪些图是前端构建，哪些图是写死图片资源，哪些是可配置；可配置的图中，需要把每个元素做拆解，这个元素是合并到背景图中，还是单独切图，还是读取数据。 6、切图格式：png（透明格式）、jpg 切图的图片大小，不要太大。移动端的大图（比如幕帘弹窗的背景图）建议不超过50kb，小图建议不超过20kb。图片在上传之前，可以先在 https://tinypng.com/ 上进行压缩。 7、复杂图形、动画的实现难度和实现方式，技术评估。详见接下来要讲的「技术选型」。 ### 排期评估 1、排期一般包含这几个要素： - 开发时间：视觉构建时长、接口文档（接口协议）交付时间、前后端联调时间、自测时间 - 转体验时间 - 转测时间 - 上线时间（以及，需确认业务投放时间） 2、评估排期时，**要根据视觉稿排期**，不要根据交互稿排期。这是首先要强调的。一个新页面的开发，前端有30%~50%的工作在做页面构建。 只看交互稿的话，无法评估真实的开发工作量。 3、前端开发工作包括：概要设计、视觉构建、逻辑代码、前后端联调、自测、转体验。每一项都要单独拆解后评估时间，加在一起就是整体的排期。 4、排期时，要考虑其它的依赖因素：比如视觉稿延期、需求不明确、接口进度、测试进度，当然最重要的是上线进度。紧急项目，经常是根据上线时间倒推开发排期。 5、即将进入开发阶段后，与测试部门协调测试资源，确认转测时间；大型项目&重点项目，需要在需求评审阶段，提前知会测试部门，让其预留时间。 6、如果自己有在并行开发其他项目，则排期时需要给自己预留 buffer。并行开发两个项目是家常便饭；但，这个项目在测试时，往往很难抽身去做别的项目，因为会一直被测试童鞋牵制。 7、开发排期：如果开发排期有变更，需要立即周知其他相关人员，尤其是要评估测试排期的风险。测试排期比开发排期 更难变更。 ### 技术选型 > 技术选型千变万化，百家争鸣。这里需要列出你所在部门的常用技术选型，并非市面上的技术栈罗列。 1、页面开发框架： （1）多端页面：（小程序原生页面、H5） - [Taro 框架](https://taro-docs.jd.com/)（基于 React技术栈） 注2：有些业务，一开始只做H5，后来迭代时，要求做小程序原生页面。这一点也要纳入需求评估。 （2）H5页面：[Vue.js](https://v3.cn.vuejs.org/guide/introduction.html) 框架、React 框架 （3）App端： - Android端开发语言：Kotlin（新）、Java（老） - iOS端开发语言：Swift（新）、Objective-C（老） （4）B端开发，UI框架： - React 技术栈：[Ant Design](https://ant.design/index-cn)（简称Antd） - Vue 技术栈：[Element](https://element.eleme.cn/#/zh-CN)、[Ant Design Vue](https://antdv.com/components/overview-cn) - 较简单的CSS响应式框架：[Bootstrap](https://www.bootcss.com/) （5）Node.js后端开发框架： - Koa：新一代 Node.js 框架。 - [Egg.js](https://eggjs.github.io/zh/)：Egg 是在Koa基础上进一步封装的企业级Web开发框架。 - Express：比较老的Node.js 框架。 2、CSS预处理器：SASS 3、复杂图形、动画的实现难度和实现方式，技术评估： - gif 动图：尽量不用。因为文件太大，且效果模糊。 - CSS3 动画：适合简单的、有规律的动画。举例：[摆动的鱼](https://www.cnblogs.com/qianguyihao/p/8435182.html)、[京喜工厂](https://mp.weixin.qq.com/s/u5GHsA0vHz8A_MmGslRw2g) - [Canvas](https://www.liaoxuefeng.com/wiki/1022910821149312/1023022423592576)：Canvas 动画、小程序分享图采用 Canvas 绘制 - 3D动画：[WebGL](https://www.zoo.team/article/webglabout)（[Three.js](http://www.webgl3d.cn/Three.js/) 是 WebGL 的综合库）常见案例：太阳系 - 游戏框架：Cocos 引擎 ### 概要设计 - 需求背景及资源 - 风险评估 - 技术选型 - 项目结构设计 - 主要功能点逻辑设计 - 可扩展可复用设计 - 依赖接口 - 工作量拆解和排期 ### 开发环节 1、代码设计： （1）目录结构设计、代码风格 （2）公共组件、工具类设计：确保**可复用**、高内聚低耦合的原则。哪些可以复用平台的公共组件，哪些需要自己单独写 components、utils。 （3）弹窗设计：如果一个页面有多个弹窗，建议先设计一个抽象的弹窗基类。**设计弹窗时，需要考虑的是**： - 设计原则：易扩展、复用性强 - 避免重复代码 - 避免同一时间出现多个弹窗 - 弹窗的位置要严格居中（不能因为屏幕尺寸的大小变了，导致弹窗位置不居中） - 处理滚动穿透这个顽疾。 2、视觉构建： （1）后端在开发接口时，前端做视觉构建；视觉构建完成后，前端根据接口文档的定义，通过 mock 数据的方式调接口，写前端逻辑；待接口开发完成后，可进入前后端联调阶段。 （2）建议前端童鞋学会自己切图，可控程度更高，也能减少沟通成本。学会基本的 PS、Sketch操作就行，做一名合格的前端切图仔。 （3）对于规则的样式和动画，建议用代码实现，而不是图片。图片会降低页面的打开性能，且大屏都显示效果比较模糊。 （4）切图的尺寸要求：100%宽度以 750px 为准。 （5）**像素级还原视觉稿**：推荐使用 [Snipaste](https://zh.snipaste.com/) 截图软件，按F1截图，F2贴图，然后调整贴图的透明度为50%，将贴图与前端页面进行像素级比对。 3、业务逻辑实现： （1）建议先用**思维导图**，梳理业务逻辑，再着手写代码。思维导图有利于理清逻辑、事后复盘、高效给他人讲解，一目了然。重要的是思想，而不是用哪一款工具更酷。 （2）在调用接口时，要明确前端自己的安全边界：假设接口字段异常时，前端需要有自己的降级措施，不能完全依赖和信任字段，导致让页面直接白屏、交互异常、甚至挂掉。 （3）除了完成产品要求的业务逻辑之外，还要时刻考虑异常流的设计和容灾。 （4）很多前端童鞋在做需求时，有个习惯是不喜欢细看prd，只对着交互稿和视觉稿进行开发。这样做虽然省事，但有三道手续不能少： - 开发前，一定要再和产品童鞋过一遍prd细节； - 开发过程中，随时和产品童鞋反复沟通确认； - 开发到80%时，自己对照prd，只字不差地阅读，看看是否有遗漏的地方。 4、非功能性需求。业务代码写完后，还有很多细节需要打磨。比如： - 不同渠道的分享场景 - 文案配置检查：运营配置端要做校验；是给产品运营用的，配置要尽量人性化。 - 添加埋点：曝光上报、点击上报、呼吸上报 - 监控上报、测试上报、badjs上报 - 重复代码精简 - 去掉 console.log、debugger 等多余的代码 - 图片、字体等静态资源压缩 - 常见的性能优化：骨架屏（按需）、图片懒加载、图片预加载、防抖节流、长列表*滚动*到可视区域动态加载 - 用户体验完善：返回定位、滚动穿透 - 屏幕适配 - 小程序代码瘦身 - 容灾演习 5、代码提交： - 先 git pull，再 git push，减少代码冲突。 - commit粒度要尽量细 - commit之前，一定要diff代码，确认每一行改动，以免提交不必要的改动。 - Commit Message 常用格式：feat、fix、docs、merge - 如合并代码时遇到冲突，一定要先解决完冲突后再提交代码。如冲突部分涉及到其他人的代码，一定要找到对应同学一起解决。 6、自测： - 对照prd，查漏补缺。 - 在真机上体验页面，而不是在模拟器上。 - 写一部分测试用例，加快后续的测试进度。前面梳理的思维导图，其实就是测试的最佳素材。 ### 产品体验 1、在真机体验，而不是在模拟器上。最好是 iOS和 Android 都要对比体验。 2、体验时，记录整理各种 todolist： - 需求待确认 list：一些小的、风险可控的需求点，可以在体检阶段，集中向产品童鞋提出。 - 开发未完成 list：有哪些尚未完成的部分，需要和产品童鞋交代清楚。 - 已知 bug list - 体验问题 list：边体验，边记录产品反馈的问题，并在稍后同步给测试童鞋。 - 依赖项 list：接口、视觉切图、真实的测试环境等等。 ### 代码评审/代码review > 代码 review 可以在测试期间进行。 review顺序： - 业务核心逻辑 - 编码规范 - 关键位置、容易踩坑的地方，需要注释详细 - 系统保障（监控、容灾降级） - 系统安全和风险 - 用户体验 ### 视觉走查 > 视觉走查 可以在测试期间进行。 视觉童鞋都有像素眼，即便是一两个像素的区别，他们都能瞧出来。所以，建议前端童鞋加强自测，努力做到**像素级还原视觉稿**。 推荐前端童鞋使用 [Snipaste](https://zh.snipaste.com/) 截图软件，按F1截图，F2贴图，然后调整贴图的透明度为50%，将贴图与前端页面进行像素级比对。 ### 测试环节 1、建议加强自测质量。进入测试阶段后，测试童鞋会进行一轮冒烟测试，如果质量不合格，将会被打回，这就很尴尬了。 2、整理自测、测试、发布时需要的主流程checkList，每次迭代时都能用上。 转测邮件的基本元素，包括但不仅限于： - prd链接、视觉稿链接 - 页面链接 - 项目相关人员 - 数据配置系统 - host 代理 - 接口文档 - 概要设计、前端开发整理（如果有的话） - 测试用例（如果有的话） - 核心业务逻辑梳理（如果有的话） - 体验问题列举 - 测试重点建议 - 风险点评估 3、测试童鞋提的bug单，开发同学需要在 XX 小时内处理完成，否则会被QA催。 4、需要控制bug单数量，否则会被追责复盘。同类问题，建议测试童鞋合并到同一个bug单中。 5、测试管理系统 是所有人处理bug 流程的平台，不是让测试童鞋随便记录个人问题的。所以要提醒测试童鞋，明确该问题是bug，再提单；不是bug，要么不提，要么在沟通后驳回。 ### 发布方案 - 发布顺序：一般是先发后端，再发前端 - 依赖项是否准备就绪：配置的数据、配置项等 - 是否会对线上业务、线上数据造成影响 - 本地环境、dev环境、gamma环境，均要做好验证。 - 回退机制 - 发布 checkList ### 上线确认 - 发布完成后，需要输出上线确认邮件 - 观察页面体验、页面性能表现 - 观察监控数据、业务调用量 - 总结复盘 ## 二、前端工程化 ### Git 版本管理 1、前端代码仓库 git 分支规范： ![](https://img.smyhvae.com/image-20220510164257833.png) ![](https://img.smyhvae.com/image-20220510164323243.png) 2、Commit Message 的格式，只允许使用以下10种标识，最常见的是 feat和 fix ： - **feat:** 新功能 - **fix:** 修补 Bug - **docs:** 文档 - **style:** 格式变更，不影响代码的运行 - **refactor:** 重构（既不是新增功能，也不是修改 bug 的代码变动） - **test:** 增加测试 - **chore:** 构建过程或辅助工具的变动 - **up:** 不属于上述分类时，可使用此类别 - **merge:** 用于 merge branch，需要手写 commit message 的情况 - **revert:** 用于撤销之前的 commit 3、业务分支，命名规范：（建议一定加上日期） - 特性分支：feature_xxx_YYMMDD - 紧急bug修复分支：hotfix_xxx_YYMMDD - 小程序发布分支（自动生成）：release_YYMMDD ### 代码规范 - 代码格式化：Prettier - 代码格式检查：ESLint ### CSS预处理器 - SASS（用得较多） - Less - PostCSS ### 包管理 - 包管理工具：npm（最常见）、yarn - cnpm、nvm、nrm常用命令 ### 编译构建 - webpack（最常见） - Vite - Gulp - Babel：ES6语法转为ES5语法 ### 小程序工程化 ![图片](https://img.smyhvae.com/640.jpeg) - [小程序工程化探索](https://mp.weixin.qq.com/s/_NSJTQ-4-8gTnwTVK-tn0A) - [京喜小程序最佳实践：我是如何写超大型小程序代码的](https://mp.weixin.qq.com/s/tJN3Yz6usSt9LG37_pN7dw) ### 测试相关 - 编写测试用例代码 - 单元测试 - 自动化测试 ## 三、前端核心知识 > 前端入门核心知识点 ### 浏览器 - Web标准：结构标准（HTML）、表现标准（CSS）、行为标准（JS） - 浏览器分为两部分：渲染引擎（即：浏览器内核）、JS 引擎 - 浏览器的工作原理：重绘和重排、V8引擎 - App的WebView容器，相当于浏览器，可以内嵌H5网页 ### HTML5 - 语义化标签：`
`、`
` 、`