This commit is contained in:
Alexander Kuzmenkov 2021-04-14 16:51:01 +03:00
parent 2594ee08c5
commit d3e06e6cfd

View File

@ -1,6 +1,6 @@
---
title: 'The Tests Are Passing, Why Would I Read The Diff Again?'
image: 'https://blog-images.clickhouse.tech/en/2021/code-review/smaller-crazy-duck.jpg'
image: 'https://blog-images.clickhouse.tech/en/2021/code-review/normie-duck.jpg'
date: '2021-04-14'
author: '[Alexander Kuzmenkov](https://github.com/akuzm)'
tags: ['code review', 'development']
@ -28,7 +28,7 @@ When working in a team, you even have a luxury of explaining your code to anothe
Code review is often framed as a gatekeeping process, where each contribution is vetted by maintainers to ensure that it is in line with project direction, has acceptable quality, meets the coding guidelines and so on. This perspective might seem natural when dealing with external contributions, but makes less sense if you apply it to internal ones. After all, our fellow maintainers have perfect understanding of project goals and guidelines, probably they are more talented and experienced than us, and can be trusted to produce the best solution possible. How can an additional review be helpful?
<img src="https://blog-images.clickhouse.tech/en/2021/code-review/hidden-items.png" width="80%"/>
<img src="https://blog-images.clickhouse.tech/en/2021/code-review/hidden-items.png"/>
A less-obvious, but very important, part of reviewing the code is just seeing whether it can be understood by another person. It is helpful regardless of the administrative roles and programming proficiency of the parties. What should you do as a reviewer if ease of understanding is your main priority?