mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-11-21 15:12:02 +00:00
fixes
This commit is contained in:
parent
2594ee08c5
commit
d3e06e6cfd
@ -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?
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user