前端侧重于人机交互和用户体验，后端侧重于业务逻辑和大规模数据处理。理论上，面向用户的产品里，所有问题（包括产品、设计、后端、甚至看不见的问题）的表现形式，都会暴露在前端，而只有部分问题（数据问题、计算问题、安全问题等）暴露在后端，这就意味着前端起到了至关重要的承载和连接作用。
前端技术的更新日新月异；前端框架的技术选型百家争鸣；视觉审美的潮流不断更替；可视化效果酷炫无比；用户的运营体系逐渐精细化；适老化、无障碍化、青少年人群的诉求浮出水面；智能设备的升级和适配无穷无尽。所有的这一切，对前端领域和前端同学就一个要求：要折腾，爱折腾，反复折腾。
一般在做需求评审时，PRD里只有交互稿，尚未有视觉稿。需要在评审结束并达成一致后，再输出视觉稿。
1、需求分析：需求点逐一讨论、需求合理性、交互评审、逻辑梳理，以及可能遗漏的部分。
2、涉及渠道/环境：
渠道和环境，往往是需求盲点，也是影响技术选型和开发进度的关键因素。
3、可行性分析：是否有技术上的实现难点，是否有其他的依赖条件。
异常流设计：容错、容灾、兜底、降级、回退机制、风险可控。prd一般只写了正常流的逻辑，异常流往往需要研发同学配合做全盘考虑。
1、进度跟进：视觉稿是分批交付，还是一次性给到？这是要首先考虑的。
按照历史经验，前端项目进度的延误，有一半的概率依赖于视觉稿的进度；因为一个新页面的开发，前端有30%~50%的工作在做页面构建。
2、视觉稿的文件格式：
【划重点】交付视觉稿时，需要视觉同学输出“带尺寸标注”的视觉规范文件。
3、检查需求：是否覆盖需求和交互设计中的全部设计点。
4、检查视觉规范：
5、哪些图是前端构建，哪些图是写死图片资源，哪些是可配置；可配置的图中，需要把每个元素做拆解，这个元素是合并到背景图中，还是单独切图，还是读取数据。
6、切图格式：png（透明格式）、jpg
7、复杂图形、动画的实现难度和实现方式，技术评估。详见接下来要讲的「技术选型」。
1、排期一般包含这几个要素：
2、评估排期时，要根据视觉稿排期，不要根据交互稿排期。这是首先要强调的。一个新页面的开发，前端有30%~50%的工作在做页面构建。 只看交互稿的话，无法评估真实的开发工作量。
6、如果自己有在并行开发其他项目，则排期时需要给自己预留 buffer。并行开发两个项目是家常便饭；但，这个项目在测试时，往往很难抽身去做别的项目，因为会一直被测试童鞋牵制。
技术选型千变万化，百家争鸣。这里需要列出你所在部门的常用技术选型，并非市面上的技术栈罗列。
1、页面开发框架：
（1）多端页面：（小程序原生页面、H5）
注2：有些业务，一开始只做H5，后来迭代时，要求做小程序原生页面。这一点也要纳入需求评估。
（3）App端：
（4）B端开发，UI框架：
2、CSS预处理器：SASS
3、复杂图形、动画的实现难度和实现方式，技术评估：
gif 动图：尽量不用。因为文件太大，且效果模糊。
游戏框架：Cocos 引擎
1、代码设计：
（1）目录结构设计、代码风格
（2）公共组件、工具类设计：确保可复用、高内聚低耦合的原则。哪些可以复用京喜平台的公共组件，哪些需要自己单独写 components、utils。
（3）弹窗设计：如果一个页面有多个弹窗，建议先设计一个抽象的弹窗基类。设计弹窗时，需要考虑的是：
2、视觉构建：
（1）后端在开发接口时，前端做视觉构建；视觉构建完成后，前端根据接口文档的定义，通过 mock 数据的方式调接口，写前端逻辑；待接口开发完成后，可进入前后端联调阶段。
（2）建议前端童鞋学会自己切图，可控程度更高，也能减少沟通成本。学会基本的 PS、Sketch操作就行，做一名合格的前端切图仔。
（3）对于规则的样式和动画，建议用代码实现，而不是图片。图片会降低页面的打开性能，且大屏都显示效果比较模糊。
（4）切图的尺寸要求：100%宽度以 750px 为准。
3、业务逻辑实现：
（1）建议先用思维导图，梳理业务逻辑，再着手写代码。思维导图有利于理清逻辑、事后复盘、高效给他人讲解，一目了然。重要的是思想，而不是用哪一款工具更酷。
（2）在调用接口时，要明确前端自己的安全边界：假设接口字段异常时，前端需要有自己的降级措施，不能完全依赖和信任字段，导致让页面直接白屏、交互异常、甚至挂掉。
（3）除了完成产品要求的业务逻辑之外，还要时刻考虑异常流的设计和容灾。
（4）很多前端童鞋在做需求时，有个习惯是不喜欢细看prd，只对着交互稿和视觉稿进行开发。这样做虽然省事，但有三道手续不能少：
4、非功能性需求。业务代码写完后，还有很多细节需要打磨。比如：
5、代码提交：
6、自测：
1、在真机体验，而不是在模拟器上。最好是 iOS和 Android 都要对比体验。
2、体验时，记录整理各种 todolist：
代码 review 可以在测试期间进行。
review顺序：
视觉走查 可以在测试期间进行。
视觉童鞋都有像素眼，即便是一两个像素的区别，他们都能瞧出来。所以，建议前端童鞋加强自测，努力做到像素级还原视觉稿。
1、建议加强自测质量。进入测试阶段后，测试童鞋会进行一轮冒烟测试，如果质量不合格，将会被打回，这就很尴尬了。
2、整理自测、测试、发布时需要的主流程checkList，每次迭代时都能用上。
转测邮件的基本元素，包括但不仅限于：
3、测试童鞋提的bug单，开发同学需要在 XX 小时内处理完成，否则会被QA催。
4、需要控制bug单数量，否则会被追责复盘。同类问题，建议测试童鞋合并到同一个bug单中。
5、测试管理系统 是所有人处理bug 流程的平台，不是让测试童鞋随便记录个人问题的。所以要提醒测试童鞋，明确该问题是bug，再提单；不是bug，要么不提，要么在沟通后驳回。
1、前端代码仓库 git 分支规范：
2、Commit Message 的格式，只允许使用以下10种标识，最常见的是 feat和 fix ：
3、业务分支，命名规范：（建议一定加上日期）
前端入门核心知识点
ES6语法：严格模式、箭头函数、Promise、Symbol数据类型、Set 和Map数据结构
ES6转ES5
JS数据类型转换、隐式类型转换
内置对象及其方法
数组的各种方法：map、filter、every、reduce等
事件机制、原型继承、立即执行函数
DOM操作、虚拟 DOM 的 diff 算法
BOM浏览器操作
事件冒泡机制：捕获阶段、目标阶段、冒泡阶段。
异步编程：Ajax、Promise、async await
SessionStorage和LocalStorage、Cookie
迭代器Iterator和生成器Generator
Web Socket
异步编程
单线程
Canvas图像绘制
svg 动画
多端自适应布局
SPA单页应用
PWA（Progressive Web App）：小程序的鼻祖
每个框架和工具，都有自己的约束、价值和最佳实践。
对比：
在vue 中，几乎给你想要的全部给你了；而react 追求的更多的是自力更生。
补充：知识库框架，首先推荐 Vuepress 和 Docusaurus，功能强大，成熟稳定。
Flutter（最近比较火）：Flutter 的Dart开发语言，可以编译为 ARM 64、x86 和 JavaScript 代码
ReactNative（逐渐没落）：App、Web端
Taro：小程序、H5
Electron 非常流行，也被大量公司使用，也有很多成功软件，比如 VS Code、Facebook Messager、Twitch、Microsoft Teams 等。Electron 虽然上手容易，但问题也很明显，就是慢、吃内存和大，Electron 吃内存是因为打包的 Chromium 吃内存，同时一个 Hello World 编译后就要 120M+ 。
VS Code、chrome、小程序开发者工具，本质上都是运行的 chrome 内核。所以你会发现，这三个软件都很占内存，都很卡。我将其称之为“前端头痛三剑客”。
控制台的瀑布图 Waterfall
控制台的 performance工具：日常开发过程中观察分析运行时的性能表现
控制台的 LightHouse ：跑分、输出性能报告，分析性能
Performance 这个API：实时动态测量性能
1、Airbnb JavaScript Style Guide：
2、clean code JavaScript：
即时设计、稿定、master go
飞书-思维笔记
从上面的流程图中可以看出，产品经理的交付物是什么？是prd吗？显然不是。
产品经理的工作跟设计师、工程师非常不同。人们对工程师的期望是交付有效的代码，对设计师的期望是交付视觉稿。而对于产品经理来说，只交付一份prd是不够的。
产品经理要负责跟进整个产品周期，包括上线后的页面效果和数据表现。编写需求规范是一种沟通和推动项目的手段，但规范本身并没有内在的价值。很多产品经理并不借助prd来交流他们的想法，他们可以用谈话，还可以把想法画在白板上。也有一些产品经理虽然写了规范，但却没有参照执行。
3、全流程跟进，持续交付，创造业务价值。
4、前端的本质是链接商业、设计、计算能力，为用户提供专业的人机交互体验。
5、产品能力和技术能力是：判断信息，抓住要点，整合有限的资源，把自己的价值打包成一个产品进行交付，并获得回报。
6、部门体系的角色有很多：运营、产品、视觉、开发、测试、架构师、leader、行销、数据分析、运维等。有些工作不是“做或者不做”的问题，而是程度的问题。在注意边界的前提下，主动承担、全盘思考、多一份同理心，这是能力和责任逐渐增强的体现。
7、谦逊、尊重和信任，是协同作战和良性合作的基础。
8、组织内，人与人的关系应该是怎样的？有人认为是管理与被管理的关系，有人认为是合作关系。而我认为，组织内的关系是奉献关系。没有奉献作为基础，组织关系是不成立的。组织内的人与人之间是相互付出的关系，部门与部门是相互付出的关系，上级与下级之间是相互付出的关系，在这样的相互奉献关系中，组织才会真正地存在并发挥作用。
奉献关系所产生的基本现象是：每个处于流程上的人更关心他能够为下一个工序做什么样的贡献；每个部门都关心自己如何调整才能够与其他部门有和谐的接口；下级会关注自己怎样配合才能够为上级提供支持，而上级会要求自己为下级解决问题并提供帮助。
能力很重要，而付出更重要。
9、优秀的人有几个特性：敏感、不能忍、有动手优化的能力。
10、前端侧重于人机交互和用户体验，后端侧重于业务逻辑和大规模数据处理。理论上，面向用户的产品里，所有问题（包括产品、设计、后端、甚至看不见的问题）的表现形式，都会暴露在前端，而只有部分问题（数据问题、计算问题、安全问题等）暴露在后端，这就意味着前端起到了至关重要的承载和连接作用。
11、前端技术的更新日新月异；前端框架的技术选型层出不穷；视觉审美的潮流不断更替；可视化效果酷炫无比；用户的运营体系逐渐精细化；适老化、无障碍化、青少年人群的诉求浮出水面；智能设备的升级和适配无穷无尽。所有的这一切，对前端领域和前端同学就一个要求：要折腾，爱折腾，反复折腾。