Post on 17-Sep-2014
description
© 2013 SpringOne 2GX. All rights reserved. Do not distribute without permission.
TAMING COUPLING & COHESIVE BEASTS WITH MODULARITY PATTERNS AND SPRING
By Param Rengaiah
CREATING ENTERPRISE SOFTWARE SYSTEM IS INCREDIBLY
HARD
KEEPING IT USEFUL AND RELEVANT IS
HERCULEAN
COST PERCENTAGE FOR MAINTENANCE IS
70%
CHANGE
ACCEPT AND ANTICIPATE
ESSENTIAL
CHANGE IS NOT ONLY DESIRABLE BUT
SPRING FRAMEWORK GROWTH FROM 14K LOC IN 2004 TO 2013 IS
1.3 MILLION
WHY?
CHANGING AND ENHANCING AN APPLICATION IS CHALLENGING.
VISION ARCHITECTS
REALITY IS AFTER A YEAR OR SO,
SPAGHETTI
COMPLICATED, DIFFICULT TO UNDERSTAND, AND IMPOSSIBLE TO MAINTAIN IS
BRIAN FOOTE JOSEPH YODER
[ Big ball of mud / spaghetti ] systems show unmistakable signs of unregulated growth and repeated, expedient repair.
“
DESIGN ROT
TIGHTLY COUPLED CODE WITH EXCESSIVE DEPENDENCIES IS KNOWN AS
ROBERT C. MARTIN (UNCLE BOB)
There are four primary symptoms that tell us that our designs are rotting : rigidity, fragility, immobility, and viscosity.
“
TECHNICAL DEBT
WHEN YOU CHOOSE TO DEFER INTERNAL THINGS THAT WILL IMPEDE FUTURE DEVELOPMENT, YOU INCUR
MARTIN FOWLER
Development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.
“
IF WE KNOW ALL THESE THINGS, WHY DOES IT STILL HAPPEN?
WHY?
MASK OFF
LETS TAKE THE
1 LOGICAL DESIGN FLAWS
PHIL KARLTON
There are only two hard things in Computer Science: cache invalidation and naming things.
“
2PHYSICAL & STRUCTURAL DESIGN FLAWS
The physical architecture is the skeleton of the system – if it is malformed, there is no cosmetic remedy for alleviating its unpleasant symptoms.
“
JOHN LAKOS
JOHN LAKOS
The quality of the physical design of a large system will dictate the cost of its maintenance and the potential it has for the independent reuse of its subsystems.
“
THE BEAST LIVES!
THIS IS WHERE
REALITY IS?
HOW DO WE KNOW WE HAVE TAMED THE BEAST?
1 CONFIDENCE WHILE EMBRACING CHANGE
2PIVOT DESIGN WITH LEAST CASCADING DISRUPTION
3UNDERSTAND THE BUSINESS THROUGH CODE
LEHMAN’S LAW
INTRODUCING
As a system evolves, its complexity increases unless work is done to maintain or reduce it.
“
MANNY LEHMAN - LEHMAN’S SECOND LAW
REFACTOR? SHOULD WE
MARTIN FOWLER
Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.
“
MARTIN FOWLER
Its heart is a series of small behavior preserving transformations. Each transformation does little, but a sequence such transformations can produce a significant restructuring.
“
S.O.L.I.D? APPLY OOP DESIGN PRINCIPLES LIKE
DESIGN ROT
TIGHTLY COUPLED CODE WITH EXCESSIVE DEPENDENCIES IS KNOWN AS
The physical architecture is the skeleton of the system – if it is malformed, there is no cosmetic remedy for alleviating its unpleasant symptoms.
“
JOHN LAKOS
RESTRUCTURING TO MODULARITY
MARTIN FOWLER
I see refactoring as a very specific technique to do the more general activity of restructuring. Restructuring is any rearrangement of parts of a whole.
“
I’m dancing! By God I’m dancing on the walls. I’m dancing on the ceiling. I’m ecstatic. I’m overjoyed. I’m really, really pleased.
“
FROM THE FOREWORD BY ROBERT C. MARTIN
MANAGE RELATIONSHIPS
MODULE REUSE
COHESIVE MODULES
ACYCLIC RELATIONSHIPS
LEVELIZE MODULES
PHYSICAL LAYERS
CONTAINER INDEPENDENCE
INDEPENDENT DEPLOYMENT
PUBLISHED INTERFACE
EXTERNAL CONFIGURATION
DEFAULT IMPLEMENTATION
MODULE FAÇADE
ABSTRACT MODULES
IMPLEMENTATION FACTORY
SEPARATE ABSTRACTIONS
UTILITY PATTERNS
TOOLS YOU NEED THE RIGHT
TOOLS
Spring Tool Suite
App Server Hibernate, Spring, Spring Boots, Groovy
YAY!
ITS TIME FOR A SHORT DEMO.
SO, WHAT CAN WE INFER?
1. EXPOSE SEAMS OF THE SYSTEM
2. ARCHITECT ALL THE WAY DOWN
WHAT NOW?
I CAN’T START THE RESTRUCTURE TODAY.
1 RECORD DESIGN DEBTS, HACKS AND QUICK WINS
2 REVIEW THE INVENTORY AT LEAST EVERY SIX MONTHS
3 REFACTOR LOGICAL FLAWS AS PART OF REGULAR RELEASE CYCLES
4 PILOT THE RESTRUCTURE FOR AN ISOLATED FUNCTION
5 PLAN A SEPARATE RELEASE FOR RESTRUCTURING
6 CAMPAIGN AND GET THE BUY-IN FROM STAKEHOLDERS
7 RESTRUCTURE THE SYSTEM TO MODULARITY
THANK YOU @its_param
http://baruzzo.wordpress.com/2009/07/01/physical-design-vs-logical-design-part-i/ http://blogs.msdn.com/b/ericlippert/archive/2009/04/06/good-names.aspx http://docs.oracle.com/javaee/6/tutorial/doc/bnadx.html http://en.wikipedia.org/wiki/Lehman's_laws_of_software_evolution http://en.wikipedia.org/wiki/Technical_debt http://interactiveasp.net/blogs/softwarepsychology/archive/2009/12/23/the-blame-game.aspx http://martinfowler.com/bliki/RefactoringMalapropism.html http://martinfowler.com/bliki/TechnicalDebt.html http://martinfowler.com/bliki/TechnicalDebt.html http://martinfowler.com/books/refactoring.html http://mikadomethod.wordpress.com/2009/12/09/introduction-to-the-mikado-method/#more-1 http://stackoverflow.com/questions/1030388/how-to-overcome-the-anti-pattern-big-ball-of-mud http://upload.wikimedia.org/wikipedia/commons/7/7b/Hammer2.jpg http://www.codinghorror.com/blog/2006/05/the-long-dismal-history-of-software-project-failure.html http://www.codinghorror.com/blog/2007/11/the-big-ball-of-mud-and-other-architectural-disasters.html http://www.construx.com/10x_Software_Development/Technical_Debt/ http://www.flickr.com/photos/tambako/494118044/ http://www.informit.com/authors/bio.aspx?a=410e6d20-a168-41cb-8d5e-93b14e4843d9 http://www.jsjf.demon.co.uk/thesis/Thesis.html http://www.kirkk.com/modularity/2009/12/chapter-5-taming-the-beast/ http://www.kirkk.com/modularity/pattern-catalog/ http://www.laputan.org/mud/ http://www.ohloh.net/p/spring/analyses/latest/languages_summary
REFERENCES AND ACKNOWLEDGEMENTS
https://medium.com/@its_param https://medium.com/on-software-architecture/46603626bc1e Twitter: twitter.com/springsource YouTube: youtube.com/user/SpringSourceDev Google +: plus.google.com/+springframework LinkedIn: springsource.org/linkedin Facebook: facebook.com/groups/springsource
Learn More. Stay Connected.