代码审查是否已经落伍？深入解析最新最佳实践！( 二 ) _代码审查

在我刚开始接触 IOS 开发时，我花在代码审查上的时间和学习 Swift 和 iOS 的时间几乎一样多。这使我能够快速地熟悉新的代码库，语言习语，最佳实践，以及了解项目中的关键人物。

我通常在面对学习新的大型代码库时，会立即开始进行代码审查（这是作者有效学习和了解新代码库的一种方法）

如何(how)编写大量的评论可能会让你感到枯燥乏味，因此你可能在表述上变得过于直白。书面交流与口头交流有所不同，我建议你遵循以下建议：
友善待人
这一点无需多说。通常情况下，当我向我不太熟悉的人写评论时，我会首先用一个简单的 "你好 " 打招呼。如果你发现有什么项目缺失，不要直接用 "这是不完整的" 来表示，你可以询问 "这里为什么会缺失？"
注意细节
尝试在关键的和不那么关键的修改之间找到平衡，这需要你的经验来指导。我们不希望因为一个小的空格问题而阻塞了一个重要功能的实现或者 bug 的解决！
询问作者的意见
如果你提出的改动不显著，或者你提出了重构的建议，那么最好在你的评论结尾处询问一下 "你怎么看？" 或者 "你对此有什么看法？"
有时需要权衡
有些项目比其他项目更为重要。尽量不要因为小的修改而坚持不懈，以免造成发布延迟。你可以与作者达成共识，以后再创建一个"打磨"分支。然而，我常说：

以后 == 永不（later == never）

不要做假设
你正在审查一个 PR 并发现了一个明显的错误，而这段代码的开发者的职称是"初级" 。你可能会假设这个错误是由于他们的经验不足，或对一些基本概念的理解不够深入。也可能是他们匆忙完成的，或者在度过了一天的劳累后提交的。或者……可能有一些我们未能看到的、合理的原因在背后。如果有疑问，告诉作者： "可能是我漏掉了什么，但是……"
保持个人偏好的开放性
当你在代码审查中建议更改时，确保这些更改是对代码的实实在在的改进，而非审查者的个人偏好，这些偏好可能并不符合公司或行业的最佳实践。当我提出这样的更改时，我会说： "这是个人偏好的问题，但如果你愿意，可以试试<代码更改>"
赞美作者
“看起来很好（LGTM）” 可能会被解读为“我草率地审查了你的 PR” 。对我来说，看到这个还好，但是，如果你真的认为代码写得很好，那就在 PR 中大胆地表扬。以下是值得赞扬的原因：引入了新的炫酷功能，或者进行了复杂但结构良好的重构。
如果 pull request 只包含一个简单的颜色更改或函数参数的添加，那么过度的赞美可能会被误认为是讽刺。请选择适当的语言表达。
副作用
尽管你持有善意，或者在代码审查过程中为项目贡献良多，有时你的行动可能仍会引发他人的反感。他们可能按照你的建议进行修改，但可能并未对你的审查表示感激。
有些人可能会驳斥你的建议
你的建议可能错误，无效，或者触碰到了作者的自尊心，使他们认为修改代码就等于否定自己。这没有关系。然而，如果你认为某段代码可能会导致严重的问题或性能影响，你应该考虑邀请其他开发者一起讨论，例如在评论中@他们，引导他们参与讨论。更好的做法是，尝试直接通过电话或面对面的方式进行讨论。
不要期待你的付出一定会得到回报
你或许为许多代码审查和批准做出了贡献，帮助审查了他人的代码，但当你自己的代码需要审查的时候，不要期待你的新 pull request 一定会受到关注。
你可能会收获友情
去年，我为了更好地熟悉某个代码库，我对一个新接手的代码库进行了持续的代码审查。我与许多开发者进行了积极的讨论，最终，对仓库中的一些模块进行了改进。这是作者和我——这位新来的代码审查者的共同努力的结果！我结识了一些愿意改进他们代码、并始终对新建议和学习保持开放态度的优秀人才。季度结束时，我向他们请求正式反馈，收到了非常积极的回应。我们可以称这种关系为"联系"，甚至我愿意称它为"友谊" 。
结语在这篇文章中，我们探讨了持续进行代码审查的诸多优点。我推广的 W3H 方法，就是一种给他人的代码提供反馈的流程。
在我所工作的 Expedia Group™，我经常应用这种方法，公司也倡导并正式提出了"有意识的包容"这一价值观。