Code Reviews At Disy – Observations

After reviewing almost all code we wrote for 18 months, completing some 1’500 reviews, we want to share some recommendations and look at things we’d like to change.
The category for posts which talk about techniques helpful in achieving and maintaining a high quality code base.
After reviewing almost all code we wrote for 18 months, completing some 1’500 reviews, we want to share some recommendations and look at things we’d like to change.
After setting out to create a peer review culture we came up with a workflow and picked a tool (yes, Crucible) that would help us get there.
At Disy we review almost all the code we write. Here, we want to share why that was not always the case and how we started with code reviews.
There are a couple of things you should do to make code reviews successful. Chief among them, keep them brief, short, and focused. This is the story of how I fucked up on all these accounts and we still made it work.
As with most things in software development the ultimate currency for comments is time. This is an analysis of the costs and benefits of comments.
To discuss the up- and downsides of comments we need to know what exactly we are talking about. Categorizing and characterizing different kinds of comments is an important preparatory step.
Matt Werner from DZone interviewed me about my stance on comments.
My rant to comment your fucking code sparked some interesting conversations. Here we discuss some of your and my thoughts on the topic of comments.
You think your code is so clean that it doesn’t need comments? Then this rant is just for you!
Anonymous classes are verbose and obfuscating. Functional implementations can oust them from their last strongholds (“almost-functional” interfaces and abstract classes).