Most articles I have written focus on Agile Project Management techniques.? One area where agile PM?s can improve is their involvement with team engineering practices.? Without a strong, good agile presence introducing good engineering practices in your team, the agile PM must help.? You may need to set up and help the team adopt good engineering practices.? One fantastic tool for accomplishing this is the Code Review.
Agile Engineering Practices
Let?s start with what are probably considered basic engineering practices that agile teams should adopt.? Usually these practices are from the eXtreme Programming (XP) space.? Below is a listing of important XP engineering practices:
[login]
- Test Driven Development (TDD)
- Continuous Integration
- Team Rooms
- Pair Programming
- Small Releases
- Refactoring
- Collective Code Ownership
I believe most serious development shops would consider the XP practices a stepping off point.? For those shops wanting to move ahead, there is also the Software Craftsmanship manifesto.? This movement focuses specifically on making better software.? Below are the principles of this movement:
- Not only working software, but also well-crafted software
- Not only responding to change, but also steadily adding value
- Not only individuals and interactions, but also a community of professionals
- Not only customer collaboration, but also productive partnerships
?
Other good practices include loosely coupling your design, SOLID principles, which are beyond the scope of this article.? The team must keep whatever their principles for good development in mind for these code reviews.? Conducting a code review is great time to focus the team on when and if they are following these principles and good practices.
When to Conduct a Code Review
The timing of a code review should be agreed on by the team, in good agile fashion.? It makes sense to do this at least two or three times during a project, or more depending on time constraints.? There really is not a standard just make sure to do this consistently with input from the team.
If your team delivers on 2 week iterations, or sprints, then conducting the first review after 2 sprints seems like a good time.? There should be enough code to evaluate, but any issues that surface in the review can be caught quickly.? The timing also depends on your team?s maturity.? If the team is practicing Pair Programming and is a high maturity team, then code reviews need not be conducted as often as a more intermediate or new team.? Conduct code reviews with teams of any maturity, varying the frequency based on the teams maturity.?? Good reviews keep the team focused on good engineering practices, and allow teams to introduce new practices.
Who is included in the Code Review
Include the entire development team in the review.? Developers of all maturity levels need to be in on this.? Reviews allow teaching principles outside of actual head down coding, and allow the team to reinforce those principles with all team members.? Your QA folks should be included, assuming they have development tasks as well.? The team should be asking questions and providing feedback during the review.?
Conducting the Review
?If you are a team lead, Scrum master, or Project Manager who has never conducted a review, do not fear!? The code review does not have to be done totally manually!? To prepare there are tools to use before stepping into the review that can help.? In addition most technical members of teams will want to help you.? Be sure you prepare before the review, so there are few surprises with what will be found in the code.
Preparing
Code Coverage
The organization or team should have targets for some basic quality measures.? For instance, most teams will have a target of code coverage of business logic by the unit tests.? There are many tools that help with code coverage.? In the .NET space, there is nCover, Visual Studio Test and others.? The Java space includes jCover, hansel, CodeCover and others.?
Use one of these tools to show what kind of code coverage the team is achieving overall against business logic.? Code coverage should not be an end all be all final statistic.? Code Coverage should uncover issues, and raise questions.? If a piece of code has below 20% code coverage, the question needs to be asked why.? If the answer is, ?I will get to it?, then perhaps there is an issue with the Test Driven Development concept in your shop!? However, there may be a good reason, so the code coverage report should be a conversation starter, not a report card.
Architecture
This is a good time to go over architecture also.? Put together any old architecture diagrams, along with the current architecture with class libraries etc.?
Plan to go over the way your project files are organized, class library locations etc. are a good place to make sure that the current project is organized correctly.? While changes probably have been made, ensure they were made for the right reasons.?
Code Analysis
Finally, go over the code using an analysis tool before the meeting.? You will want to do the analysis in the meeting also, but use the tool before the meeting so you know where the focus of the review can start.? There are many tools to use to help with this.
In the .NET space one of the tools I would recommend is called nDepend.? Use the tool to generate reports before the meeting.? These reports should show different reports on things like cyclomatic complexity, depth of inheritance and other measures.
The Code Review
Once you have prepared for the review, it is time to conduct it.? Set up a meeting with the team, and allow an appropriate amount of time for your team to discuss issues.? The code review is an interactive meeting intended for teaching to come from the team, not a director or team lead.? All tools and preparation are meant to engender conversation.
The temperament and size of your team will help determine how long the meeting should last.? To give you an idea of where to start, here is an example team.? This team with a size of 8 developers, 1 project manager, and 1 dev manager would take 1 hour and a half to conduct their code review.? This team functioned well, and had good rapport within the team.? That may help you with your first meeting, remember to adapt after the first meeting using the results from that meeting.
Within the meeting here is a sample schedule to show what you might cover in the meeting.
1)????? Overview of Stories covered for this code review (10 minutes)
2)????? Discuss team metrics (10 minutes)
3)????? Mention special focus of review (5 minutes)
4)????? Review code in Depth (55 minutes)
a)????? Code Coverage
b)????? Architecture
c)?????? Analyis Report in depth.
5)????? Summarize and note any action items (10 minutes)
The above sample schedule is focused on reminding the team of what they are working on, what is important for software engineering practices, and then deep diving into the code.? Some teams may need to focus on a certain practice.? For instance, if my team has just adopted test driven development, the review may focus on the testing topic, including code coverage.
When discussing code coverage focus the topics on what the unit testing is covering.? Unit tests need to test both happy and unhappy paths.?? Be sure that any error trapping is being tested in these unit tests.? As a team, agree on what are some good practices for unit testing, and do some random searching on the unit tests to show what team members are coding in those tests.
Another great test is to go over cyclomatic complexity or CC.? Higher CC values can mean that methods are harder to maintain.? CC counts number of instructions like if, while, for, foreach, case, default, continue, goto, &&, ||, catch, tenary operator, ?:, ? .??? ?For maintenance, keeping these values low will help as you change the code in the future.
Another aspect to view is dependency.? The tool I use has a dependency matrix which is can show dependencies between objects.? For instance, on one project, we found some code where objects depended on each other.? This kept these objects tightly coupled to each other.? The team needs to make the decision in the review if there is a good reason for this tight coupling.? See Figure 1 for an example of what this looks like.
In the meeting, the team should be discussing these issues.? Any issue should invite conversation.? Team members need to validate that there are good reasons for doing things that the tool or observation brings out in these review sessions.? If action is needed then the person conducting the review needs to note that and create follow up items to ensure the issues are addressed.
At the end of the meeting, wrap up by going over any action items.? Also note any general trends noticed in the code review.? Make sure to notice any positive directions the team is taking in any of these practices.
You have conducted a Code Review!
Now you have the tools to conduct a code reviews with your team.? Keep in mind the code review is a tool to help teams increase their software engineering maturity.? And in the end this means delivering higher value to customers.
