8 February 2017, by Harry Cummings
This is part of a series of blog posts on code reviews, based on two sessions of an internal discussion forum at Softwire. See the first post in this series for more information. In this post, we’ll discuss improving the interaction between the reviewer and the recipient of the review (i.e. the developer).
How do we mediate reviews?
There are all sorts of ways to mediate a review:
- Specialist review tools like Crucible and UpSource
- Repository systems with review features, like GitHub, GitLab, and Gerrit
- Sending diffs/patches over email
- Talking through the code face-to-face, e.g.
- Have the reviewer sit with the developer at their computer
- Reviewing code as a team around a big screen
- The old-fashioned way: Print out the code, stick it to the wall, and scribble over it together
- Pair-programming is arguably a form of code review, taking place as the code is written
Broadly speaking, all of the above approaches fall into two categories: asynchronous online reviews, or in-person reviews. Which kind of approach people preferred was probably the most contentious part of our discussions at Softwire. There was a range of opinions here, highlighting benefits and drawbacks to each approach.
Asynchronous online reviews vs. in-person reviews
Several people made the point that in-person reviews can be more useful for training, and for knowledge sharing in both directions. Face-to-face discussions make it easier to provide context around the code changes. They also give the developer a chance to talk the reviewer through the changes in a sensible order, or perhaps commit-by-commit. This might be better than the arbitrary order in which changes are presented by a diff/patch or an online review tool.
In-person reviews may also provide opportunities to pick up other context that might not be directly relevant to the code quality but is useful for the reviewer to know. For example, any frustrating obstacles the developer encountered while working on the task, which the team might need to address. Reviewing in-person can also save developers from context-switching. If you have enough reviewers on a team, developers can get a review as soon as they finish their code rather than starting on another task and subsequently switching back to deal with review feedback. This obviously comes at the cost of the reviewers having to make themselves highly interruptable though.
A lot of the literature on code reviews also favours some kind of in-person reviews. Here’s one particularly strongly stated example:
“Effective code reviews are not done via a tool or remotely—they are done when you’re sitting side-by-side with the person or pair who just wrote the code. This personal way allows you to share and teach much more information than you can pass in a text-based tool. Don’t skimp on this! If you’re going to do code reviews because your code sucks, do them right.” – Roy Osherove in Notes to a Software Team Leader
On the other hand, some of our reviewers felt that asynchronous online reviews were better partly because they don’t provide the reviewer any additional context. Online reviews arguably make for a more authentic review of maintainability (future developers on the project probably won’t have the luxury of talking through the code with the original developer). Also, coming at the review from their own angle might allow the reviewer to spot issues that the developer has missed.
One major advantage of online tools is that they leave a permanent record of review comments. Some tooling combinations make it particularly easy to go back through old reviews (for example, Crucible with JIRA integration). Several people had worked on projects where they had benefited from the ability to do this.
Several people found it useful to mix online and in-person approaches, perhaps depending on the nature of the change. For example:
- Performing a high-level review in isolation first, then talking through with the developer for context, before finally performing a line-by-line review online.
- Saving face-to-face reviews for bigger or more complex changes
- Carrying out most of the review discussion in person, but using an online tool to track this. That is, initiating the review process and documenting any important outcomes of the discussion.
Reviewers: Making code reviews better for the developer
Quite a few people found phrasing review comments to be a challenge, especially when using online review tools. Some of our reviewers were concerned whether we did enough to make new-starters comfortable with the process, and to make it clear that they can and should challenge their reviewers. After all, the developer is always closest to the code and knows it best. It can be worth a reviewer (particularly one in a more senior position) reminding the developer of this explicitly.
Ways to make reviews more positive included:
- Phrasing review comments as questions or suggestions rather than statements
- Talking through major issues in person rather than writing lengthy review comments
- Talking through and fixing batches of very minor issues in person, rather than writing lots of tiny review comments
- Remembering to always make some positive comments (especially in reviews with some criticisms elsewhere)
This might be more or less important depending on the developer. Generally, reviewers should be conscious of the recipient of the code review and tailor things to them. Extra tact may be required when reviewing code from external third parties, which can be politically awkward.
Developers: Making code reviews better for the reviewer
This wasn’t a question we had set out to answer with our discussion. However, people naturally mentioned how they approached submitting their own work for review, and several common points arose:
- Performing their own review of the changes first (ideally in the same review tool the reviewer will be using)
- Linking to any relevant context (e.g. the relevant ticket in the project’s issue tracker)
- Keeping auto-generated files out of the review (if appropriate and the review tool allows)
- Splitting into sensible commits
- Especially keeping big renames, file moves, or other refactorings separate
- Also splitting code changes across multiple commits where appropriate)
- On one project, we experimented with commiting and reviewing one test at a time, resulting in many small reviews. On a small team, this turned out to be a very effective workflow.
As we saw in the previous post, there are many different valid approaches to code reviews. Organisations should give teams the flexibility to choose a code review process that meets their needs. The first post in this series covered the wide and varied benefits of code reviews. As a team, you should reflect on your code review process, considering what value it provides and what further value it could provide. This will allow you to evolve your code review process to be more effective. I hope this series gives you some ideas that you find useful. Please feel free to share your own ideas on code reviews in the comments below.
1 February 2017, by Harry Cummings
This is part of a series of blog posts on code reviews, based on two sessions of an internal discussion forum at Softwire. See the first post in this series for more information. In this post, we’ll cover some of our current approaches to code reviews.
We tend to at least implicitly perform code reviews in multiple passes. These break down into three stages:
- “Outside-in” preliminary review
- Reading through the original user story or defect
- Reviewing the design
- Checking out the dev branch and doing some cursory testing (this can be useful for reviewing UI issues or things that are hard to spot from the code or by automated tests)
- Reviewing the tests at a high level (do they function as good developer documentation for the code)
- Review of the code itself and the tests in detail
- Review of any activities surrounding the code change, e.g.:
- Manual testing
- External documentation
- Risk/impact assessment
Note that not every project needs all of these passes. The point is that “code review” is a broad term covering a range of activities. Which activities you carry out, and when, may vary by project. Although within each project, there’s a lot of value in being consistent. Consistency helps developers become comfortable with the review process, and makes code reviews a much more reliable tool for quality assurance.
When do we review
As noted above, different code review activities may be carried out at different times. There was a general consensus in our discussions that reviewing earlier is preferable. Most projects insisted on at least some form of review before commit, although a few relaxed this in special cases (depending on the type of project) to avoid becoming a bottleneck.
About half our teams are actively performing up-front High-Level Design reviews. These can be useful for everyone but especially for less experienced developers (which might just mean less experience with the particular project). They encourage working through design issues up front, avoiding wasted time at the implementation stage. It also means the code reviews can then focus on just the code. The only problem mentioned with HLD reviews was that it can be a bit unclear what we mean by an HLD, and sometimes people go too low-level. For projects broken up into well-sized tasks, an HLD could just be a couple of sentences and a few bullet points.
An alternative to up-front HLD reviews is reviewing roughly implemented code, essentially a spike or proof-of-concept. This can be particularly useful on tricky legacy codebases, where it might be hard to see how to go about introducing new functionality.
Who carries out reviews?
Most of the people in our discussions were their team’s technical lead. Unsurprisingly, tech leads were doing reviews themselves, but there was a lot of support for reviews being done by not only the tech lead. Getting more people involved in the review process is a good way to build people’s confidence, share knowledge within the team, and help people become more comfortable with the review process. One person doing all the reviews can also become a bottleneck and slow the team down. Perhaps more importantly, giving developers the autonomy to carry out genuine peer reviews is a show of faith in the team’s ability, and makes it easier for reviews to act as a positive motivator.
One problem with having multiple people involved in reviewing is that it can become confusing for developers. It’s not always clear how to pick an initial reviewer, or when a review would be considered “done”. It’s important for each team to agree on a consistent approach, although approaches can of course vary between teams. Most of our teams use one of the following approaches:
- Let the developer choose the initial reviewer and allow the developer or the reviewer escalate to the tech lead if needed
- Have a high-level second line review as part of the standard review process
- Include the tech lead on every review, but allow developers to merge their changes as soon as at least one person has reviewed it. This prevents the tech lead becoming a bottleneck but still gives them a chance to go into detail on any red flags.
All the above approaches include the possibility of the tech lead acting as a second line reviewer. Our tech leads would go into more or less detail in their review based on the nature of the change and the experience of the other people involved (i.e. the original developer and reviewer). In some cases perhaps just reviewing the comments from the first-line reviewer and/or looking out for changes within common problem areas of the codebase.
How much detail to go into in a second line review is a matter of judgement and may not be obvious. It can help to think of the goal of reviewing as gaining trust that the code is up to standard, and getting involved enough to meet this goal. Of course, it’s still worth bearing in mind the importance of code reviews for training and mentoring. A second-line reviewer may be looking out for learning opportunities for both the developer and the initial reviewer. They’re also in a position to assess the quality of the interaction between these two roles. This will be the subject of the next post.
25 January 2017, by Harry Cummings
There is a lot of writing on the importance of code reviews and how to go about them at a low-level (i.e. what to look for in the code). This series of posts takes a higher-level look at how to approach code reviews and how to maximise their benefits. We’ll also refer throughout to other useful writing on code reviewing and how to make the most of it.
At Softwire, we have always carried out code reviews in one form or another. But our methods and tooling have evolved over time, and often varied between projects. This allows each project team to find a way of working that best suits them.
We recently ran couple of internal lunchtime discussion forums to talk about code reviewing and pool our collective experience. The goal here wasn’t to try and agree on “one true code review methodology”, but just to share ideas between teams. We discussed the perceived benefits and overall aims of code review, and how we go about achieving these.
It turned out that the approaches to code reviews within the company are even more varied than I’d thought. But there was some broad consensus on the benefits and aims of code reviews. However, the benefits that we valued most may surprise you.
What value do we get from code reviews?
Both of our discussions came up with a similar consensus on the range of benefits provided by code reviews. In rough order of their prominence in the discussions, these were:
- Training and mentoring
- In fact, several people felt that the healthiest approach to code reviewing was to treat it as a training opportunity first
- Knowledge sharing
- In both directions (i.e. both the developer and the reviewer had opportunities to learn from one another)
- This includes sharing domain knowledge, general technical knowledge, and knowledge of the specific codebase
- Encouraging people to produce better work (knowing that it will be scrutinised by your peers)
- Keeping the codebase consistent, in terms of style and structure
- More generally, keeping the codebase maintainable
- Catching defects, or at least catching them earlier (and so making them cheaper to fix)
One point I found interesting here was that “catching defects” was one of the last points to come up, in both discussions. There was a lot more emphasis on the holistic benefits of code review: training, knowledge sharing, and improving the overall codebase.
Quality assurance is the main focus of some widely-referenced sources on code reviewing. For example, Jeff Atwood’s blog post Code Reviews: Just Do It, and the two books that it references (Peer Reviews in Software and Code Complete). These mainly focus on reducing errors/defects/bugs, and only briefly mention other benefits. Of course, improving defect detection is not a bad argument for doing code reviews. Perhaps it’s also the most persuasive one in organisations that don’t have a history of doing code reviews and are reluctant to let people start spending time on it.
Defect detection is a valuable and somewhat measurable benefit, which may make it a good angle to sell the idea of doing code reviews at all. However, for the developers and tech leads who actually carry out code review, it doesn’t need to be the only aim or even the primary aim of the exercise. So how do we go about code reviews at Softwire? We’ll cover this in the next post.
5 September 2016, by Harry Cummings
On Monday 13th June, I worked with an organisation called The Conservation Volunteers at one of their sites near Harringay Green Lanes. They do all sorts of work all over London (and in fact have groups over the rest of the country too), so it’s really easy to find something to join in with on their website.
We were working at Railway Fields, a small conservation area tucked away behind Finsbury Park. I’d never come across it before, but it was obviously well used by locals, with lots of families with small children passing through during the day. It was nice to discover another little green space like this in London.
26 November 2013, by Harry Cummings
What are Guilds?
At Softwire, we’re always keen to learn from others, but it can be difficult to apply lessons from elsewhere in the software industry that we come across at conferences, in literature and online; because much of the wisdom on best practices in our field seems to be aimed at product companies or in-house enterprise development teams. As a services company, we have a very different structure and different commercial pressures.
However, sometimes lessons from other companies really resonate with us. One example of this was the article on Scaling Agile at Spotify, which Camille posted to our internal blog. Much of it seemed relevant to us, especially as we’d grown in the last few years from a small business to a medium-sized one, while trying to retain for ourselves the benefits of working in a small company environment.
There are a lot of great ideas in Spotify’s structure, but the concept of guilds stood out particularly. Guilds are described in the above article as “… a more organic and wide-reaching ‘community of interest’, a group of people that want to share knowledge, tools, code, and practices”. Something about the idea of a guild as a group of particularly enthusiastic people also reminded us of a phrase in Kevlin Henney’s keynote at DevWeek earlier this year: “we are fanatics for testing” – this struck a chord with us at Softwire!
19 December 2012, by Harry Cummings
I read a few books on game development for a hobby project. Here are some brief reviews.
A Theory of Fun for Game Design (Raph Koster)
This was quite a short book with some interesting ideas. It generally talked about the importance of games as an educational and social tool. It made some arguments about how games are really quite fundamental to human behaviour and a bit of an undiscovered country in terms of our understanding of them. It was a good read, but I’m not sure how useful it was for the exercise of actually designing a game.
7 December 2012, by Harry Cummings
There are plenty of Java books out there, and I’ve read quite a few of them! Here are some of the ones I found most useful:
Effective Java (Joshua Bloch)
This book is definitely worth a read if you want to make good use of Java. It’s not a manual for the language in the manner of the ‘in a Nutshell’ books or Core Java (below). Compared to these kinds of books, it concerns itself with “why”s rather than “how”s, seems to sink in better, and is surprisingly concise. There is a great deal more useful, memorable content in its 300-odd pages than in many programming books that are twice as long.
Recommended chapters: All of them (it’s very good and not a very big book)
12 July 2012, by Harry Cummings
This post is the third in a series on code generation on the .NET platform. In this post, we will look at how to package a code generator as a Visual Studio extension, and how best to share a single library between multiple extensions.
5 July 2012, by Harry Cummings
This post is the second in a series on code generation on the .NET platform. In this post, we will take a closer look at Microsoft’s Community Technology Preview of ‘Roslyn’. In brief, this is a C# compiler implemented in managed code that exposes an API to let you hook into the compilation process.
In the previous post, I introduced Roslyn as an interesting tool for code generation, in particular when generating source code from other source code. Roslyn is especially appealing for this purpose because it provides a strongly-typed model for working with source code and (unlike most code generation approaches) allows you to use the same model for both input and output.
One of the common drawbacks of most other options for code generation (as discussed in the previous post) is the need to translate from one model to another and how clumsy this can be, particularly when you want to carry across some elements of the input source code without changing them. A detailed example of when you might need to do this is discussed in the appendix at the end of this post. (more…)
28 June 2012, by Harry Cummings
This post is the first in a series on code generation on the .NET platform. This is a huge subject area and there are a bewildering number of relevant libraries and tools that are useful for this purpose. I will make an effort to mention the most important third-party options (particularly where they’ve pre-empted Microsoft’s efforts), and may revisit some of them in future posts. However, for this series I will focus on those libraries and tools that are part of the .NET framework itself, or will be included in future versions. In particular, I’ll explore building code generation tools using Microsoft’s in-development compiler-as-a-service project, code-named “Roslyn“.
In this post I’ll briefly discuss what we mean by code generation, before going through some of the current tools and libraries for code generation in .NET, along with their shortcomings. I’ll also introduce Roslyn and explain why it initially caught my interest as a potentially useful library for code generation. Subsequent posts in this series will cover what I learned about using Roslyn and creating Visual Studio extensions, by looking at a specific WCF-related code generation scenario.