发布于 2026-01-06 2 阅读
0

提升代码审查能力:像设计师一样进行审查

提升代码审查能力:像设计师一样进行审查

最让我恐惧的莫过于别人审查我的代码。我过去做过很多前端开发工作,但都是在只有我一个人写代码的地方——一想到要和其他工程师共享代码库,我就害怕。以前,只要从用户角度来看没问题,就算代码是“好代码™️”。我知道“好代码™️”的真正含义并非如此,而且我确信清算之日即将到来(事实也的确如此)。

我之前没怎么考虑过,其实我在艺术院校和后来做平面设计师的时候就已经积累了多年的作品点评经验——说实话,我第一位创意总监对我的作品的评价比我经历过的任何代码审查都要刻薄得多(至少目前为止是这样🤞🏻)。更重要的是,那些年点评他人作品的经验让我成为了一名更优秀的代码审查员

所以,即使你不是艺术爱好者,你也可以借鉴优秀艺术评论的准则,在下次撰写公关稿时留下更好的评论:

退后一步,理解这项工作的背景。

杜尚的著名作品《喷泉》乍看之下不过是一个小便池——如果你不了解它的历史背景的话。但退一步来看,你会发现它远不止于此:它挑战了那些自以为能够定义艺术的人,是对艺术中现成物运用的一种反思,同时也提出了一个开放式的问题:究竟要对一件作品进行多少改动,才能将其据为己有?正是这些层面——而非其字面形式——使得它成为现代艺术史上的一件关键之作。

应用程序整体架构中的一小段代码也是如此——如果你不了解他们试图解决的问题的全局,就无法判断它的用途和解决方案的有效性。不要只浏览修改过的代码行;务必整体审查文件,并将其与最初促使你进行这项工作的功能或错误进行比对。

以友善的方式表达不同意见。评论艺术作品,而非评论艺术家本人。

如果你直接向同事提出批评意见(而不是对博物馆藏品进行批判性分析),坦诚得体都至关重要。与普遍认知相反,这两者并不比谁更重要。记住,最终目标是创造更好的作品,而不是炫耀自己的知识、贬低他人、唱反调等等。确保你的建议基于事实而非个人观点,并且以改进为导向。如果你不喜欢或不同意某些内容(这很正常),请确保你的评论也包含你认为更好的改进建议。

最后:不要用“三明治式”回复法,也就是先夸奖/批评/再夸奖。这种方法容易被识破,会让夸奖显得不真诚,即使你的夸奖并非真心。

技术执行固然重要,但这并非唯一需要评判的方面。

合并到共享代码库中的代码应该尽可能地符合技术规范:这一点毋庸置疑。我有个同事似乎把确保我的代码在每个 PR 中都完美缩进作为自己的使命,如果缩进不正确,他就会留言指出——我很感激这一点。我也很感谢我的同事指出哪些地方可以遵循 DRY 原则(避免重复代码),哪些地方的命名结构不一致或不清晰等等。技术注释是代码审查最显而易见的目的,但我认为同样重要的是要记住,这并非代码审查的唯一目的。

一幅好的画作并非仅仅取决于它是否逼真地描绘了对象——还有其他因素在起作用。技术上的不足会限制作品的发挥,需要加以改进,创作者才能有所进步。然而,如果你只关注技术细节,我建议你也从整体结构的角度来审视作品。

多问问题,不要妄下结论。

妄下断言很容易,但99%的情况下,它都会得出错误或带有偏见的答案。当你阅读他人的作品,却不完全理解他们的某个选择时,不妨请他们解释一下——这往往是双方学习的机会。

  • 如果创作者并非有意选择(比如他们不假思索地选择了蓝色作为背景),那么询问他们为什么这样做,他们通常会说“嗯,我其实也不确定!”,然后重新评估。
  • 如果他们做出了有偏见的选择(他们选择蓝色是因为那是他们最喜欢的颜色),这将迫使他们为自己的选择提出理性的辩护,而不仅仅是“我就是喜欢它”。
  • 最后,如果他们确实有合理的理由(例如,他们选择蓝色是因为蓝色具有镇静作用),那么他们就可以告诉你他们的选择,这样你就获得了以前没有的信息,这将有助于你理解作品。

如果你只留言“把它变成红色”,这一切都不会发生。

你不需要成为更优秀的艺术家才能提出评论。

这一点我一直很纠结(特别感谢我的好朋友——冒名顶替综合症🙌🏻),但你不需要成为大师才能评论别人的作品。我敢打赌,你们大多数人即使不会画火柴人,也能通过欣赏一幅画作形成自己的观点。事实上,如果你不断欣赏各种不同的画作并形成自己的见解,我们就称之为“接受艺术教育”。

代码也是如此。我刚开始学习 Ruby,为了帮助我达成目标,我的同事们会在他们使用 Ruby 时把我添加到他们的 PR 中。这让我有机会熟悉这门语言,了解他们如何解决问题,搜索我不熟悉的语法,或者有时只是问问“嘿,你为什么用 X 而不是 Y?”这对我来说是一个绝佳的学习机会,我惊讶地发现,即使是在我还是个新手的情况下,我也能经常发现问题。

注意哪些方法有效,而不仅仅是哪些无效。

我们通常认为代码审查或点评是让别人指出我们工作错误的机会,但它的意义远不止于此——它也是一个讨论哪些地方做得好的机会。那位总是唠叨我缩进的同事,也总是在我做得好的地方留下很棒的评论。有时候,他只是在某行“好代码™️”旁边点个赞而已。谁知道呢——如果梵高的作品能多得到一些赞,也许整个耳朵事件就能避免了。

文章来源:https://dev.to/kathryngrayson/the-no-bs-guide-to-being-a-dev-with-a-bfa-code-reviews-3d89