update: 前端开发流程（详尽版）

17-前端综合/01-2022年Web前端开发流程和学习路线（详尽版）.md

@@ -27,9 +27,9 @@
 
 数据来源：哪些是调接口，哪些是做成**可配置**，哪些是前端写死；可配置的部分，是前端读取，还是接口读取然后返给前端。提示：可配置的灵活性与风险正相关。
 
-异常流设计：容错、容灾、兜底、降级、回退机制、风险可控。prd一般只写了正常流的逻辑，异常流往往需要研发同学配合做全盘考虑。
+异常流设计：容错、容灾、兜底、降级、回退机制、风险可控、边缘场景。PRD一般只写了正常流的逻辑，异常流往往需要研发同学配合做全盘考虑。
 
-6、需求变更：如有需求不明确、改需求、加需求、砍需求、加时间、改时间、加人力等等，需要提前预判风险。
+4、需求变更：如有需求不明确、改需求、加需求、砍需求、加时间、改时间、加人力等等，需要提前预判风险。
 
 ### 视觉评审
 
@@ -56,14 +56,14 @@
 
 - 样式和配色，是否符合页面和产品的整体风格。
 - 尺寸规范：移动端的视觉稿宽度是750px。
-- 排版、对齐、一致性。推荐阅读书籍《写个大家看的设计书》，了解基本的设计原则。
+- 排版、对齐、一致性。推荐阅读书籍[《写给大家看的设计书》](https://m.douban.com/book/subject/3323633/)，了解基本的设计原则。
 - 字体：字号大小（一般是12px以上，特别小的是10px以上）、字重（注意bold属性值为700），以及有哪些**特殊字体**。尤其要注意字体的版权问题。
 
 5、哪些图是前端构建，哪些图是写死图片资源，哪些是可配置；可配置的图中，需要把每个元素做拆解，这个元素是合并到背景图中，还是单独切图，还是读取数据。
 
 6、切图格式：png（透明格式）、jpg
 
-切图的图片大小，不要太大。移动端的大图（比如幕帘弹窗的背景图）建议不超过50kb，小图建议不超过20kb。图片在上传之前，可以先在 https://tinypng.com/  上进行压缩。
+切图的图片大小，不要太大。移动端的大图（比如幕帘弹窗的背景图）建议不超过50kb，小图建议不超过20kb。图片在上传之前，可以先在 https://tinypng.com/ 上进行压缩。
 
 7、复杂图形、动画的实现难度和实现方式，技术评估。详见接下来要讲的「技术选型」。
 
@@ -84,9 +84,9 @@
 
 5、即将进入开发阶段后，与测试部门协调测试资源，确认转测时间；大型项目&重点项目，需要在需求评审阶段，提前知会测试部门，让其预留时间。
 
-6、如果自己有在并行开发其他项目，则排期时需要给自己预留 buffer。并行开发两个项目是家常便饭；但，这个项目在测试时，往往很难抽身去做别的项目，因为会一直被测试童鞋牵制。
+6、如果有其他并行开发的项目，需要在排期时给自己预留 buffer。并行开发两个项目是家常便饭；但，这个项目在测试时，往往很难抽身去做别的项目，因为会一直被测试童鞋牵制。
 
-7、开发排期：如果开发排期有变更，需要立即周知其他相关人员，尤其是要评估测试排期的风险。测试排期比开发排期 更难变更。
+7、开发排期：如果开发排期有变更，需要立即周知其他相关人员，尤其是要评估测试排期的风险。测试排期比开发排期更难变更。
 
 ### 技术选型
 
@@ -136,7 +136,7 @@
 - 风险评估
 - 技术选型
 - 项目结构设计
--  主要功能点逻辑设计
+- 主要功能点逻辑设计
 - 可扩展可复用设计
 - 依赖接口
 - 工作量拆解和排期
@@ -155,7 +155,8 @@
 - 避免重复代码
 - 避免同一时间出现多个弹窗
 - 弹窗的位置要严格居中（不能因为屏幕尺寸的大小变了，导致弹窗位置不居中）
-- 处理滚动穿透这个顽疾。
+- 处理滚动穿透这个顽疾
+- 维护好z-index，不要滥用
 
 2、视觉构建：
 
@@ -169,6 +170,8 @@
 
 （5）**像素级还原视觉稿**：推荐使用 [Snipaste](https://zh.snipaste.com/) 截图软件，按F1截图，F2贴图，然后调整贴图的透明度为50%，将贴图与前端页面进行像素级比对。
 
+（6）如果项目维护了一套全局的css样式文件，建议熟记几个常用的class类名，提高效率同时减少编写重复的样式代码。
+
 3、业务逻辑实现：
 
 （1）建议先用**思维导图**，梳理业务逻辑，再着手写代码。思维导图有利于理清逻辑、事后复盘、高效给他人讲解，一目了然。重要的是思想，而不是用哪一款工具更酷。
@@ -177,11 +180,11 @@
 
 （3）除了完成产品要求的业务逻辑之外，还要时刻考虑异常流的设计和容灾。
 
-（4）很多前端童鞋在做需求时，有个习惯是不喜欢细看prd，只对着交互稿和视觉稿进行开发。这样做虽然省事，但有三道手续不能少：
+（4）很多前端童鞋在做需求时，不习惯细看PRD，只对着交互稿和视觉稿进行开发。这样做虽然省事，但有三道手续不能少：
 
-- 开发前，一定要再和产品童鞋过一遍prd细节；
+- 开发前，一定要再和产品童鞋过一遍PRD细节；
 - 开发过程中，随时和产品童鞋反复沟通确认；
-- 开发到80%时，自己对照prd，只字不差地阅读，看看是否有遗漏的地方。
+- 开发到80%时，自己对照PRD，只字不差地阅读，看看是否有遗漏的地方。
 
 4、非功能性需求。业务代码写完后，还有很多细节需要打磨。比如：
 
@@ -190,12 +193,12 @@
 - 添加埋点：曝光上报、点击上报、呼吸上报
 - 监控上报、测试上报、badjs上报
 - 重复代码精简
-- 去掉 console.log、debugger 等多余的代码
+- 利用打包插件去掉 console.log、debugger 等多余的代码，
 - 图片、字体等静态资源压缩
 - 常见的性能优化：骨架屏（按需）、图片懒加载、图片预加载、防抖节流、长列表*滚动*到可视区域动态加载
 - 用户体验完善：返回定位、滚动穿透
 - 屏幕适配
-- 小程序代码瘦身
+- 小程序代码瘦身，分包加载
 - 容灾演习
 
 5、代码提交：
@@ -208,13 +211,13 @@
 
 6、自测：
 
-- 对照prd，查漏补缺。
+- 对照PRD，查漏补缺。
 - 在真机上体验页面，而不是在模拟器上。
 - 写一部分测试用例，加快后续的测试进度。前面梳理的思维导图，其实就是测试的最佳素材。
 
 ### 产品体验
 
-1、在真机体验，而不是在模拟器上。最好是 iOS和 Android 都要对比体验。
+1、在真机体验，而不是在模拟器上。最好是 iOS 和 Android 都要对比体验。
 
 2、体验时，记录整理各种 todolist：
 
@@ -253,7 +256,7 @@ review顺序：
 
 转测邮件的基本元素，包括但不仅限于：
 
-- prd链接、视觉稿链接
+- PRD链接、视觉稿链接
 - 页面链接
 - 项目相关人员
 - 数据配置系统
@@ -369,6 +372,7 @@ review顺序：
 
 - 语义化标签：`<header>`、`<article>` 、`<footer>`等。
 - 多媒体标签：`<audio>`、`<video>`
+- HTML5新增API：window.history、localStorage等
 - 更强的本地存储能力和设备兼容性：indexDB、HTML5 APP cookie
 - 三维、图形及特效：SVG、Canvas、WebGL
 - 更有效的实时连接：WebSocket、Server-Sent Events
@@ -378,8 +382,8 @@ review顺序：
 
 - CSS盒模型、BFC
 - 浮动、定位（绝对定位和相对定位）
-- flex 布局
 - 圣杯布局、双飞翼布局
+- flex 布局、grid 布局、响应式布局（媒体查询）
 - 选择器：后代选择器、交集选择器、并集选择器、伪类选择器
 - 2D转换：移动translation、旋转rotate、缩放scale
 - 3D转换：透视 perspective、3D移动 translate3d、3D旋转 rotate3d、3D呈现 transform-style
@@ -407,16 +411,14 @@ review顺序：
 
 - 事件冒泡机制：捕获阶段、目标阶段、冒泡阶段。
 
-- 异步编程：Ajax、Promise、async await
+- 异步编程：Ajax、Promise、async await、微任务/宏任务、事件循环
 
 - SessionStorage和LocalStorage、Cookie
 
 - 迭代器Iterator和生成器Generator
 
 - Web Socket
 
-- 异步编程
-
 - 单线程
 
 - Canvas图像绘制
@@ -434,7 +436,7 @@ review顺序：
 - 防抖和节流
 - Promise的宏任务和微任务
 - 浏览器的重排和重绘
-- 手写 Promise的整个逻辑和API：resolve、reject、then、catch、finally、allSettled、race any
+- 手写 Promise的整个逻辑和API：resolve、reject、then、catch、finally、allSettled、race、any、all
 - 高阶函数
 - 事件委托
 - call、apply、bind
@@ -491,10 +493,10 @@ review顺序：
 
 对比：
 
-- vue ：声明式编程，数据驱动的思想
+- Vue ：声明式编程，数据驱动的思想
 - React：函数式编程。如果你要改变数据，那么必须调用api去改。
 
-在vue 中，几乎给你想要的全部给你了；而react 追求的更多的是自力更生。
+在Vue中，几乎给你想要的全部给你了；而React追求的更多的是自力更生。
 
 
 ### CSS框架、组件库（B端常用）
@@ -646,7 +648,7 @@ Electron 非常流行，也被大量公司使用，也有很多成功软件，
 ### 前端社区
 
 - GitHub
-- stackoverflow
+- Stack Overflow
 - 掘金
 
 
@@ -730,7 +732,7 @@ Electron 非常流行，也被大量公司使用，也有很多成功软件，
 
 - **幕布**：<https://mubu.com>
 
--  飞书-思维笔记
+- 飞书-思维笔记
 
 
 
@@ -882,6 +884,7 @@ Electron 非常流行，也被大量公司使用，也有很多成功软件，
 - 《少有人走的路》
 - 《沟通的方法》
 - 《我们为什么要睡觉》
+- 《金字塔原理》 
 
 
 
@@ -893,11 +896,11 @@ Electron 非常流行，也被大量公司使用，也有很多成功软件，
 
 ![](https://img.smyhvae.com/20220613_1330-2.jpg)
 
-从上面的流程图中可以看出，产品经理的交付物是什么？是prd吗？显然不是。
+从上面的流程图中可以看出，产品经理的交付物是什么？是PRD吗？显然不是。
 
-产品经理的工作跟设计师、工程师非常不同。人们对工程师的期望是交付有效的代码，对设计师的期望是交付视觉稿。而对于产品经理来说，只交付一份prd是不够的。
+产品经理的工作跟设计师、工程师非常不同。人们对工程师的期望是交付有效的代码，对设计师的期望是交付视觉稿。而对于产品经理来说，只交付一份PRD是不够的。
 
-产品经理要负责跟进整个产品周期，包括上线后的页面效果和数据表现。编写需求规范是一种**沟通和推动项目**的手段，但**规范本身并没有内在的价值**。很多产品经理并不借助prd来交流他们的想法，他们可以用谈话，还可以把想法画在白板上。也有一些产品经理虽然写了规范，但却没有参照执行。
+产品经理要负责跟进整个产品周期，包括上线后的页面效果和数据表现。编写需求规范是一种**沟通和推动项目**的手段，但**规范本身并没有内在的价值**。很多产品经理并不借助PRD来交流他们的想法，他们可以用谈话，还可以把想法画在白板上。也有一些产品经理虽然写了规范，但却没有参照执行。
 
 ### 前端工程师应该具备怎样的能力和素质
 
@@ -911,7 +914,7 @@ Electron 非常流行，也被大量公司使用，也有很多成功软件，
 
 ### 前端认知
 
-1、虽然我们绝大多数时间耗在业务开发上，但仍需要积累其他方面的沉淀，做多一些有趣的、可持续的事情，比如分享总结、基础能力建设、研发效能提升、技术运营建设、技术沉淀等。
+1、虽然我们绝大多数时间耗在业务开发上，但仍需要积累其他方面的沉淀，多做一些有趣的、可持续的事情，比如分享总结、基础能力建设、研发效能提升、技术运营建设、技术沉淀等。
 
 2、学会提问。我们日常在提出问题和解决问题时，经常容易陷入[X-Y问题](https://coolshell.cn/articles/10804.html)，导致目标不明确、思路不清晰、沟通效率低下，甚至在一个完全错误的方向上浪费大量的资源、时间和精力。无论是在寻求帮助的人身上，还是在提供帮助的人身上，都有所体现。