Friday, September 4, 2009

Design anti-patterns

I have not had so much fun for some time.
If you know what are design patterns - take some time to read through the document, I am sure you'll notice many wel-known real-life examples of this.

That's where life meets theory:


Dmitriy Nagirnyak said...

Good ones!
I love the appropriate names of the patterns! They really show the actual counterparts but for a real-life :)

I found the 1.1 (difficult to test and maintain) to be a real issue.

I would say 1.2 (Blinder) is sometimes not an issue. Remember YAGNI? But of course if the thing is obvious and we refuse to see implicit the extensibility requirement then of course it is an issue.

The 1.3 (Fallacy Method) should never ever be written without a test. This brings us to back to 1.1 and 1.2 :)

1.4 ProtoTry - is really so close to the life. Hurts to tears.

1.5. Simpleton - I like this: "The art of transforming an easy thing in a difficult through an unnecessary procedure. [Fabio Maulo]" :)

2.1-2.2. classical sample of Project.Utils/Common package that serves the purpose of a rubbish bin to drop code from the whole team :)

2.3. Compromise - LOL :) So true!

2.4. Detonator - can be found in every project. Hopefully not in NASA ones :)

2.5. Fromage - ohhh. Look at the cross-brower support :)

2.6. Flypaper - typical corporate thing :)

3.1. Chain of Possibilities - typical OSS project :)... Typical stuff in "code styling is non-enforced" environment :)

3.2. Commando - heh, this sounds like a candidate for a freelance dev :) Or million of companies that "design" web sites.

3.7. - Ohh. That is a freaking paing, in corporates of course and/or outsourced projects :)

Hey, mate. This is really fun... with tears in the eyes :)

Alexander said...

Yeah, I really felt many of them pretty close to reality...
Especially, when product is migrating from one mgmt model to another or one technological base to other.

Especially - I HATE LEGACY CODE!