Patterns vs AntiPatterns

  • [アーティクル]

why is it always more important to understand AntiPatterns than Patterns ? and what are the benefits ?

I consider AntiPatterns as "hall of shame" , "Flaws in Design or Architect" "Architectures that were too dynamic(loosely coupled) for the requirements(like buying a super cell phone with 5000 features and only using 7 of them" "excellent architecture that didnt meet the requirements". all these are considered as antipatterns sources.

here i am just going to shed some light on the comparison.

1- boundaries : understanding antipatterns implies understanding the boundaries of the system. it is exactly like knowing the ceiling and the ground of the system.what you shouldnt do vs what you can do.

it is always better to know what the system CAN'T DO than what it is capable of . this of course doesnt mean to ignore technical capabilities. but knowing the limitation of the system always raise an important question : how can i get this feature from different systems, so it leads to thinking out of the current boundary.

2- Creativity : alot of people when they find a limitation in a system(specifically Developers) , first thing that pops up their mind is to build this feature , write code, creativity.

3- Indicates Experience : Anti Patterns are always derived from experience , opposite to Patterns which are inducted by both  theroies and practical experience. so if a techei guy knows how to architect a system by using patterns , this means that he can be using some theories in a mix of experience. but if he is very keen to avoid antipatterns , this means that he is so experienced.

4- Technical Interviewing : i got this q in my interview when i joined MS, "you have 5000 users using this protocol with this bandwidth, etc... alot of input information. how do you design a collaboration system with Sharepoint for them?" this question mean "what capacity plans and design patterns used?" the more complex and more experienced technical q is "what you should avoid when building such system?what are the antipatterns in this system?

5- better documentation : all the functional specs/design documents we have today are just putting some peices together to get an architecture which adhere to highest avilability, scalability, supportability , xability, etc....

if we have design documents that clearly says , "i will take this approach in design with these patterns over other designs , and my choices are based on these antipatterns", this will give every one a clear message of the constraints and limitations of the other designs.

Systems documentation now should add beside "whats new" and "System Features"---> "AntiPatterns and Limitation (what you shouldnt do with the system , and what the system cannot do for you)"

6- Higher productivity : if i want to go from Point A to Point B and i have 10 Routes. knowing the AntiPatterns is like looking into which of these routes cannot be used which in turn decreases my options to may be 2 . choosing 1 of 2 routes is much much better than choosing 1 of 10. this applies to planning, scoping , implemtation and all phases of projects.

 

ULTIMATE ANTIPATTERN(S) = LIMITING MY OPTIONS TO ONLY 1 OPTION , SO I HAVE NO CHOICE AT ALL :)  IT IS ONLY 1 WAY TO GO

if we have this ultimate set of antipatterns, we can create wizards around them to pickup the only route we have beside auto generating docs and code. this would be incredible.

Comments