I know, I haven't posted in awhile. Work has been very hetic, with big deadlines for one of the biggest projects my departments has even done. So with big deadlines looming, it is really easy to let some code that is less than perfect slip through the cracks. Less then perfect code would be something that, while it works as in it doesn't have memory leaks or anything like that, just doesn't subscribe to good design patterns and practices. So why is the post titled "Learn Bad Code". Well, you need to learn to recognize when you've written bad code. Actually it needs to bother you when you've written bad code, or are using code that someone else's. It should bother you so much that you get up in the middle of the night to fix it. How do you do that? Well there is a couple of ways.
First learn the right way to right code. Learn to use N-Tier design structures. If your application is connecting to a database, your presentation layer should have no idea what kind of database it is. It shouldn't even matter. Your should write a data layer, that takes care of all of those things, and handles the data off to the business layer in a generic way. The business layer can then pass the data to the presentation layer in a generic, or more correctly abstracted way. I'm not the first one that has ever said this, in fact most developer, well .NET, C++ and Java developer work this way.
The second way, look at bad code. Hopefully it isn't your own bad code but someone else. At work we go to http://thedailywtf.com/ everyday. Here are examples of bad code posted daily and discussed. Don't get me wrong this code works, but it works in the most convoluted way possible. The other thing that comes from reading this daily as a group is the threat factor. Yes, I have threatened people in my team with posting their bad code, and vise versa. Let's face it, none of us wants laughed at for being a lazy programmer.
Let's go back the first method for a moment. Like I said earlier, there has been a lot written on how to write a N-Tier application, I'm going give you a practical example of why. I'll start by telling you a little bit about my team at work. There are three of us, including myself. Which makes each person's role very important. We have the Front-End Web Developer, The .NET Developer and me The Senior Web Developer. Our Front-End Developer works on the User Interface, design and things like that, he is an Expert in HTML and can do amazing things with it, yet he is new to ASP.NET and .NET in general. Our .NET Developer is a back-end programmers, programmer. He does all of the Database work, the stored procedures, the data layer stuff and so on. Then there is me, I do a lot of the architecture and design, as well as writing the business logic with our .NET Developer, and Front-End design with our Front-End Web Developer. So you can see by the way the team is structure that we are set up in to an N-Tier architecture. Okay, with that being said, why, is the N-Tier important to us?
One of the reasons why a N-Tier architecture is important to us is flexibility. Let's say, hypothetically, the company decides that Oracle is the way to go and that all of our applications have to be converted to use Oracle as it's database. Of course we had written all of our appliations for Microsoft SQL. Well with the N-Tier design model, we just change our data layer (or data access layer, which ever you like to call it), and we are in business. We didn't have to change the presentation layer (web page, or windows app front end) or our business layer (business logic) to accommodate the change because we wrote the application in such a way that those two layers were abstracted from the database. Simply put, they didn't care able the database, because they never knew it was there.
Another reasons why a N-Tier architecture is important to us is knowledge. My team is really diverse in their knowledge, so I can't expect them to all know the same thing. I wouldn't expect my Front-End Developer to write stored procedures, just as I wouldn't expect my .NET Developer to create photoshop comps of web pages. With the N-Tier architecture in place, the Front-End Developer doesn't have to know ADO.NET, or SQL. He just calls the business object and can intellisense his way though the fields without having to ask about them. Adversely, my .NET Developer doesn't have to sort through the ASP.NET code to firgure out where to try and put some inline SQL. And this touches on our third reason, speed. Now with both of the Developers, (Front-End and Back-End) doing what they do best, they aren't slowed down by trying to figure out how to do each other's job. They don't have to deal with the speed bumps of code.
In the end Learning what "bad code" looks like keeps you from writing it, just as much as learning what "good code" looks like helps you write flexible applications.
