code review 怎么做？
- 提交合入请求后，仍然需要查看git上面的差异报告，总有一些想不到的地方是有问题的
- 代码，配置文件，sql需要保证对应的上此次修改，因为要交付给运维使用
- 尽量使用原有代码逻辑，如单个操作接口转批量操作接口，为避免过度优化，建议调用单个操作接口对应的API实现批量操作接口
- sql语句会出现多次修改，需要更新最后修改到何如文件上面；如以下例子，新增一个叫做taskId的字段，并且增加了taskId的索引，但是因为taskId不符合一般的字段明明，所以会将字段改为task_id，但是如果忘记修改新的索引，会导致上线时SQL语句报错
- 因为是持续交付项目，所以为了保证代码可以持续性，如果要修改某个配置文件的名称，如果像是修改redis-time直接修改为alarm-redis-time，那么旧微服务在更新为新版本微服务时，会出现一段时间的该字段是小问题；正确做法应当是新增一个alarm-redis-time属性供新版本微服务在未来使用，redis-time则备注在下一个迭代删除
- 配置文件尽量不新增，减少运维工作量
- 日志尽量少打，因为大量日志会导致检索服务花费大，且导致过度消耗CPU；打印日志时，需要将入参，当前业务涉及对象进行打印，避免线上出问题导致无法排查
- 进行业务开发，需要将大的业务步骤之间进用空格分隔，并且使用备注表明逻辑；整个的逻辑链路需要做到口述出来