Code reviews are more than another task standing in the way of deployments. When code reviews are good they can be used to build community, trust and teach. At worst, they become punitive, nerve-wracking and destructive.
Lemme give you a little story.
I was well into my career as a developer and working at a new company. I was reviewing some code for an epic which I wasn’t too familiar with, written by a developer who was more senior than me.
Looks good to me! LGTM.
The code blew up spectacularly and the tech lead slacked me that fateful day. He wanted to discuss the oversight.
I was a bit shocked. I mean, it wasn’t like I wrote the code right? In his opinion I was as much to blame for the critical error that happened as a result of the offending code as the actual developer.
I was embarrassed and a bit upset. I also knew he was right. I had essentially rubber stamped the code without doing a thorough review.
He was an amazing reviewer. He always seemed to be catching issues and I wondered what his methodology was. So I asked.
Here’s the process he used:
- Run the code locally of course — before you even look at the code!
- Act as a QA engineer would and try to “break” the functionality by exploring edge cases and explicitly use the feature as unintended
- Open the console and check for any errors or warnings
- If this is a UI change — test against different browsers and screen widths
- Run any associated unit tests
- Run the entire test suite and ensure nothing fails
Code Quality (Only done if user testing does not reveal any issues)
- Repeated code should be abstracted into helpers
- Is it scalable? No nested for loops or computationally expensive functions? Will it work if the input increases by tenfold?
- Immediately clear variable naming conventions