项目流程

完成流程参考 参考 https://www.imooc.com/article/289377

会遇到的各个项目角色

• PM 产品经理 - 提需求，一般也是项目的推动者
• FE 前端开发
• RD 后端开发
• CRD 客户端开发
• UE 视觉设计师 - 切图仔
• QA 测试
• OP 运维人员 - 管理服务器的

需求分析

• 了解项目背景，即为啥要做这件事儿，解决的问题是什么。别一上来就说功能
• 需求是否合理？从用户角度来考虑
• 需求是否闭环（如缺少统计）
• 是否可实现？（如在 h5 中做点赞的动画）—— 此时应该建议修改续期，而不是硬撑着做
• 是否需要其他支持？如图片放大需要客户端支持，用户信息可能需要服务端支持。
• 不要着急给出排期，一般话术是：“今天下班之前给排期”

技术方案设计

在此回顾一下之前讲的“组件设计”

• 尽量以最简单的设计来解决问题，不要为了设计而设计
• 要写出设计文档，画图、写伪代码。—— 不要觉得写文档很麻烦，它是检验你是否真正理解的一个过程
  • 如果你真理解了，写文档画图不会花费你过多时间；
  • 如果你不理解，那你写不出文档，到时候你也一定写不出代码。
• 前端设计的重点：组件设计、数据结构设计、接口设计
• 要通过全组评审，或者你的导师、组内高工评审。
  • 第一，他们技术好、工作经验丰富能看出你设计的是否合理，是否有破坏性，是否可扩展，是否有性能问题、安全问题、或者其他坑；
  • 第二，他们对公司环境熟悉，知道公司中很多线程的工具，有些你可以直接用。
• 要和服务端、客户端对好接口和调用协议，确定好联调时间，以邮件的形式发出来，抄送他们的领导。

开发

反馈排期

• 预留 buffer ，应对风险
• 考虑自己是否有并行的其他工作
• 关注 UE RD CRD 的排期 —— 大家协作，可能会因为上游、或协同人员的延期，而导致你延期

开发规范

• git 规范：分支规范、commit 规范
• 注释规范 jsdoc ，注释是代码的一部分
• 及时写开发文档 README.md ，文档是代码的一部分 —— 例如你做了一个公共的 API 或者 UI 模块，写清楚如何调用、注意事项等。

单元测试

• 代码和单测并行，单测是代码的一部分 —— 前端开发，不用要求对所有部分写单测（例如 UI 写单测挺麻烦的），但是一些公用的方法和函数，还是要有的
• 及时开发，及时单测
• 常用工具 jest ，以及 React vue 的单测

mock API

• 此时，服务端在还开发中，没有后端接口
• 需要自己构建假数据，模拟后端接口
• webpack proxy 或 mockjs

及时 cr code review

• 将 cr 归入研发流程
• cr 的内容 merge request
• cr 必须留有记录

联调

• 后端、客户端联调
• 视觉联调 —— 这一步很麻烦，UE 的像素眼可能会给你调出很多问题，特别是不同尺寸的手机上
• 产品确认 —— 这一步特别重要！！！确定最后做出来的产品，一定是 PM 需要的，否则就不能提测。

此时 PM 可能还会让你加需求，怎么办？？？

• 不能拒绝（你也无权拒绝），走需求变更流程
• 如果公司有现成的流程，则按照这个来
• 如果没有，可以发邮件或开发周知项目组和 leader （重要！！！），重新评估技术方案和排期

测试

“我这里没问题呀！” —— 自己复现不了，怎么办？

• 不要说这句话！！！—— 显得自己很不会沟通
• 当面讨论，让 QA 帮你复现问题 —— 如果是偶尔复现的，就尝试找一找必然复现的路径
• 如果需要特定设备才能复现，则让 QA 提供设备 —— 总之，要抱着一起解决问题的心态，而不是推卸

上线

暂无问题，每个公司的上线流程都不一样

回滚（如果需要）

• 遇到问题先回滚，止损，再排查
• 回滚之后，要立刻周知 PM 和项目组
• 解决之后，记得写复盘报告 —— 无论公司有没有规定，对自己的总结和反省，是进步的最好方式

沟通和变更

• 每日站会，周会 —— PM 或者项目经理组织
• 有问题（如要延期）及时汇报
• 如上游或写同人导致的延期，也要及时汇报 —— 但说话不要用甩锅的语气，就事论事即可

项目总结

• 项目结束之后，要记得写个总结
• 总结项目遇到的各种问题和风险，以及解决方案
• 总结自己做下来的感想