Geeks With Blogs

News For all those who are interested, the .NET User Group Meetings here in Winnipeg are starting up again next Thursday, check out Winnipeg's .Net user group Home Page for details.
Evil Dev's Blog Plots, Schemes, and Plans to take over the Devleoper world.... Mu hahahaha
This is a topic that has been beaten to death. I know it, you know it, but I'm still going to give my version of it, just because I can.

One thing I'm going to try to do different from every other "implementation" of this topic, as actually make it practical. It's great that for good design you should follow <insert design pattern of choice here>. And for the crowd that's going to comeback with "The design pattern isn't as important, so long as your code follows the SOLID Principals", well, what exactly does that entail?

One thing I like to do every once in a while, is just sit down, relax, and imagine myself in the third person. As if I was watching my life on YouTube. Yeah, I know it's silly, but it's really something I think a lot of people need to do more often. Your probably thinking, what does this have to do with the idea of "Good Architect, Bad Architect", well before I get into that, I'll explain a little more as to why I do this.

Sometimes, you need a different outside perspective on things, you need to "see the forest" inspite of the trees. By trying to see things from the outside looking in, it helps me grab a different perspective on things.

I try to apply the same philosophy to whatever I'm developing. Even when I see a clear path through the application, a simple pattern to whatever I'm building, I try to give myself a new perspective. Because what is obvious to me, could be Chinese to the next person who has to look at it.

So, now to the point of my post, what is Good Architecture? Well, I don't care what your pattern of choice is, and I don't care what tools you decide to use in your application. A good Architect should try to see their code from a different perspective. For example, the experienced developer on the team may know the framework he/she is using inside and out, and when they design their code, even on something simple, they dive in, code it, test it, it works, great. They will stop, refactor a bit to make the code "pretty" and say "K, it's done, deploy".

I'm going to take the time now to give you an example of such a scenario. I came across this at work, and as such I'm not going to name any names, nor any direct references. If your reading this, and you know who/what I'm talking about, please keep it to yourself, the idea behind this post is to prove a point, not to point fingers.

Recently, I had one of the newer developers on my team, ask me for help on a task he was assigned, it was a simple enough task, make some tweaks to the system, to have it clear some text boxes on a website after a search was complete. When we dug into the code a bit, we came upon the engine driving this particular feature, being client side it was all being done with javascript.

At first glance, it was an impressive piece of code, the developer had done an excellent job of abstracting a 3rd party api, into a rather pretty javascript object. It was really clean code. I'm thinking great, finally a nice piece of code to dig through. But as we got deeper within the code, to find where we needed to make the change, I noticed something that was really throwing my team mate off. Within the code of the wrapper class, the developer of this particular chunk of code, was making some heavy use of the prototype javascript library. I don't know if your a web developer, or just reading this blog, but the prototype javascript library is a very well known javascript library. It's powerful, and abstracts away a lot of the headache of dealing with cross browser "fun". So, again, this is good practise, but, the code itself was writen, single letter variables passed to these internal functions, etc. I'm very familiar with prototype, having used it a lot in previous projects I've been part of, so I kind of got the just of what he was doing without much effort. But there's no documentation, and in places, single letter variable names (and not even obvious letters chosen) and it's didn't take me long to understand the delima of my team mate.

The point of that story, is just because you have the experience, and know-how to come up with an elegant design, simply taking the time to properly name his variables probably would have made the difference between the new guy being completely lost, and needing to get help, and the same new dev being able to catch on right away, and dive into his code.

I'm a big advocate for documenting code. No matter how clever you feel your design, somebody's not gonna understand it, and if it takes too much effort to understand your code, there is a good chance they won't touch it unless they have to, opting for writing the feature they need separately, and overtime, bloating and complicating the code, and compounding the initial problem until it's a big mess.

So, plan your code for the audience you expect will need to maintain it. If you know beyond a reasonable doubt it will likely be used differently in the future, plan the required components to be re-usable. Keep your code a simple as possible, you don't need an multi-teired enterprise class design on a sitelet that's going to be up for 3 months, and DOCUMENT your code, especially in areas you know won't be easily understood by anyone but you. Oh, and name variables so you know what they are.

That's my take. Posted on Thursday, September 10, 2009 7:31 PM .NET Development | Back to top


Comments on this post: Good Architect, Bad Architect

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Mitchell Lee | Powered by: GeeksWithBlogs.net