Open winterggg opened 5 months ago
本文取材自《The missing readme》-- Chapter 6
你的目的是让评审者理解你在做什么以及提供有建设性的反馈,有些建议可以遵循:
对于大体量的代码修改,需要安排 walking-through 会议,内容主要是快速回顾设计文档,在 IDE 里以某种顺序展示代码。解释任何新模型或抽象背后的主要概念、它们是如何被使用的,以及它们是如何整合的。这个会议的目的是让团队快速理解为何要提出修改,并给他们一个良好的心理模型。
(这个对于简道云有点高级了,不过我感觉 walking-through 会议的一些信息完全可以在 PR 描述里传递)
一方面不要羞于要求别人评审你的代码,另一方面收到评论后要及时回应,你回应得越快,得到他人回应的速度就越快。
给自己洗脑 -- 这些评审意见是针对代码的,而不是针对你个人的。
得到很多建议不意味着你没有通过考验,只意味着评审者正在参与到你的代码中并且在思考如何去改进它。
尽量保持开放的心态。
关于如何看待评审,摘抄一段不久前刷到的文章:
代码评审是我们工程师通行的质量管理手段。它基于这么一个事实:不管一个人有多聪明多细心,他总是考虑得不完善,需要同事提供 peer review。因此它也暗含了这么一个规则:一个人的代码被驳回或者被要求重写,并不代表此人水平不行。代码评审过程中的意见不应该被视作对原作者的批评。这条规则被广泛采纳,大名鼎鼎的 Linus 就因为喜欢在代码评审的时候攻击原作者,被社区停职了一段时间。
按照重要程度来排序,同时对于一些小改动也可以快速评审。
提前在日历上规划评审时间。如果收到一个评审需要花费一两个小时,创建一个 JIRA 任务跟踪代码评审本身。
包括:正确性、可实施性、可维护性、可读性和安全性。要承认优点。
区分问题、建议和挑剔:简单来说,将提出的建议与真正希望的修改区分开来。比如可以在一些建议前加上「可选」、「Nit」之类的。
不要忘记评审测试代码:从测试代码开始评审是比较好的实践,它们说明了代码是如何被使用的,以及预期会发生什么。
尊重当前的修改范围,不要给出一些明显超出范围的修改意见,如有需要可以创建任务。
一方面大型的改动在网页端很难浏览;另一方面本地代码可以运行,可以创建测试用例来验证,甚至构造失败的场景,以更好的说明评审意见。
代码评审
当你是被评审者
精心准备
你的目的是让评审者理解你在做什么以及提供有建设性的反馈,有些建议可以遵循:
walking-through 会议
对于大体量的代码修改,需要安排 walking-through 会议,内容主要是快速回顾设计文档,在 IDE 里以某种顺序展示代码。解释任何新模型或抽象背后的主要概念、它们是如何被使用的,以及它们是如何整合的。这个会议的目的是让团队快速理解为何要提出修改,并给他们一个良好的心理模型。
(这个对于简道云有点高级了,不过我感觉 walking-through 会议的一些信息完全可以在 PR 描述里传递)
保持主动
一方面不要羞于要求别人评审你的代码,另一方面收到评论后要及时回应,你回应得越快,得到他人回应的速度就越快。
不要太在意
给自己洗脑 -- 这些评审意见是针对代码的,而不是针对你个人的。
得到很多建议不意味着你没有通过考验,只意味着评审者正在参与到你的代码中并且在思考如何去改进它。
尽量保持开放的心态。
关于如何看待评审,摘抄一段不久前刷到的文章:
当你是评审者
分流和预留时间
按照重要程度来排序,同时对于一些小改动也可以快速评审。
提前在日历上规划评审时间。如果收到一个评审需要花费一两个小时,创建一个 JIRA 任务跟踪代码评审本身。
提供全面的反馈
包括:正确性、可实施性、可维护性、可读性和安全性。要承认优点。
区分问题、建议和挑剔:简单来说,将提出的建议与真正希望的修改区分开来。比如可以在一些建议前加上「可选」、「Nit」之类的。
不要忘记评审测试代码:从测试代码开始评审是比较好的实践,它们说明了代码是如何被使用的,以及预期会发生什么。
尊重当前的修改范围,不要给出一些明显超出范围的修改意见,如有需要可以创建任务。
在 IDE 里评审
一方面大型的改动在网页端很难浏览;另一方面本地代码可以运行,可以创建测试用例来验证,甚至构造失败的场景,以更好的说明评审意见。