✨今天我学到了：代码审查的微妙艺术💡✨

代码审查很难。我审查的 Pull Request 是针对My Photohub项目的。

人生中第一次代码审查，让我意识到这项任务有多么艰巨。作为第一次代码审查员，我发现自己盯着代码，苦苦思索着如何才能改进它。感觉相当迷茫。我提出了一些平庸的建议，没什么特别好的，也没有什么让我真正满意的建议。然后，Dave 教授来审查我正在审查的同一个拉取请求。我坐在那里，惊讶地发现他审查的细节以及我所忽略的一切。他提出了一些重要建议，比如改进编程逻辑，也提出了一些小建议，比如更新项目描述。我本来也可以提出这些小建议，比如更好的项目描述，一个更符合项目风格的、取代默认 React 标志的更好的标志，以及为某些方面创建后续问题。为什么我会忽略那些显而易见的问题，而这些是 Dave 教授如此优雅而轻松地指出的呢？
因为我当时太执着于寻找一些重要的建议，以至于我的感官完全忽略了那些简单的事情。这让我意识到，我需要多多练习阅读别人的代码，并进行批判性思考。就像精通任何技能一样，成为一名优秀的代码审查员需要时间、耐心和练习。

一些代码审查最佳实践

这是我在研究代码审查最佳实践时偶然发现的一篇很棒的文章
。 它精彩地阐述了设计、功能、复杂性、测试、命名、注释、风格、一致性、文档和上下文如何成为代码审查的重要组成部分。

时间。注意力。沟通⏳‼️

好的评审需要时间和精力。它要求我们批判性地思考编程逻辑。对于初学者来说，盯着别人写的代码去尝试一些有意义的东西可能会让人感到不知所措。他们害怕犯错，害怕冒犯编写代码的人。我理解，因为我自己也经历过这些。然而，在开源开发中，在提供建设性反馈的同时，保持礼貌和尊重的沟通方式始终很重要。我们有时可以不同意评审意见，但如果我们这样做了，应该礼貌地表达出来。

在给予和接受反馈时保持开放的心态也很重要。正是通过这种思想交流和反馈，我们才能随着时间的推移不断进步。

如果您有一定的编码经验，并且花费足够的时间并全神贯注于代码，那么几乎总是可以提出改进的建议。

从小事做起🐌🌱

如果你是初学者，那就从小事做起，向他人学习。我通过阅读 Dave 教授的代码评审学到了很多重要的东西。后来我意识到，只有通过观察经验丰富的人如何评审代码，我才能进步。我把在 GitHub 上阅读他的大量代码评审时学到的东西做了一些记录。我把这些内容整理成了一份清单：

• 如果不清楚，请询问有关某些代码行的具体问题。
• 寻找未使用的依赖项和优化 package.json 的方法。
• 从整个代码库的上下文来查看代码。
• 留下一些鼓励的话来指出开发人员做对了什么！
• 注重功能性和兼容性。
• 寻找清晰的名称和正确的命名约定。
• 在审查 README 或 CONTRIBUTING.md 文件时，请注意样式、格式、拼写和语法的一致性。
• 确保设计和 UI 看起来不错。
• 确保单元测试适合代码的设计。
• 确保代码符合提供的某种样式指南。

我的代码评审

以下是我过去几天进行的代码审查。点击链接即可查看完整审查 :)

在提出修改建议的同时，我也会提供修改背后的理由，并征求开发人员的意见。这确保了沟通的专业性和礼貌性。

评论 1

评论 2

我们linters相信🚀

自动代码检查器和静态工具分析器可以帮助审阅者节省大量时间，查找愚蠢的拼写错误或风格错误。Linter 和扫描器的作用类似于代码的拼写和语法检查。审阅者无需再为格式和其他风格问题而烦恼，就可以专注于代码的实际逻辑。作为代码审阅者，利用可用的自动代码检查器来节省时间和保持思路清晰至关重要。

关于生产力的总结

如果您像我一样喜欢阅读有关心理学和生产力的文章，那么这是一篇很棒的文章！