Code review — The good, the bad and the better

  • Maintain a specified and agreed upon quality standard in respect to the code base
  • Create or maintain a sufficient shared (technical and functional) knowledge, understanding and responsibility among team members
  • Support a dialogue among team members and beneficiaries to confirm, share and exchange ideas
  • Be subconsciously more critical of your own work
  • They (can) take (a lot of) time.
    Time to review but also more time is taken to scan your code multiple times to receive a positive review or perfect score
  • They can cause arguments and division
  • They can cause stress for the writer of the code
  • Lack of trust and feeling unsafe among team members
  • Suboptimal way of working
  • Incorrect or incomplete understanding of the purpose of reviewing someone’s code
  • Lack of experience and coaching to provide useful feedback
  • Have clear and effective coding standards (this is a whole separate topic)
    You could even talk about them when you are interviewing potential candidates. Don’t ask them to take it or leave it. But ask their opinion about some of the standards. Sometimes a fresh pair of eyes can teach you and the team something. It’s not a holy document so update it as the team sees fit.
  • Have a checklist to provide clear rules of engagement.
  • Use static analysis like SonarQube or linting plug-ins. But keep your rules up to date and provide a standard way to override some of the rules at particular places in the code.
  • Be liberal about points that are really not important for readability, usability or quality. Keep taste and feelings out of it.
  • Be forgiving and fix little things yourself and write a short note stating that you have done so and why. Be careful not to rewrite big portions of code.
  • Offer an alternative when it needs refactoring. Either in real working code or pseudo code. But don’t just say, this is unclear, rubbish, etc.
  • Start a dialogue when it concerns a functional discrepancy. Walk up to the person and talk about your findings. A great way to do this, is by asking open and honest questions. So don’t be sarcastic or rhetoric. Tip: involve the beneficiaries in this conversation to avoid theorizing and hypothesizing.
  • Write a test or perform a test when you think the code may contain a bug or pose a risk. This way, when the test confirms your suspicion you can demonstrate it clearly. When it doesn’t, then you might see why.

--

--

--

A software developer since 2008. He loves coding and everything that comes with it. From cradle to consumer and from personal development to team building.

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Demystify Builder Pattern in Scala

How to make Vapor 3 Swift Playground in Xcode 10

Algorithms In Nature [Part-1]

Episode 2 TheBotCamp.com and The Flexy List Building Method

Find your favorite artists in Spotify playlists with Python

Cover image

From Solving a Problem in Google Play to Publishing with Flutter

Getting branch name in Github Actions based on workflow trigger

CS373 Fall 2021: Fifth Blog

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Thomas Heijtink

Thomas Heijtink

A software developer since 2008. He loves coding and everything that comes with it. From cradle to consumer and from personal development to team building.

More from Medium

Are you asking these questions while running Performance tests for your software application?

London vs Chicago

My Take on Pull Requests (PRs): Are They Really Time Consuming?

What Does it Mean to Have an Elegant Solution?