需求文档
目的：
- 思考这个需求到底有哪些功能？用来满足用户什么需求？
- 保证研发出来的功能是和需求文档相匹配的，防止互相甩锅
作用：
- 项目的迭代过程可以准确记录，可以理解整个项目的演进过程
- 需求产生的价值，成功的经验，后续可以被复用
功能
- 换位思考，用产品视角去考虑问题，尽可能的去拆解需求
- 以点看，尽可能的需求原子化，保证不会影响其它
- 以全局看，尽可能形成联动和复用
难点
- 尽可能的深刻理解业务需求，拆分的越详细越好（拆分的越细评估越准确）
- 领导在意的是成果，所以尽可能给给领导展现你的工作是有挑战和难度的
- 记录难点，去寻找最优解(可以写思考演进过程)，形成文档
- 有风险点，不可把控点一定在此刻抛出来，切勿做到中途提出
技术文档
画图
- 任何一个需求，要对自己高标准，必须写架构图，时序图等
- 画图可以增加自己对系统架构的理解程度，也可以明白需求在项目中的角色
定协议字段
- 如果涉及到和服务端交互，需要确定好交互协议，并明确好每一个字段的含义并形成文档
设计算法
- 代码用到需要算法，操作数据集合等，一定要考虑并发安全
- 极端情况下，直接复用已有代码，时间充足，建议去寻求最优解
技术评审
- 完成需求理解，拆解，画架构图，定协议，算法设计等，就可以先进行技术评审了
- 技术评审可以在群力的协助下，补上我们没有考虑的地方和提出更佳的技术方案
- 如果没有做这个，很可能被代码review者提出更佳方案导致返工
编码测试
开发
- 因为事先已经进行过调研和技术评审，此时只需要按照既有方案编码就行
联调
- 此时字段，协议不合理，要及时更正
- 其实在开发阶段，就可以Mock数据验证了，切勿等数据等出来了在开发
自测
- 开发完成，必须进行测试，以保证高质量交互
- 首先基础功能必须正确，不能产生导致测试阻塞的问题
| 代码规范 | 阿里代码规范 |
|---|---|
| UI还原 | UI，深色模式，多语言 |
| 稳定性 | FC，NPE，内存，主线程耗时 |
| 安全隐私 | 隐私，安全相关 |
| 数据打点 |
提测
- 提测时，带上需求链接，评审文档，代码链接，描述影响范围，apk链接
- 测试反馈问题，立即跟进解决
Review+合入
- 切记，review后，自己自测后，一定要同步给测试在复测一次
上线发布
-
版本上线后，既在刚开始灰度的时候，去查看大盘数据(特别是性能问题)
-
数据回收验证，xx提升了多少，xx降低了多少(又一条okr到手)
-
整体复盘，多问自己几个为什么
1、整个排期过程中，哪里做的不好，需要改正？哪里做的好，可以复用？
2、编码过程中，哪里形成了自己的经验，方法论，下次是否可以迁移复用？
3、编码过程中，可能着眼于局部解决问题，这个时候再次用全局视角去回溯
4、对于需求产生的业务价值，自己可否从产品的角度去思考项目中哪里有价值的方案，而不仅仅是一个开发工具？
