Written on 9:27:00 PM by S. Potter
On a mailing list recently someone posed a question about how to incorporate code reviews into an "agile methodology". While I had questions about the way the question was posed it got me thinking about how agile practices make code review happen more often, more organically and more transparently. Having different members of the team review code at different times during the development process on agile projects is both explicit, but also implicit.
Let us back up a little here. First off agile is at its core a set of four ideals. Prefer:
- individuals and interactions over processes and tools
- working software over complete documentation
- customer involvement over contract negotiation
- adapting to changing needs over completing a stale plan
From these ideals there are about 10 or so principles or tenets that are most commonly discussed among agile practitioners from most of the main camps. This is where it starts getting controversial as some agile camps acknowledge some of these principles and others do not necessarily, so here are just a few that I want to talk about in relation to increasing code review on agile projects:
- Collective team ownership of product: meaning everyone on the team owns the product and nobody on the team is exclusive to just one or a couple of components of the product.
- Embracing change: instead of continuing down a set path determined long ago that no longer applies, the team needs to adapt to customer's changing requirements at set (and regular) intervals (these might be called iteration planning meetings/negotiations, for example). This has various implications throughout the iteration/sprint.
- Verify expectations continuously: meaning whenever possible, without impeding development, verify that customer expectations will be satisfied and no new additions have negative impacts.
- Customers set priorities: instead of technical staff or outsourcing companies specifying technical priorities, customers specify business/feature priorities.
This is the point where we start seeing the translation into agile practices, many of while you will start to recognize:
- Pair programming which arose from both collective team ownership and embracing change tenets.
- Test-first practice came about mostly to satisfy embracing change, but also verify expectations continuously
- Assigning new stories independently of previous ones. This means that no developer or pair has a niche component or product area and is used to satisfy the first tenet listed above.
- Continuous integration that helps satisfy the verify expectations continously principle.
- No fear refactoring, which is only advisable if your test/spec suite has good enough coverage,. This means you will likely revise poorly constructed code on agile projects vs non-agile projects more often and have the chance to do it more often too.
Obviously with the pair programming practice that some agile methods promote, you have another set of eyes reviewing code as it is written. This catches errors closer to the time it was written, which is a big time (and money) saver.
Applying a test-first approach means that you start out defining custom expectations of the code first before writing the actual code. This is reviewing, perhaps not code in the traditional way, but the requirements, which in my view is even more productive usually.
When a project manager assigns new stories to a developer or a pair without confining him/her/them to specific areas of the codebase, this increasing the transparency of the codebase and exposes hidden dragons to be exposed before too long and hopefully before being launched into production (but you never know). Again this increasing the number of eye balls on parts of the codebase.
With continuous integration you can incorporate metric tools to capture some metrics of the code so that parts of the code that are obviously in need to technical refactoring get highlighted earlier rather than later. Increasing transparency of the codebase, which is always a goal of code reviews.
Hopefully you can see where I am going with this and not think about code reviews in the traditional top-down way where every month or quarter a piece of code is reviewed from each developer in a formal way.
There are a number of different agile (and common) software practices that could be used, I can think of 4 more off the top of my head that improves codebase visibility across more of the team.If you enjoyed this post Subscribe to our feed