In figuring out the Big OOP Kahuna, we've all come across the ubiquitious 'Design Patterns' right?
Cool, now how many times just 'knowing' about a design pattern helped us write better code, create more robust systems, create reusable, more valuable code?
In my experience, not many.
No matter how well engineered the application, how well written the code, we still have rarely profited by writing code for that very application, in terms of raw effort, if at all, our profit margins have been pretty slim.
I go from project to project coding similar applications, and its a rare instance that I am able to reuse my code with minimal effort. Even in the cases where I know a 'trick' of how to get something done, I still struggle as hard in 'implementing' it in my current situation, as I fought with the problem in the first case!
There are too many examples to count : Multi Page Printing in flash, or Depth Management in Flash, or Drag-Drop like activities in Flash. Although I know how I did it in one project, It's still hardly a 15-20% reduction in my effort, the next time I do it!
This sort of problems plague us coders every step of the way, in every project, in every product.
But, where do we miss, where is it that things go wrong?
In the quest to improve the quality of (and practice of writing) my code, I came across a significant observation, I'll quote this verbatim :
"Identifying bad practices can be as valuable as identifying good practices."
How simple was that!
With this deceptively simple little observation in place, software engineers across the world set out to document both, their smiles as the good practices, and their sins as the bad ones. [okay pathetically cheesy line, but, you do get the point, don't you.]
The good practices took the shape of Design Patterns, from starting in the completely unrelated feild of architecture (the brick and mortar kind), they spread to management practices, governance and finally in programming of digital applications, a domain where we, the coders, encounter them most often.
But, what happened to the bad practices?
As it turns out, these were documented as the "Anti-Patterns".
Their official definition is :
"An AntiPattern is a pattern that tells how to go from a problem to a bad solution."
It makes an interesting read, wading thru the Anti Patterns Catalog.
I must confess to have comitted many of these sins as listed in the catalogue :)
Look thru, how many can you recognise to have comitted? Ummm... don't tell me, hehe...
But, there's always hope, and I am trying to improve, I look at some of these anti-patterns, and try to eliminate them from my day-to-day work and from my line-to-line code.
Here are some of my favorites, not just interesting names, but, interesting lessons in software engineering too, check them out :
BTW: "Voodoo chicken" is also a slang for "a spicy chicken dish"...
ciao.
shauryashaurya
No comments:
Post a Comment