这篇文章上次修改于 902 天前，可能其部分内容已经发生变化，如有疑问可询问作者。
1. 主体流程
1.1. 前期调研
这个时期中，调研的粒度都比较粗，主要以体验功能为主。在体验竞品的过程中，会对竞品有一个大概的认知，然后结合可以利用的资源（已有的 API 等）考虑并罗列出自己的产品中要实现哪些功能，并列出利弊，形成功能调研文档。
1.2. 概要设计
列出功能点，并描述总体流程，结合流程图、时序图、架构图、交互图辅以说明。
最好能实现基础框架、各模块之间的交互接口。
1.3. 详细设计
将各模块功能落实到各负责人。各负责人可能需要根据自己负责的模块进行进一步的调研，给出详细设计。
详细设计中需要细化各功能点，如果有多种实现方案，需列出各种方案的利弊，如果涉及产品决策，需及时与产品沟通。
如果需要调用第三方的接口，需要充分调研第三方接口的行为。
设计数据库表的时候，需要根据 sql 语句设计索引，可以通过 explain、show profiles 等进行检验。
如果涉及状态的转换，需要绘图说明，并考虑各种状态是否存在冲突的情况。
同时需要考虑各种异常情况，如：
- 并发，对资源争用需要仔细考虑。
- 程序在运行的过程中可能会 down 掉，虽然概率较低，但应尽量避免 down 掉造成的错误，必要时需要考虑清理脏数据或重试。
- 数据库会有出错的可能，虽然概率极低，必要时需要考虑清理脏数据或重试。
- 如果采用了消息队列，需要考虑消息丢失的情况，实现重试机制。
- 在重试时，要考虑幂等。还需要考虑重试次数，重试间隔，重试次数后的处理行为以及处理行为对正常流程的影响。
- 在对资源进行操作前，需要判断资源是否存在、状态是否正常等。
1.4. 技术评审
各模块负责人实现了详细设计后，进行技术评审，对实现方案进行讨论，及时暴露方案的不足。模块负责人需要提前想清楚方案的利弊，并给出决策，然后参考评审参与者的意见，形成最终决策。
交流的时候需要注意，不要默认参与者知道自己所知道的东西，需要从最基本的信息开始讲述。
1.5. 开发
开发的过程中需注意：
- 如果多个函数或模块行为相似，进行抽象，避免如果要改动的话一下子改动多个地方，也为后续的开发带来方便。
- 遵循约定的编程规范。
- 如果开发的过程中在设计上有变动的话，需要及时同时同步文档，方便合作的人了解变动。
1.7. 代码 review
代码 review 是一件比较辛苦的事情，感激那些 review 自己代码并提出意见的人。
1.8. 测试
- 单元测试。可借助 python 中的 unittest.TestCase 对各个单元进行测试，这种测试通常代码行数较短，且随生产代码一起编写。需要保持测试的整洁，即测试代码也需要遵循生产代码的质量标准。
- 模块自测，包括接口参数、功能、内部逻辑测试。可借助 postman 对各个 API 进行测试，同样需要保持测试代码的整洁。
交叉测试。
（1）先了解对方模块的功能，可以通过查看对方的文档或直接面谈去了解。
（2）然后尝试自己进行设计，比较自己的设计和模块负责人之间的区别，查看自己想到的缺陷模块负责人是否想到，同时可以审视模块负责人想到的缺陷自己是否想到了，有助于自己的提高。
模块负责人在修复了交叉测试的 bug 后，需要对模块中涉及的接口全部回归测试一遍，防止引入新的 bug。
- 集成测试。
1.9. 上线
项目打包、部署、灰度上线。
1.10. 内测
专门的测试人员对上线项目进行测试，及时发现问题。
1.11. 公测&运营
向用户提供优惠活动，吸引用户体验并反馈问题。
产品经理撰写文案，介绍产品特点、优势，为产品造势。
1.12. 项目回顾
总结在项目中有哪些好的做法，形成经验积淀，在以后的项目中推广。
2. 并行流程
2.1. 人力预估
对投入的人力进行大概估计，最开始或许无法准确估计，随着项目的进行可能需要继续投入人力。
2.2. 行为规范
提前告知开发人员需要遵循一些规范。
- 编程规范。包括编码风格约定等。
- 各类文档撰写规范，包括需求文档，实现文档，接口文档，测试文档等。
2.3. 进度预估
包括总体项目完成时间、主体流程中各阶段完成时间、各模块负责人对各自模块完成时间的预估，及时发现风险点。
2.4. 资源申请
对域名，运维机器，配额等进行申请。
2.5. 进度对齐
在约定的时间点进行进度对齐，及时发现风险点。
没有评论