代码Review的艺术：如何给同事提有建设性的意见

# 代码Review的艺术：如何给同事提有建设性的意见 做了三年的Code Review，一开始经常把同事搞得很不爽。后来总结了一套方法，分享给大家。 ## 反面教材 ``` // 不要这样写Review评论 "这代码写得太烂了" "为什么不用xxx？这都不知道？" "又是这个问题，说了多少次了" ``` ## 正确姿势 ### 1. 对事不对人 ``` // 差评："你这个变量命名太烂了" // 好评："这个变量名改成 userActiveCount 是否更清晰？" // 差评："你怎么又忘了加空指针检查" // 好评："这里 user 可能为 null，建议加个判空" ``` ### 2. 给出具体建议 ``` // 差评："性能有问题" // 好评："这个循环内每次都 new ArrayList，建议提到循环外面" // 差评："这段代码可以优化" // 好评："这里可以用 Stream 的 groupingBy 替代手动分组： // Map> grouped = // orders.stream().collect(Collectors.groupingBy(Order::getStatus));" ``` ### 3. LGTM的标准 我们团队的标准： - 没有明显bug - 没有安全隐患 - 代码风格一致 - 有必要的注释 - 核心逻辑有单测 不要追求完美，能达到以上标准就可以Approve。追求完美的Review只会拖慢整个团队的交付速度。 ### 4. 及时Review 超过24小时没Review的PR，提交者的心态就从"期待反馈"变成"你到底看不看"了。设定SLA，24小时内必须首次Review。