Gorgo.Live.ToString()

Mariusz, Gorzoch tech Blog

Code review lesson learned

leave a comment »

So, you’ve been coding for a while and now someone ask you to review his code. In that post I would like to share few tips what I believe the code review is about. Let’s get started:

  1. Code review is about small incremental improvements
    When doing code review we should not perform detail analyze of everything we got, but instead we should focus on one area (200-400 lines) and just post 1, max 2 improvements to the existing code. The idea is to improve someone else code by small incremental steps. Better to focus on one think, discuss that and workout the best approach then spend a lot of time verifying entire change and trying to discuss number of improvements. Code review should be done ideally before each check-in of the code and shouldn’t be time consuming. The power of it lays in repeating that process over and over again and improving our coding standards slowly.
  2. This is not about blaming, showing you are better
    Code review process is about improvement and learning from each other. What team has to heavily avoid is trying to show up, point someone else mistakes or use it as kind of verification process how good developers are. If you go that path then you can be sure that this is the shortest way to kill all goodness around code review process.
  3. It is not only about skills
    Some people tend to assign only skilled developers to do code review and do not let all junior developers to be a reviewer. I would say this is really bad practice. Code review should be done by all team members and I believe that junior developers can also bring a lot of good ideas. Junior developers do not have years of practice of coding and by this they can find bright and simple solution to complex problems and by this simplify our code.
  4. What about communication
    Doing code reviews I found that it also improve communication as it give opportunities for team members to discuss different approaches they use to solve problems. On the daily bases developers tend to stick to their computers and do not talk too much. They rather get assigned to tasks and once they figure out how they want to code it then they start and do the typing part. Code review process force them to start talking with other team members about how they solve particular problems and why they did that this way. That is a great opportunity to improve communication in the team and that in my opinion is one of the critical factors in successful projects.
  5. Share and promote good solution
    When reviewing someone code we often find brilliant solution and I believe we shouldn’t just go by, but instead we should let the author know about that or even share this with rest of the team. We all want to be seen and shy – let’s promote that and the good will come back to us at some point too. That improve team morale and make us all eager to improve even more.
  6. Meet from time to time and sum-up all findings 
    When doing that ensure that things you will discuss will not be personal and will not insult any particular team member. Remember code review is about improving and not blaming. There is thin line between two and you don’t want to cross it. What to pick-up for those meetings : best things are common mistakes share by all team members or you can just have a discussion how to improve your code readability. Make a note from that meeting, share with everyone and this could be a good starting point for your next review.
  7. Simplicity is the key
    Often people ask me : how should I decide if something is a good solution to a problem or not. My answer is : maintenance/simplicity. The solution you are building is going to last for a while and for sure you as a team will have to maintain it for a while. In that case good readability and simplicity are key factors to ensure you have easily maintainable code. So, next time you are not sure then ask yourself a question: will I understand that code 6 months from now ?
  8. Never go too emotional
    Never become to emotional about the code you are reviewing. Everyone of us make mistakes or have bad practices. That is something we get as humans by default. When looking at someone code we should focus on how we can help that particular person to be better, to improve. If we switch to blame mode, then you can be sure that author of the code will go deference and will not take any lesson from you. This will make your time wasted and come on = we have just one life to live
  9. Don’t focus on how you will design it 
    You need to keep in mind that you are reviewer of the code and not someone who solve that problem from the scratches. That in particular is really hard to learn. Focus on design of the code, not particular solution and the way you will do it.

Those above points in my believe are key factors to ensure that code review process can work for you and your team. If you find some time then I strongly recommend to watch “Lessons from Real World .NET Code Reviews” course done by @Shawn Wildermuth on @Pluralsight.

Advertisements

Written by Mariusz Gorzoch

25 July 2014 at 12:27

Posted in Bez kategorii

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: