Everybody Loves a Code Review

Today we had an impromptu code review during a meeting which is actually intended for our feature teams to get together with the platform team to discuss any issues, ask questions or just address anything that might be of interest to others.

This time it was mostly our team trying to get some input on problems we already had discussed within our team but felt we could need more people to chime in on and collect new ideas.

My main issue was that I felt that I was stuck implementing the UI for a pretty straight forward feature. Unfortunately, though it was straight forward, it was also fairly non-standard. The good news was that we had implemented similar features already. The bad news was that we had implemented different parts of what I needed (or thought I needed) in different features, so I was taking code from three different features and trying to mesh it together for what I needed. I had come to a point where it was kind of working, but not really.

I had also come to a point where I didn’t know where to start looking to solve the issues I still had. Our team lead told me that she’d take a look at it with me to figure out where the problems were. That was pretty much what I was looking for, but since I was pretty frustrated already I went on a bit more about… well… basically about how frustrating it was that I was digging through code that I felt I should understand, but really didn’t. I guess my frustration showed, because the next thing I knew, I was asked to bring my laptop so we could all have a look at the code and figure out where the real issues were.

There were six of us and it took us about an hour to get through the main parts and leave me with a pretty good idea what was still missing and how to solve it. As it turned out the code wasn’t half as messy as I thought it was, but I had made a couple of stupid mistakes, mostly due to my inexperience with frontend development. We got to tidying up the code a bit and got the feature up and running (with a couple of things missing, but still).

At the end I wondered whether I should feel bad for taking up five developers‘ time to look at my code. But you know what: I think I shouldn’t. Both my team lead as well as another developer from my feature team said that they actually liked the small code review session and I got the impression that everyone else liked it as well.

Here are a couple of thought on why code reviews are good for everyone:

  • Everyone looks at code differently. Everyone thinks differently, so you get a lot of new ideas you would have never though of.
  • Everyone has different experiences, so it’s a simple way to learn new stuff. It’s also a good exercise for explaining things to others.
  • You’ll see problems and issues popping up that you didn’t know where actually a problem. This also goes for pretty small and random problems that otherwise would have never been mentioned. So now you have a chance at solving them.

Basically, code reviews are a good way to solve an actual problem, but it also might reveal a couple of underlying problems that people weren’t aware of before. It’s a nice and communicative way to get your brain working, whether you’re more of an expert in the matter discussed and are suddenly forced to explain concepts to your colleagues or whether you’re the one with the questions trying to find a solution to the problem at hand.

If you’re someone who doesn’t like to present your messy code to others for fear of being thought of as stupid or if you’re someone who doesn’t like to throw ideas around the room while purely looking at code projected on the wall, code reviews might not be thing for you. For a code review to work you can neither try to hide your coding mistakes not can you point fingers and laugh. It can turn out to be a challenge for everyone, but it can be a pretty rewarding challenge at that.

I guess my main point is, if you feel like a code review could help, do it. If you’re the one with the problems, don’t be shy. Everyone makes mistakes, everyone has problems understanding different things. People understand. If you’re someone with more experience, share it. Explain. And for everyone involved I would just say: Ask. Help. Suggest. Try. Enjoy.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert