Lately, I was asked by one of my trainees why I am so persistent when it comes to code reviews. An interesting question if you ask me, so I decided to take a closer look as to what my big Whys were, and also wanted to ask you what you think about the (sometimes feared) Code Review π»π»!
No matter if your dev-team is looking on a Scrum or Kanban board on a daily basis (π₯) there most probably is this one column with a header like To Verify, Testing or QβnβA written prominently above it. Why? Well, in my mind there are a lot of good reasons for cultivating code reviews within, especially small, dev-teams:
π Quality Assurance: Four eyes always see more than two and so potential bugs or pitfalls can be fixed on the spot. The argument of quality of course needs to be the first point on this kind of agenda as it is the most practical reason for their existence.
ποΈ A Break from your own Tickets and Code: Personally I love nothing more than spending Monday mornings with some delicious coffee reviewing new merge requests to again find into the right mindset for the week and stay up-to-day with current developments.
π± Everyone Learns Something new: Of course, always depending on your levels within the coding domain, both β the coder and the reviewer β will always learn something new in the process. Be it how to do something or how not to do something.
π¬ More Communication: Especially with home office and remote work, working together changed a lot over the scope of the past few months (and actually years!). The biggest pain-point for most people probably was the lack of interaction with their peers and colleagues, and personally within the scope of reviews I communicated the most with my co-workers also on a personal level.
What are your opinion on Code Reviews? What other Whys do you see (so I can hype my protΓ©gΓ© up even more when it comes to them)?
Looking forward to hearing your thoughts π.
Cover picture by Markus Winkler on Pexels π
Top comments (8)
Code reviews make a huge difference to a developers career development. Over time your code will improve and as a consequence you become better at code reviews yourself so you become a better developer overall.
This is very true! π I think that when reviewing one takes way more time actually thinking about the code that is there - especially regarding side effects - because you do not have to actually solve the problem anymore and can put your focus elsewhere.
I agree you become a more dependable developer and it can be the difference between a junior, mid or senior. Reviewing other developers code can really raise your status within a team.
I like how you phrased that - more dependable developer - I think reviews help you to understand the big-picture of a software, not just codewise, but also people-wise. You get to know your peers on this professional level and start to understand how they think about certain challenges and how they approach them!
Code Reviews are probably the single biggest factor in a developer's growth in terms of written better code or better understanding frameworks. It's also a really good way to challenge your own patterns and solidify why certain things work or don't work.
I've also found Code Reviews are a good way to practice giving good feedback. It's not something we get the chance to do often, but it helps in-office relationships if you can give good feedback without sounding like you're taking jabs at their code.
I never thought of the hands-on experience of giving feedback one of course gets when reviewing! It especially is a nice way of doing so, because it is a very practical one - the code is what it is and that is where the conversation starts!
Good article. In my mind is a bit like code review vs pair-programming . What you think?
Yes, there is a big difference! π I think the main one between those two practices is where the focus goes. When reviewing, you of course have the problem in mind and maybe your way of how you would have approached it, yet the focus lays on the existing code. When (pair) programming the main concern is writing the code, no matter how hard you think about everything that is written in any programming book ever. Code has to be written before it can be improved - it is just a different kind of mindset! π±