Flylib.com

Books Software

 
 
 

- page 34

for RuBoard

Summary

In this chapter we discussed common design elementsidioms and patternsin Transact-SQL code. You learned about the importance of taking idiomatic , or natural, approaches to building software. Hopefully, you came to understand that deviating from established conventions and straightforward approaches comes at a costincreased program complexityand that you should avoid it when you can. You learned about some of the idioms and design patterns commonly used in Transact-SQL and the differences between idioms and patterns.

for RuBoard
for RuBoard

Chapter 4. Source Code Management

I'm not a great programmer, I'm just a good programmer with great habits.

Kent Beck [1]

[1] Fowler, Martin. Refactoring:Improving the Design of Existing Code . Reading, MA:Addison-Wesley, 1999. Page 57.

I've placed this chapter as early as I have in the book because I think it's crucial to adopt good source code management habits if you're going to develop robust code for complex projects. Successfully building a sophisticated system with faulty code management practices in place is about as likely as building a space ship in a junkyard: Although it's theoretically possible, it's not very likely (Andy Griffith's Salvage I notwithstanding).

There's a tendency among Transact -SQL developers, especially inexperienced ones, to treat Transact-SQL code as though it's not "real" source code. They don't edit it with a decent editor. They're content to work eight hours a day in a tool that's more suited to editing batch files than program code. They don't comment their code or follow any of the standard conventions you might see with other types of programming languages. And they don't "version control" their code. They don't use source code management tools such as VSS, PVCS, or Source Integrity (Vertical Sky Software Manager) to manage their Transact-SQL source code.

Instead, stored procedure code is viewed as more of a database resource than program code, and is therefore managed in the atomic, transactional manner that other types of database objects normally are. From this perspective, Transact-SQL procedural code is just data. After all, it resides in the database in a table named syscomments, and it is protected from corruption via backups just like other data. So the thinking goes.

The purpose of this chapter is to refute the myth that Transact-SQL code is not "real" source code and to establish the value of source code management (a.k.a. version control) software in working with it. Although you could use virtually any text file-based version control or source code management system to control your code, this chapter covers VSS because it's the one I use.

for RuBoard
for RuBoard

The Benefits of Source Code Management

I suppose I should begin this discussion by talking about the benefits of storing your Transact-SQL code in a version control or source code management system. Some of these benefits aren't immediately obvious, so it's instructive to go through a few of them.

First and foremost, version controlling your code allows you to roll back to a previous version should you discover a bug or decide to scrap a code branch you've started. Because every version you've checked into the system is readily available, accessing a previous one is easy.

Second, version control systems usually provide difference-checking facilities. These are invaluable. When you've discovered a newly introduced coding problem and want to know what's causing it, you can check the differences between the broken version and the last one that worked, and usually find your problem. VSS has a visual difference-checking tool that places the two files side by side on the screen and highlights their differences.

Third, version control systems ensure version consistency. As you develop software and release products, your software will naturally begin to be categorized by version. Say that you discover six months after the release of a given product version that you need to compile that specific version again. Your version control system's ability to label versions and to retrieve a complete version in one step makes this a snap. You simply find the version with the label you want and instruct the system to retrieve it for you. Think about how complex this process would be without the assistance of a version control system. Once you located what you believed were the old version's source files, you'd have to check each oneperhaps hundreds or even thousands of themand attempt to ensure that not only were they from the right version of the application, but also from the same version. And this assumes that you retained the old version's source code in the first place. In essence, you'd be forced to become a human version control system. Rather than creating software, you'd spend a fair amount of your time doing things better left to computers.

Fourth, source code management systems help protect source code from accidental loss or destruction. Because the source code is typically stored in a central repository (a database of some type), it's easy to back up and much easier to manage than hundreds or thousands of files scattered across the desktop machines of a development team.

Fifth, version control systems make change management much easier. Because those who change code must check it out before changing it and must check it back in before those changes take effect, it's easy to track who's changing what in the source code. If a change was ill advised or detrimental to the application, it can be easily rolled back. If a change necessitates an explanation or comments that further detail its purpose and scope, these can be included when the file is checked back into the system. Because changes to a given source code element can only be made by one developer at a time, version control systems prevent developers from accidentally overwriting one another's changes. In short, good source code management systems help manage source code. They elevate source code management from the equivalent of a messy desk to a well-organized filing cabinet that can support the development of complex projects.

NOTE

As I write this, a new generation of version control systems is on the horizon that changes the dynamics of source code management in important ways. These new systems handle change management and other source code management duties in ways that are more conducive to large programming teams . For example, one feature that's increasingly being touted is the support for simultaneous changes to a single source code file by multiple developers. In this scenario, the version control system performs a three-way (or n -way) difference check and resolves conflicts between different versions of the same member. Obviously, this could be a real boon to large teams with large source code files. With traditional version control systems, changes to a given source code fileeven independent and unrelated changesare precluded as long as someone else has the file checked out. It's not uncommon for a developer on a large team to spend a measurable amount of time asking people to check in a code member so that he can proceed with his work. As I've said, this chapter covers source code management from the perspective of more traditional tools such as VSS, but this new generation of tools is worth keeping an eye on.


for RuBoard