I recently read this on Twitter:
Sadly, it seems code reviewing is a practice that's foreign to many students, freelancers and agencies. [Translated]
Apparently, it's not obvious to everyone that code reviews are actually helpful. Call me naive, but I really thought it was a process used in all IT companies. Apparently I was wrong, and it scares me.
In this article, I'd like to give my thoughts on code reviews, why I believe they're an important part of the code shipping process, and how to get started with them. If you don't do code reviews, or if you feel like you could do better, I hope this write-up will help!
What Is a Code Review?
We live in the era of Wikipedia, so allow me to begin by quoting the definition given on the Code review entry:
Code review is systematic examination (sometimes referred to as peer review) of computer source code. It is intended to find mistakes overlooked in the initial development phase, improving the overall quality of software. Reviews are done in various forms such as pair programming, informal walkthroughs, and formal inspections.
A code review, as the name states, is the process of reviewing some code in order to make sure it works, and in order to improve it where possible.
Ways to Do a Code Review
As the Wikipedia definition notes, there are various ways to perform code reviews. However, in a world where so much code lives on GitHub, code reviewing often goes hand-in-hand with what we call a “pull request”.
A pull request is a request to introduce changes to a code repository using a distributed version control system (Git, SVN, Mercurial etc.). It works by “pulling” the original code, applying changes, then submitting a request to merge the changes in.
GitHub made this process particularly easy and efficient thanks to its friendly user interface, abstracting most of the Git knowledge requirements.
Why Reviewing Code Matters
So, why does code reviewing matter? After all, we’re all competent here. Surely we can ship code without having someone metaphorically standing over our shoulder, watching everything we do.
In theory, yes. But in practice, there are many reasons why having an established code reviewing process helps. Let’s look at a few of them.
It limits risks
This is probably the most important reason of all. Having someone double-checking our work never hurts, and limits the risk of unnoticed mistakes. Even good developers get tunnel vision sometimes.
It’s always good to make sure not to forget anything. For instance, proper keyboard navigation, screen reader accessibility, flexibility for internationalization and friendly, non-JavaScript behavior are often forgotten topics in the front-end world, to name but four.
It dramatically improves code quality
Let’s make something clear: this is not about standards and code linting (at least not exclusively). It's about making code more efficient.
In a team where everybody has their own background and strong suits, asking for improvements (because that’s what it's about) is always a good idea. Someone could suggest a smarter solution, a more appropriate design pattern, a way to reduce complexity or to improve performance.
It makes everyone better
By joining forces, everyone can learn and get better. The code submitter is likely to receive feedback on their work, making them aware of possible problems and areas for improvement. The reviewers could well learn new things by reading through the code, and figure out solutions applicable to their own work.
It helps being familiar with the project
When a team works on a project, it's highly unlikely that every developer is working on every part of the application. Sometimes a developer will heavily work on one large part for a while, while another one is working on something else entirely.
Doing code reviews helps people familiarize themselves with code they haven't written but might be asked to maintain in the future. It promotes knowledge of the codebase across the team, and is likely to speed up future development.
Continue reading %The Importance of Code Reviews%
by Hugo Giraudel via SitePoint
No comments:
Post a Comment