回顾一年半之前，我还在作为一个项目的推进者，为整个项目的进度和完善而头疼。当时遇到的问题非常棘手。如今我又面临和完成了一个完整大功能的开发，完成度和问题解决上都有了一些进步。
一、一个完整的功能开发都有哪些阶段
1.1 需求评审
需求评审是整个流程的源头，是由产品同学将需求以文档的形式产出，然后拉着RD同学一起进行对需求进行评审。
在评审过程中，可以了解到需求的背景和作用，换句话说就是要做这个功能的意义。
当然还有很多问题需要搞明白：
1、这个功能在整个大的业务链路中有什么样的作用
2、它涉及到的交互上下游都有哪些，交互方式是同步还是异步
3、产品方案或交互方案是否合理
4、上游要求调用的耗时大约是多少，并发可能会是多少
5、文档中的规则或者描述是否清晰
6、异常的兜底方案是什么
我的一个习惯是：
要用大脑尽可能的在数据流的维度上，串一遍完整的业务流程。看看需求文档中是否缺失了哪些必要字段，可能会遇到哪些大卡点和小卡点。
1.2 技术评审
在进行完需求评审之后，就需要对功能进行技术方案的拟定。
其中就包含：
1、交互方式决定了通信方式
2、接口文档的产出，包括参数和返回值的数据结构等
3、数据库表的设计
4、类图设计
5、是否需要缓存
6、是否使用多线程的方式提高处理效率
7、是否使用分布式锁
8、特殊情况是否考虑清楚
9、是否需要兜底定时任务
10、是否需要分布式配置
11、是否需要限流和熔断
12、是否要加一个最外层开关
拉着qa进行技术评审，评审需要考虑的问题：
1、数据库设计是否合理，索引是否合理
2、类的设计是否合理
3、是否会发生死锁
不同公司的QA具备的能力不同，有的是会开发，能读代码；有的是只会黑盒测试，不关心内部实现，更侧重业务流程的验证和交互是否通顺。
1.3 开发
开发过程就是按照技术方案进行代码实现，当然，我们有单测覆盖率的要求，所以单测也可以算到开发过程中。
开发过程中也会遇到一些方案的考量：
1、是否需要用事务
2、分布式锁超时时间
3、是否存在主从库延迟，延迟的话是否加事务，或者强制走主库
1.4 自测
1、交互自测
2、各种逻辑分支测试，包括正向流程，异常流程，边界情况等
3、并发逻辑测试，主要是测试是否能安全上锁，上了锁以后是否能安全读写库等
4、压测
我的习惯：
尽量在每一个读写操作节点出摸你程序中断的情况，然后观察表中数据是否符合预期，比如：事务是否能正常回滚，兜底的定时任务是否能捞起异常流程等。
1.5 CR
一般在提交分支合并申请时，如果需求内容不多的话，tl 会自己 code review。如果是个比较大的功能，一般都是单独拉会，组内全员进行 CR。
1、类的设计是否合理
2、代码是否整洁，注释是否适中，是否存在潜在的NPE
3、其他可能未考虑到的问题等
1.6 联调
为了可以并行开发，服务提供方是需要给调用方提供mock调用的，无论是实时接口还是异步消息，都提供一个mock响应。先把两方的通信打通，这样联调就只剩下逻辑联调了。
当然，除了要在测试环境正常跑起来之外，最好还是记录一下在测试环境需要配置的内容和步骤，比如：
1、域名的配置
2、服务鉴权的添加
3、分布式配置的添加
4、数据库表的创建
5、公司内部的中间件平台上资源的申请，如：redis、topic和消费者的创建、分布式锁资源的申请等
讲这些一步步的都记录之后，上线前在准备上线单就不会漏掉了，因为在 tes 环境要完成的这些步骤，在 prod 同样也是要做的。
1.7 提测
一般能自测出来的问题都解决了，之后让QA完整的测一下。
1.8 预生产环境上线
等test 环境测试通过后，QA 会通过合并到 master 分支的申请，代码将会合并到 master 上。
在预生产环境上，公司之间会存在差别，我们公司是预生产环境与生产环境共用一套资源，如：数据库，topic和消费者，redis等。
在预生产进行构建和部署，一是要确保项目能在生产环境上正常启动；而是在生产环境上正常执行。
1.9 生产环境上线
完善上线单，一步一步在检查一下是否有漏掉的地方。
确认之后，进行上线操作。同时观察日志和监控。
二、可能遇到的问题
在整个功能开发过程中，会在不同的阶段遇到不同的问题。有可能代码写着写着，就会发现一个漏想的点，这个点可小可大，往小了说是少一两个字段，往大了说可能会成为整个需求的卡点。无论是大问题还是小问题，肯定越早暴露出来越好。
网友评论