前端项目开发流程

项目完整流程

需求分析

1、了解背景

为什么做这个事情

2、质疑需求是否合理

这个需求为什么要做，是否符合我们的产品，开发也是用户

3、需求是否闭环

需求是否考虑全面，分析功能操作前，操作时和操作后所带来的数据变化，以及引起的对其他功能的影响

4、开发难度如何

最好现场评估开发中的难点之处，集思广益

5、是否需要其他支持

考虑某个需求是否需要其他端人员的支持，并提出

6、不要急于给排期

不要急于需求分析现场给排期，根据自己实际情况做好统筹兼顾

技术方案设计

1、求简，不过度设计

做出满足需求的基础设计即可

2、产出文档

更清晰设计方案中的细节，也便于之后复盘

3、找准设计重点

4、组内评审

5、和 RD CRD 沟通

6、发出会议结论

开发

1、如何反馈排期

预留风险时间，最好多出 1/4 时间；
考虑其他插入工作
考虑其他依赖人员的排期

2、符合开发规范

git 规范
注释规范
模块组件规范

3、写出开发文档

公共 API
公共 UI 组件
公共函数方法

4、及时单元测试

单元测试是检验代码质量的重要工具

5、Code Review

Code Review 不仅仅是去看对方的代码写得规不规范、细节上有没有小问题，更多的是：

暂时忘记对方的代码，如果让你来实现这个需求，你会如何设计，跟对方的设计思路一致么？差异在哪里？谁的更优？
暂时忘记具体的需求（或者你原本就不知道需求），看着对方的代码，是否能够理解他想完成一件什么事情么？他理解需求了么？他完成的好么？
其实 CR 就是对设计和实现的再次确认，在反复较量的过程中，相互学习和成长。如果以上两个问题存在否定的答案，那就有必要好好写写 CR 评语了。

Mock API | 模拟数据

联调

和 RD CRD 技术联调
让 UE 确定视觉效果
让 PM 确定产品功能

1、PM 加需求怎么办？

不能拒绝
按照公司规定，走流程变更流程
否则，项目组和 leader 重新评审，重新评估排期

2、测试
提测发邮件，抄送项目组
测试问题要详细记录
避免 QA 和 FE 信息不对称，有问题要及时沟通

3、上线
上线之后及时通知 QA 回归测试
上线之后及时同步给 PM 和项目组
如有问题，及时回滚。先止损，再排查问题