关于前端:前端项目开发流程

我的项目残缺流程

需要剖析

• 理解背景

  为什么做这个事件

• 质疑需要是否正当

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

• 需要是否闭环

  需要是否思考全面，剖析性能操作前，操作时和操作后所带来的数据变动，以及引起的对其余性能的影响

• 开发难度如何

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

• 是否须要其余反对

  思考某个需要是否须要其余端人员的反对，并提出

• 不要急于给排期

  不要急于需要剖析现场给排期，依据本人理论状况做好统筹兼顾

技术方案设计

• 求简，不适度设计

  做出满足需要的根底设计即可

• 产出文档

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

• 找准设计重点
• 组内评审
• 和 RD CRD 沟通
• 收回会议论断

开发

• 如何反馈排期

  预留危险工夫，最好多出 1/4 工夫；
  思考其余插入工作
  思考其余依赖人员的排期

• 合乎开发标准

  git 标准
  正文标准
  模块组件标准

• 写出开发文档

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

• 及时单元测试

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

• Code Review

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

  1. 临时遗记对方的代码，如果让你来实现这个需要，你会如何设计，跟对方的设计思路统一么？差别在哪里？谁的更优？
  2. 临时遗记具体的需要（或者你本来就不晓得需要），看着对方的代码，是否可能了解他想实现一件什么事件么？他了解需要了么？他实现的好么？

其实 CR 就是对设计和实现的再次确认，在重复较量的过程中，互相学习和成长。如果以上两个问题存在否定的答案，那就有必要好好写写 CR 评语了。

• Mock API | 模仿数据

联调

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

PM 加需要怎么办？

• 不能回绝
• 依照公司规定，走流程变更流程
• 否则，项目组和 leader 从新评审，从新评估排期

测试

• 提测发邮件，抄送项目组
• 测试问题要具体记录
• 防止 QA 和 FE 信息不对称，有问题要及时沟通

上线

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