I would distinguish two kinds of code reviews, which any developer could do:
1) Check code style to be it as "Clean code" suggests and that it follows project's code conventions
2) Do check code "adequateness", if it provides a proper solution and not a dirty hack.
That it's design is good enough for the project.
First type could be done by anyone.
To be more efficient with the second you should be an "expert" in a code which you do review. So, some tools could be useful, which suggest recommended reviewers.
The first type of code review can be done by anyone, indeed. Having linters help too!
Regarding adequateness, I feel there are two ways to review this. Design discussion and code review. I try to hold design discussions if the feature / fix being worked on is major and / or extensive. Changing the approach before you write the code is more efficient than changing the approach after going through a code review.
Thanks Ali for sharing this!
I would distinguish two kinds of code reviews, which any developer could do:
1) Check code style to be it as "Clean code" suggests and that it follows project's code conventions
2) Do check code "adequateness", if it provides a proper solution and not a dirty hack.
That it's design is good enough for the project.
First type could be done by anyone.
To be more efficient with the second you should be an "expert" in a code which you do review. So, some tools could be useful, which suggest recommended reviewers.
Thanks for the feedback, German. 🙂
The first type of code review can be done by anyone, indeed. Having linters help too!
Regarding adequateness, I feel there are two ways to review this. Design discussion and code review. I try to hold design discussions if the feature / fix being worked on is major and / or extensive. Changing the approach before you write the code is more efficient than changing the approach after going through a code review.
Indeed, absolutely agree that it is better to review approach before implementing it.