Today, I attended a lunch and learn session on code reviews and I learned quite a bit about good code review processes. I will discuss some things that were mentioned that really stuck out to me.
One of the many benefits of code reviews is that there is less impact when someone leaves the team since others will be familiar with their code. As obvious as this seems, I sometimes worry that other developers have some magical ability to understand other people's code instantly without even having reviewed it very much. It is silly, but it is nice to be reminded that it can take some time to familiarize yourself with someone else's code.
There are three types of code reviews: inspections, short reviews, and walk-throughs. Inspections involve defect-detection, but not correction. Short reviews are reviews of small changes in code. Surprisingly, small changes to code tend to cause more errors than larger changes. In this context, a small change refers to a change of approximately less than five lines. Walk-throughs are the kind of code review that I am most familiar with. Apparently, they are also not very effective. A walk-through is a type of code review where a (usually) more senior developer will walk-through a more junior developer's code with them.
Every developer's code should be reviewed equally, regardless of level. I did not necessarily expect to learn this during the presentation because I have heard a lot of talk in the tech world about junior developers benefiting from mentorship. This is not to say that the implication is that juniors should not be mentored.
When I attend various tech events, there always seems to be a tech term that comes up that I am not familiar with. Today's was "linters." A quick web search taught me that (in the context of computer programming) a linter is simply a program that checks code for style errors.
Thanks for reading!
One of the many benefits of code reviews is that there is less impact when someone leaves the team since others will be familiar with their code. As obvious as this seems, I sometimes worry that other developers have some magical ability to understand other people's code instantly without even having reviewed it very much. It is silly, but it is nice to be reminded that it can take some time to familiarize yourself with someone else's code.
There are three types of code reviews: inspections, short reviews, and walk-throughs. Inspections involve defect-detection, but not correction. Short reviews are reviews of small changes in code. Surprisingly, small changes to code tend to cause more errors than larger changes. In this context, a small change refers to a change of approximately less than five lines. Walk-throughs are the kind of code review that I am most familiar with. Apparently, they are also not very effective. A walk-through is a type of code review where a (usually) more senior developer will walk-through a more junior developer's code with them.
Every developer's code should be reviewed equally, regardless of level. I did not necessarily expect to learn this during the presentation because I have heard a lot of talk in the tech world about junior developers benefiting from mentorship. This is not to say that the implication is that juniors should not be mentored.
When I attend various tech events, there always seems to be a tech term that comes up that I am not familiar with. Today's was "linters." A quick web search taught me that (in the context of computer programming) a linter is simply a program that checks code for style errors.
Thanks for reading!
Comments
Post a Comment