Table of Contents
- Microsoft SQL Server Defined
- Microsoft SQL Server Features
- Microsoft SQL Server Administration
- Microsoft SQL Server Programming
- Performance Tuning
- Practical Applications
- Professional Development
- Application Architecture Assessments
- Business Intelligence
- Tips and Troubleshooting
- Additional Resources
Transact-SQL Code Reviews, Part One
Last updated Mar 28, 2003.
In larger software development groups or companies there is a often a very mature process for a “code review.” A senior developer or perhaps a peer-developer will examine the code of another developer for mistakes or to help optimize it. It’s a standard practice, and one the data professional should adopt.
The Transact-SQL code in an organization doesn’t always go through this level of scrutiny. There are many reasons — often there are only one or two data professionals on the team, or perhaps there’s no one else in the organization that has the skill to review the code of the data professional. But most often it’s a belief that “we don’t have time for that. If we stopped to look over every line of code we all write we’d never get anything done.” I certainly understand that the technical professional’s day isn’t filled with a great deal of “slack time,” but in this article I’ll try and convince you that you should take the time to follow this practice. In this tutorial I’ll explain the benefits, risks and rewards for performing even a basic code review, and in the next I’ll give you some tips on how to make it part of your standard process, and show you some practical tools and steps on performing a code review.
So what exactly is a database code review? It’s deceptively simple — it means that one technical professional looks over another professional’s Transact-SQL (T-SQL) statements. It’s deceptive in its simplicity because it’s often more difficult to actually perform the review than to explain it. I’ll show you how to break the process down into simple steps, and which of those steps you could actually leave out if you’re really that pressed for time.
A set of senior developers might review the newer data professional’s code. This is probably the best situation, since it spreads the knowledge of the senior professional around, leveraging their skills as much as possible.
The code review process can also be done by a “peer review.” In this case, the technical professionals are gauged to be roughly the same skill level. Even in this case it’s great to have another pair of eyes looking over what you’ve done. I insist on it for my code.
In another variation, you may be one of only a few (or the only) data professional in your shop. At one location I worked, the developers wrote their own T-SQL code, rather than on relying on Stored Procedures and such from the DBA team, which was much smaller. In this case, the DBA team reviewed the code of the developers. At times, this was quite painful, but as you’ll soon see the benefits outweigh the effort.
You should include this type of review not only for the code within an existing project, but when you create your database objects at the outset of the project. In fact, I find that this is one of the most important places for a code review. In a typical project that includes a database design, there is (or should be) a design review, where a team including the data professionals, developers and the business analysts look over the design of the database to ensure that it meets all of the functionality required in the requirements. But later, when the design is approved, the data professionals have to persist that design down onto physical hardware. That takes code that creates physical objects like FileGroups, files, tables, indexes and so on. Having another person ensure you’ve coded these statements up properly is essential — even if you have graphical tools do the work. In fact, if you’re using an Object-Role Modeling (ORM) or similar process to create the database, make sure you have multiple people review the scripts it creates. I’ve seen some really poor code come out of these tools lately.
The reasons you need to perform a code review, even if you feel you don’t have to, involve four main areas:
- Find and correct errors
- Foster learning
- Increase team-building
- Distribute “tribal knowledge”
The primary reason for a code review is to find and correct errors. We all make mistakes — all of us — and it helps to have someone else look over our shoulder. In fact, while I’m writing this article, I’m multi-tasking a little. I sent off something to a co-worker who pointed out a flaw in my efforts that I fixed by looking 2 pixels down in the screen. I still can’t believe I missed it — possibly due to the multi-tasking :) or just that I’m human, but we miss things. Having someone else, even at the same technical level you are, read over your code will keep you from making mistakes.
There’s an interesting side-benefit to a peer review: embarrassment. I am so embarrassed that I missed that option on the screen I’ll remember it next time, especially if I ask that person to look at my code again. While this might make you less likely to ask for a review, it shouldn’t. This kind of mental reinforcement can really help you get better at your craft.
Another purpose of the code review is to foster learning among the teams. Everybody starts somewhere — everybody doesn’t know something. Once I submitted some code where I typed a loop, and found out from a review that I should take a look at replacing it with a recursive function like a CTE. No, the senior developer didn’t come over and give me a private lesson on how to do that, but I now knew that the recursive functions existed, and that in this kind of situation I should evaluate if they make sense. I learned, got better, and the code ran better.
This becomes especially interesting in the situation where the development team’s code is reviewed by the data professional team. A developer might focus on high-level object-oriented code and not be as familiar with all of the things to know about T-SQL, so it’s a great way to teach them. In the situation I was in, we had so many changes, that I instituted a “SQL Brown Bag” lunch where the DBA team bought a pizza and did T-SQL training once a week.
And that brings up the point that a code review process can foster team-building. Before we began the brown bag sessions, there was some tension between the DBA team and the developers, since it felt a bit like having your writing edited. It’s undeniably a painful process to have your code looked at by another person, but once you get over that process, it can have the effect of introducing all of the team members together to get a sense of a single purpose — to get more error-free, optimized code out for the organization. And at the end of the day, that should be the goal.
“Tribal knowledge” is the set of information that a small number of people know because of the common situation they all live in. Sometimes this is called an “island of information”, and it can even be held by one person. Ultimately, that’s bad for the organization, and even for the person.
In the next installment, I’ll close out this topic and show you the tools you can use to do the review, the areas you need to focus on (and in what order) and some practical steps for the review.