0.摘要
此文主要介绍了业务开发的整体流程、关键节点和需要注意的事项，适用于刚入行的小白，以及对自己过往经验的一个总结整理。持续更新中~~
1.开发的主要流程&名词释义
大概给大家梳理下一个项目从发起到上线的流程。
○ 参与人员：业务（使用我们系统的用户方）、产品经理（PM product manger）、后端开发 (RD research and development engineer) 、测试 (QA quality assurance） 、前端开发（FE front-end engineer）
○ 整体流程是，会从业务方发起，pm通过和业务方沟通、调研、整理后，输出产品需求文档（PRD product requirements documents），输出prd后会经过产品内部评审，再到每周的需求预评审环节；通过后到【需求详细评审】，该节点会需要pm、fe、rd、qa、可能还会需要数据开发、业务方等的参与；需求详细评审通过后，开发人员会需要经过 设计、技术评审、评估排期、开发、自测、联调、提测。提测后，任务会流转到测试同学，开发这个节点需要做的就是配合测试，解bug。最后等到测试环境、灰度环境验证通过后，需要部署上线
2.重要节点注意事项
● 需求详细评审
非常重要！！！
需求详评的发起者是pm，主要目的是，pm将本次需求背景、重点、细节，准确清晰地传达给参会人，参会人需要站在各自的角度对prd中不明确或有歧义的地方进行讨论，最终达到参会人对本次需求的整体、细节的理解都达成一致，可以进行下一步的工作。
作为RD需要做到的是
参会前：
- 根据需求的大小，花10-30min去详细阅读prd，了解本次需求所属的系统，背景&价值，具体的变更点
- 如果对需求所属的系统不了解，可以找pm、组内熟悉的同事、mentor去使用、了解这个系统
- 对于自己有疑问的点，可以自己记录下来，或者在prd里直接评论
参会时：
- 尽可能的做到专注，跟上pm的讲解节奏
- 在听的时候需要多思考，这个变更是合理的么，有没有其他方式？pm想达到什么效果，当前这个方式可以达到么？
- 需要站在技术的角度去思考，每一个变更涉及的数据，来源是什么？db/es/接口？需要怎么存储？数据是怎么流转的？如果依赖其他方，接口是否是现成的，如果不是，什么时候能给到。
- 对于会前记录的有疑问的地方，或者在听的过程中有疑问时，一定要表达出来，需要和pm确认清楚
- 迭代/改版的需求，pm可能会写上一句，“和旧系统逻辑保持一致”，这种时候一定要指出来，让pm在prd里详细表述出来，具体是哪些逻辑需要和旧系统保持一致。
会后： - 需要把会议上有疑问的点/PM的todo项和PM确定好落实时间，尽可能让PM在群里发出todo&ddl
● 设计
最开始的小白阶段，可能拿到需求就开始会着手想怎么去写。但是好的做法是，在前期设计阶段花上足够的时间，可以避免后期出现设计遗漏等问题。先谋而后定～
设计阶段需要注意的点 - 梳理清楚数据的整体流转，数据从哪里来，到哪里去，涉及到哪几方，推荐使用时序图来实现（https://plantuml.com/zh/sequence-diagram）
- 根据需求设计model，考虑是需要创建新的model，还是在原有的model里进行修改，修改需要考虑到兼容性
- 是否设计到db/es变更，如果有，画出e-r图，给出表的设计
- 重要/复杂的逻辑，可以画出流程图
- 缓存的设计
- 接口的设计（http、rpc）原有接口上修改，需要考虑兼容性
● 技术评审
原则上开发周期大于5pd的都需要有技术评审环节，我们rd是做为主r，发起方，主要是给pm、fe、qa同步我们针对需求的整体设计&细节的设计，参与方可以评估我们的设计是不是都覆盖到了本次的需求。组内的前辈（mentor/leader）也会参与，可能会在评审时提出意见
需要注意的点 - 可以提前熟悉技术设计文档，尝试练几遍，做到表达清楚
- 之前需求详评审没有确认清楚的点（技术向），主要是接口的使用等，可以在会议上提出
- 参与方提出的问题，可以直接在文档里进行评论作为记录，会后在群里给出todo&ddl
● 评估排期
在开完需求详评后，会需要各个参与方评估工期（做这个事情需要多久，人/天），排期（从啥时候开始到结束）。新手熟悉阶段，一般是mentor会帮忙评估排期，但是到需要自己独立负责时，就需要自己评估，工期和排期也相当重要，即使pm催的紧，也不应该着急地给出不够准确合理的排期，不然坑的就是自己以及合作方（血泪史）、 - 工期和排期的依据就是你的设计文档，前两步做好了，这步就会比较轻松
- 推荐在设计文档里对需求进行细粒度的拆分，每个小的feature给出对应的工期。可以按照一个接口0.5pd～1pd来。
- 如果有其他部门的依赖，或者有前端的参与，需要算上和其他方的联调时间，简单计算方式是接口数量/2or3
- 根据手上正在进行的需求&需求的优先级来评估介入时间。
● 开发&自测
一般如果前期设计&技术评审做的足够充分，开发和自测阶段不会有什么大的问题，但是如果开发过程中发现一些和前期预期不一致的点或者有阻塞点，不能如期交付的，一定要第一时间同步给mentor&pm，有风险一定要抛出来，有风险一定要抛出来，抛出来！（重要的事情说三遍）
自测需要测试给出冒烟case。
● 测试用例评审
主r是qa，qa会根据prd输出测试用例，测试用例评审主要是参与方一起评估测试用例的正确性，站在各方的角度考虑现有的case覆盖的场景是否足够。
参会时如果有你觉得很重要的点，但是qa没有提到的，特别是一些兼容性问题，涉及到老逻辑回归的，需要提出来，以及接口是否需要压测等等
● 提测
提测前需要给出提测文档，这个问qa要就好了～
（此处应该有一个提测文档模版）
● 部署上线
上线前给出上线单，涉及到参与方比较多的，可以拉会确认评估是否有问题
上线策略需要选择灰度单台，灰度15-30min，灰度时需要登陆机器看下日志有无异常
并且查看监控是否有接口异常增多，耗时增加等
3.其他问题
● 需求并行
○ 尽量不要需求并行，在接需求初期就和pm、mentor同步好自己手头的工作。真滴没得办法了，就按照需求上线的时间、重要程度进行排序。需要注意点的是自己也需要和cpu的工作原理一样，外部看是并行，实际在某一个时间分片只能是串行的，做到先把一件事情处理好（结束）再去处理下一件。
● 产品需求变更
○ 需求详细评审过后，在你开发、自测、联调、测试阶段，pm都有可能变更需求，这个时候需要敏锐的察觉到，并且和mentor商量/自己评估工作量，考虑是否需要增加工期，修改排期，确认需要后，在群里同步（不要私下口头达成协议）排期的变更并说明原因，需要让pm将变更的内容标准到prd中，同时同步fe/qa同学，方便版本一致和有迹可循（@郭嗣彧补充～）
● 养成文档化的好习惯
○ 做到心中有数，也方便以后查看
● 沟通方面
○ 金字塔原理，结论先行，分点陈述
○ 尽量减少一对一（线上/线下）的沟通，有问题都在群里进行反馈，留下沟通的记录，之后出问题了可以有记录可以查询，避免被甩锅
○ 线上会议结束后，整理好会议结论&todo，发到群里@ 相关人员
● cr（code recview）
○ cr对于个人成长/业务质量来说都非常的有必要，特别是对于还在成长期的校招同学。可以通过cr发现：设计上的缺陷：你的设计和需求实际要求是否有偏差；实现上的缺陷：是否有显而易见的异常可能性，是否有更加优雅、更加面向未来的写法等等。会对需求的交付质量是进一步的保证，对个人成长也有很大的帮助。
○ 提cr的时机：最佳做法是在提测前就提cr，保证设计上没有大的问题
○ 心态上：千万不要觉得cr是在给你挑刺，而是一次非常宝贵的学习机会，是你的前辈在花时间帮助你来提高。
○ 行动上：
■ cr前：在提cr前，先自己认认真真地检查一遍，保证没有一些基础的错误，包括拼写、注释、npe等，
■ cr中：对于mentor提出的问题不太明白的地方，可以一起沟通讨论。
■ cr后：推荐单独起一个文档，记录下cr时需要修改的点，方便回顾。
