Saturday, March 12, 2005

Learn Bad Code

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.

 

3 comments:

Anonymous said...

Sure looks complicated to me
Rusty, Glad you added annonymous
to your list before I could not post a comment that is the way Harry's is. unless you are a blogget you can't post.

Granddad Kelly

Anonymous said...

Rusty, something came to my mind about this bad code. I heard that bank tellers are only shown good bills and not bad ones, the reason being that then a phony stands our right away. If they look a a lot of phonies before long they look ok. Could be the same way with bad code.
love, Granddad kelly

Russ said...

Granddad,

You are exactly right. When you know how it is suppose to look, when it doesn't look right it stands out right away. Just like Dad can walk through a job site and see if the that the wall studs aren't 16 inches on center. It's because you've seen the good one so much the bad one sticks out.

There are new security models that computer companies, called a positive security model. Instead of trying to block all of the bad attacks, it only allows the good requests. While a very simple concept it is amazing how much easier it is to secure something with that mindset. It's so much easier to write 10 rules for what the application can do, then to write thousands of rules for what it can't do.

Which is kind of the same thing.