I have a number of teams that today produce working code for either Blackboard or internal systems. As a development team we do a lot of classic software quality efforts as a means of producing and maintaining solid code.
Code Quality Evaluation and Metrics
I’m big fan of static code analysis. It was a huge initiative for the Performance and Security Engineering teams dating back to early 2010. Engineering then joined the counter-movement in 2011 and included it into their daily working process as part of 2012. We use a number of tools for evaluation purposes that integrate with a reporting framework called Sonar. We have legitimate executive buy-in to make SCA a major check-and-balance as part of our code quality initiatives.
In late 2012, the Release Engineering team started to play around with SCA, implementing their code projects into Sonar for evaluation purposes. The team hasn’t done much with Sonar as of yet, but I’m expecting to see an emphasis on both evaluation, code coverage and measurement.
Code Reviews are Critical
The previous topic brings me to my point about this blog. About a year ago I wrote a blog about Crucible Reviews. I felt like we had a lot of issues with Crucible Reviews. The issues varied from getting all members of the staff to participate in reviews to changing the direction and content of a code review. I was adamant then and am still adamant today that we need to train developers (new and experienced) about how to give a good code review. We need good examples. We need formulas for input. We can’t just assume that everyone knows what good feedback is all about.
Here’s a quick caption from my blog from back in 2011 in which I called out my views on Code Reviews…
|So what’s my point? Well, code reviews were considered a means to an end. The end being better coding practices and improved collaboration. I’m sure we can say that there’s anecdotal evidence that quality has improved and quite possibly code reviews were a contributing factor. Code reviews are very subjective. They have a huge dependency on human interference. They are dramatically influenced by the person giving the review, specifically the subject-matter-expertise and skill set of that individual. They are influenced by the environmental conditions impacting the reviewer. For example, what if the reviewer is rushed for time because he/she has 4 other reviews that need to be completed before the end of the day. It is common for the same person to be included on multiple reviews. I know for certain that whenever Nori’s developers are working on Course Delivery refactoring, they without a doubt always include the Course Delivery Architect (Lance) on every review. A lot of times we will have as many as 2 to 3 reviews out at any time. So it’s not that far off of an example.
Code reviews are about reading code. They should be used to verify that designs were implemented. In fact, design trace-ability should be one of the most important outcomes of a code review. In some cases, CRs can be leveraged as a way to suggest alternative approaches for implementation. We want our code manageable and should therefore be evaluated for manageability during a CR. They can be used to find bugs. They can be used for mentoring, specifically for helping someone gain experience with the code base, as well as providing a medium for sharing feedback for improving coding abilities of team members.
So What’s My Point?
All of my teams (Performance, Security, DBAs, Systems Engineering and Release Engineering) need to learn how to request a code review via Crucible and how to perform a code review in Crucible. We need to define Code Review policies and perform measurements on both the act of requesting and giving a code review, as well as the quality of content provided in a code review.
I’m looking for our team leads and managers to take this to the next level…