One thing I do have to admit, and not just for Peter Ford's sake, but for my own, is that growing up in a mainframe world was quite beneficial. The rigor and thoroughness that was required was very good at helping new developers out.
When I was younger I was involved in a project that was creating some stored procedures for a database. The stored procedures were written in COBOL as the database was mainframe oriented and this was the preferred method for writing stored procedures. (We didn't have any PL/1 expertise so that and Assembler were out of the question.)
Because of the mainframe orientation we followed all of the rules that we normally did for COBOL programs. We documented changes that went in, both in the program and in the source control system we were using. This allowed anyone, at any time, to take a look at the changes that had been made to a stored procedure (COBOL program) and see how it had grown.
The same discipline, however, does not seem to be there in the non-mainframe world. Call it "freedom from the tyranny of those mainframe ..." or call it a "more relaxed development atmosphere" or whatever you will, some of the lessons learned from decades of mainframe usage and discipline are still valid in the Wintel era. One of those valuable lessons is putting comments in your code, whether that code is VB, C#, or T-SQL. Comments help identify what has changed in the script. These comments not only help when debugging issues, but could lead to identifying other issues, such as maintainability, that need to be addressed sooner, rather than later. (If the same lines of code are constantly being changed, perhaps that section should be refactored.)
Why bring this up? Well, the vast majority of SQL scripts that I see migrated through DeCo do not contain comments and, quite frankly, this worries me. If we don't know what changes we've made, how are we ever going to know what to test? How are we going to know what may or may not be working?
No comments:
Post a Comment