Code(?) Reviews - Just Do It! (in a better and less boring way) by Michał Ostruszka

Speaker Michał Ostruszka
Title
Code(?) Reviews - Just Do It! (in a better and less boring way)
Description

Most of the software development projects involve collaboration of team of several developers, except for these pet projects we do for ourselves. In majority of cases we work on common codebase, constantly adding great amount of new features. It is our day-to-day job to decide which way to go with design when implementing new feature, how to fix this or that bug staying aligned with general architecture concept, code quality, standards and so on.

While the above sounds great in theory, sad truth is that we are only imperfect human beings and we make mistakes. Lots of mistakes, actually: we introduce subtle bugs and gaps accidentally (even in tests), we are not able to collect and analyze all possible solutions that we could choose from to resolve given problem, we overlook implementation and requirements details etc.

Additionally, when working on a given thing, developers tend to get more and more specialized, becoming  “single point of knowledge” and dangerously lowering project’s “truck factor” . Some, but not all of these points, can be handled by (still imperfect) IDEs and other automated tools, but there is nothing as powerful as having teammates over the shoulder, helping you stay on the right track. That is why code review is so important, especially when you don’t do regular pair programming.

 

In this talk I will present benefits of code review practice, some of which are not always obvious. I will show how it maps to pair programming and if it adds any value when already doing PP. I will also answer questions, such as how to make Code Review to be effective for all parties and how to keep all participants involved. Additionally, I will describe the possible ways of having this practice work even in distributed teams, and present an example of how we try to implement code review in one of my current projects, including where it fails and what is still to improve. As an added bonus, I will explain why I don’t really like word “code” in code review (hence the question mark in the title).

Last Updated 28 Jan 09:16