Coding Standards Redux
I complained today about having to work on two web projects where there are now not one or two, but FOUR separate generic SQL Server Data Access classes, all of which do essentially the same thing!
They all do it differently, because individual developers have taken it upon themselves to "roll their own" without consulting with the team about best-practices coding standards and what we already may have, or not have, to work with.
In addition, developers have "cobbled in" references to things like Anthem.NET, a WAV COM Library, and other dependencies into these Data Access assemblies that have NO BUSINESS being in a generic data access class.
When I worked at a banking software firm back in early 2001, doing our first big .NET project, we had 17 developers in two teams working together. We all sat down in the conference room at the beginning and argued, and we all agreed to use the "SqlHelper" class from the Microsoft Data Access Application Blocks sample code for our basic "talk to SQL Server" needs. We chose it because it (at least, at that time) exemplified one of the most important fundamental principles of framework design: it had been constructed by focusing on a set of common usage scenarios to enable power and expressiveness, and especially, ease of use. The learning curve, even for beginners, was fast, the class was well-documented, and it offered features (such as automatic static caching of SqlParameters) that I wouldn't have thought of.
I cannot describe how much easier that made things. Everybody was doing Sql calls the same way; you always knew exactly what their code was doing, and you never had to look for assemblies that you had missing references to, because THERE WAS ONLY ONE.
Now if you wanted to build a specialized DAL, you could still have it use the SqlHelper class under the hood for your basic data access, and so you weren't restricted in any way. It saved us literally dozens of hours of developer time and, you know what? I still use it today (even the more advance Provider model version) - five years later.
But -- It doesn't have to be "SqlHelper" - it can be any basic data access class you want. The point is, it should be the same for everybody, and if it needs to be able to do something new, then everybody should get together on that before making the change. And the framework should be designed properly. If you want to study good framework design basics for class libraries, a good place to start is Framework Design Guidelines by Krzystof Cwalina and Brad Abrams.
Man, I hate to sound like a broken record, but really - this is such basic stuff, it just blows me away how people don't seem to think that this is important. It's VERY IMPORTANT! We do not do our development in "a vacuum" -- even if we are the only developer on a project. Other people have to be able to use our code!
They all do it differently, because individual developers have taken it upon themselves to "roll their own" without consulting with the team about best-practices coding standards and what we already may have, or not have, to work with.
In addition, developers have "cobbled in" references to things like Anthem.NET, a WAV COM Library, and other dependencies into these Data Access assemblies that have NO BUSINESS being in a generic data access class.
When I worked at a banking software firm back in early 2001, doing our first big .NET project, we had 17 developers in two teams working together. We all sat down in the conference room at the beginning and argued, and we all agreed to use the "SqlHelper" class from the Microsoft Data Access Application Blocks sample code for our basic "talk to SQL Server" needs. We chose it because it (at least, at that time) exemplified one of the most important fundamental principles of framework design: it had been constructed by focusing on a set of common usage scenarios to enable power and expressiveness, and especially, ease of use. The learning curve, even for beginners, was fast, the class was well-documented, and it offered features (such as automatic static caching of SqlParameters) that I wouldn't have thought of.
I cannot describe how much easier that made things. Everybody was doing Sql calls the same way; you always knew exactly what their code was doing, and you never had to look for assemblies that you had missing references to, because THERE WAS ONLY ONE.
Now if you wanted to build a specialized DAL, you could still have it use the SqlHelper class under the hood for your basic data access, and so you weren't restricted in any way. It saved us literally dozens of hours of developer time and, you know what? I still use it today (even the more advance Provider model version) - five years later.
But -- It doesn't have to be "SqlHelper" - it can be any basic data access class you want. The point is, it should be the same for everybody, and if it needs to be able to do something new, then everybody should get together on that before making the change. And the framework should be designed properly. If you want to study good framework design basics for class libraries, a good place to start is Framework Design Guidelines by Krzystof Cwalina and Brad Abrams.
Man, I hate to sound like a broken record, but really - this is such basic stuff, it just blows me away how people don't seem to think that this is important. It's VERY IMPORTANT! We do not do our development in "a vacuum" -- even if we are the only developer on a project. Other people have to be able to use our code!
Yes and your comment is an example of what I was talking about in the previous post just below- you are using a comment to complain about something that has nothing to do with the subject of this post. Its as if you didn't even read it - you just want a platform to complain. My UnBlog is also a sandbox for my "experiments" so if it doesn't render properly in Firefox right now, or you don't like the window layout, try to get over it.
ReplyDeleteCheers, Michael.
Back in the days of com +, Microsoft evangelized n-tier architecture and naming conventions and best practices. These days, the unnavigable MSDN has a motley assortment of examples that provide zero leadership for those who would like to follow coding standards. I wonder what guys like steve mcconnell think of the current state of .net development. I'd love to form a consulting company that leads by example and sets such a strong example that we become the end all be all of coding standards in this new microsoft era. Standards were much tighter in the days of com + and there is no reason why we can't look to those days to inspire those of us who still care about creating beautiful applications.
ReplyDelete