有一种习惯，叫看代码找问题；有另一种习惯，叫不看代码很不习惯。
这，矛盾，处处不在！
review代码（code diff升级）到底可以做些什么？该做些什么？
1、整体代码风格是否贴切已有框架的设计风格
一个系统本有一套体系，你就不按这个走？前人踏过无数的坑，你就要去踩？
2、注释
别人问，这定义的什么？回答：忘了
别人问，这个是干嘛的？回答：忘了
！！！！！！
3、入参的定义，出参定义（特别是枚举）
考虑某个入参是否以前已有定义？是否其他系统已有定义？是否数据库已有定义？
本部门内各系统，同一含义的参数最好（应该强制）都统一，不然系统与系统之间交互要转来转去，与数据库交互要转来转去。
4、日志打印
a、前端入参、或接受其他系统调用的入参必须打印；
b、调用依赖服务入参、出参必须打印；
c、捕获的未处理异常堆栈信息必须打印；
d、捕获的处理异常打印的信息必须明确问题所在；
e、日志级别得明确
5、异常处理
a、异常类型定义必须明确，不能一股脑抛系统异常；
b、调用第三方服务，最好单独包一层try catch（不单单是整个外部方法的异常捕获）；
c、。。。。。。
6、埋点统计
我要用户访问量！
我要异常访问量！
我要今天多少用户干嘛干嘛的量！
7、报警机制
调用第三方出问题了，自己不知道；
别人要服务大概响应时间，自己不知道；
自己服务有问题了，自己不知道；
多么尴尬的事！
8、业务实现
a、了解清楚需求了吗？
b、这设计方案讲得通吗？
c、依赖服务文档看没？
d、联调过没？交互流数据确定过没？
e、在什么环境联调？本地也叫联调？
f、表设计合理？索引创建合理？
g、增删改sql没问题？
h、简单的参数check完善？
i、完全信赖别人的传入？
j、穿插的不是很重要的消息推送做了无伤大雅处理？
k、能异步处理的开了新线程？开的新线程有效？
l、 。。。。。。