一 Review的关键节点指导
- 架构是否合理：虽然是在Review代码，其实很多时候我们都是在评判架构是否合理。 比如数据的同步机制是否合理等等；
- 跨网络请求：跨网络请求一般是性能占比最高的地方，是否在循环中调用，是否在子线程、是否反注册；
- 异常处理：结合业务查看异常处理流程是否正确合理，异常是否需要精细化，是否在catch中捕获了全部异常；
- 算法效率：算法是否过于复杂；
- 内存泄漏、OOM；
二 工作中常见的代码Review点实操
1、for循环中的remove操作（return、break除外）；
2、super非阻断性的放最前；
3、自己的代码注释修改；
4、try catch 注意需不需要Exception 包囊全部；
5、横竖屏在8.0上的问题；
if (Build.VERSION.SDK_INT != Build.VERSION_CODES.O && Build.VERSION.SDK_INT != Build.VERSION_CODES.O_MR1) {
setRequestedOrientation(ActivityInfo.SCREEN_ORIENTATION_PORTRAIT);
}
6、注册反注册、网络请求unsubscribe
7、注意循环内try，不影响下一个item的处理；如果循环外try，一旦报错整个循环就结束了；看场景确定内try还是外try；
8、合理使用成卫语句，也不要硬写成卫语句，如下为硬写：
if(){
...
return 结果；
}
return 结果；
9、map和循环：Map比for遍历效率更高。
10、数据结构和程序有时候是可以互相转换的，比如如下程序
if (str.equals("a")) {
return "1";
} else if (str.equals("b")) {
return "2";
} else if (str.equals("c")) {
return "3";
} else {
throw new UnsupportedOperationException();
}
可以用数据结构表示：
Map<String, String> map = new HashMap<>();
map.put("a", "1");
map.put("b", "2");
map.put("c", "3");
使用的时候：
if (map.containsKey(str)) {
return map.get(str);
} else {
throw new UnsupportedOperationException();
}
11、未使用的 import；
12、未使用的资源，例如 drawables, strings, colors……
13、未格式化的代码；
14、注意修饰符：自己写的类中中的一些方法或方法，如果确认仅仅为自己使用，请用private，请不要暴露了，这样有利于降低整个项目的复杂度；
15、静态分析工具在代码审查过程中很有帮助：
16、代码不遵循样式指南。 例如，Kotlin 定义了一个定义明确的样式指南。 它对任何开发人员在现有代码库中快速找到任何软件组件都有很大帮助。
最后一点：保持积极和虚心。
也有也有很多review的评论是愚蠢的，或是可以没有。但自我确实会写一些“烂代码”自我不能及时发现。若果与我具备差不多水平的人提出疑问，那么他肯定有一些我没有理解到的想法在里面；在评论中表现得友善，尊重他人的时间和工作，在代码review中吹牛、羞辱或生气没有任何好处。
参考
1、https://juejin.cn/post/7119475006408491022
2、https://juejin.cn/post/7119475006408491022
3、https://juejin.cn/post/7119414483566460935