前端开发流程

通用产品开发流程

字体

间距

按钮

调研分析

低保真原型设计

高保真原型设计

前端开发流程

最完善的前端开发流程（详解）

需求评审

一般在做需求评审时，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 是最近比较火的全平台原型设计软件，有取代 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 框架（基于 React技术栈）

注2：有些业务，一开始只做H5，后来迭代时，要求做小程序原生页面。这一点也要纳入需求评估。

（2）H5页面：Vue.js 框架、React 框架

（3）App端：

• Android端开发语言：Kotlin（新）、Java（老）
• iOS端开发语言：Swift（新）、Objective-C（老）

（4）B端开发，UI框架：

• React 技术栈：Ant Design（简称Antd）
• Vue 技术栈：Element、Ant Design Vue
• 较简单的CSS响应式框架：Bootstrap

（5）Node.js后端开发框架：

• Koa：新一代 Node.js 框架。
• Egg.js：Egg 是在Koa基础上进一步封装的企业级Web开发框架。
• Express：比较老的Node.js 框架。

2、CSS预处理器：SASS

3、复杂图形、动画的实现难度和实现方式，技术评估：

• gif 动图：尽量不用。因为文件太大，且效果模糊。
• CSS3 动画：适合简单的、有规律的动画。举例：摆动的鱼、京喜工厂
• Canvas：Canvas 动画、小程序分享图采用 Canvas 绘制
• 3D动画：WebGL（Three.js 是 WebGL 的综合库）常见案例：太阳系
• 游戏框架：Cocos 引擎

概要设计

• 需求背景及资源
• 风险评估
• 技术选型
• 项目结构设计
• 主要功能点逻辑设计
• 可扩展可复用设计
• 依赖接口
• 工作量拆解和排期

开发环节

1、代码设计：

（1）目录结构设计、代码风格

（2）公共组件、工具类设计：确保可复用、高内聚低耦合的原则。哪些可以复用京喜平台的公共组件，哪些需要自己单独写 components、utils。

（3）弹窗设计：如果一个页面有多个弹窗，建议先设计一个抽象的弹窗基类。设计弹窗时，需要考虑的是：

• 设计原则：易扩展、复用性强
• 避免重复代码
• 避免同一时间出现多个弹窗
• 弹窗的位置要严格居中（不能因为屏幕尺寸的大小变了，导致弹窗位置不居中）
• 处理滚动穿透这个顽疾。

2、视觉构建：

（1）后端在开发接口时，前端做视觉构建；视觉构建完成后，前端根据接口文档的定义，通过 mock 数据的方式调接口，写前端逻辑；待接口开发完成后，可进入前后端联调阶段。

（2）建议前端童鞋学会自己切图，可控程度更高，也能减少沟通成本。学会基本的 PS、Sketch操作就行，做一名合格的前端切图仔。

（3）对于规则的样式和动画，建议用代码实现，而不是图片。图片会降低页面的打开性能，且大屏都显示效果比较模糊。

（4）切图的尺寸要求：100%宽度以 750px 为准。

（5）像素级还原视觉稿：推荐使用 Snipaste 截图软件，按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 截图软件，按F1截图，F2贴图，然后调整贴图的透明度为50%，将贴图与前端页面进行像素级比对。

测试环节

1、建议加强自测质量。进入测试阶段后，测试童鞋会进行一轮冒烟测试，如果质量不合格，将会被打回，这就很尴尬了。

2、整理自测、测试、发布时需要的主流程checkList，每次迭代时都能用上。

转测邮件的基本元素，包括但不仅限于：

• prd链接、视觉稿链接
• 页面链接
• 项目相关人员
• 数据配置系统
• host 代理
• 接口文档
• 概要设计、前端开发整理（如果有的话）
• 测试用例（如果有的话）
• 核心业务逻辑梳理（如果有的话）
• 体验问题列举
• 测试重点建议
• 风险点评估

3、测试童鞋提的bug单，开发同学需要在 XX 小时内处理完成，否则会被QA催。

4、需要控制bug单数量，否则会被追责复盘。同类问题，建议测试童鞋合并到同一个bug单中。

5、测试管理系统 是所有人处理bug 流程的平台，不是让测试童鞋随便记录个人问题的。所以要提醒测试童鞋，明确该问题是bug，再提单；不是bug，要么不提，要么在沟通后驳回。

发布方案

• 发布顺序：一般是先发后端，再发前端
• 依赖项是否准备就绪：配置的数据、配置项等
• 是否会对线上业务、线上数据造成影响
• 本地环境、dev环境、gamma环境，均要做好验证。
• 回退机制
• 发布 checkList

上线确认

• 发布完成后，需要输出上线确认邮件
• 观察页面体验、页面性能表现
• 观察监控数据、业务调用量
• 总结复盘