taming coupling and cohesive beasts
TRANSCRIPT
TAMING COUPLING & COHESIVE BEASTS WITH
MODULARITY PATTERNS By Param Rengaiah (@its_param)
Creating enterprise software system is incredibly
HARD
Keeping it useful and relevant is
10x HARDER
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
VISION ARCHITECTS
REALITY IS?
HOW DO WE KNOW IF WE HAVE TAMED THE BEAST?
1 CONFIDENCE WHILE EMBRACING CHANGE
2PIVOT DESIGN WITH LEAST CASCADING DISRUPTION
3UNDERSTAND THE BUSINESS THROUGH CODE
MAINTAINING STATUS QUO IS NOT AN OPTION
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.
“
REDESIGN? Should we
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
Consider
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.
“
MODULE? What is a
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 ServerHibernate, Spring,
Spring Boots, Groovy
YAY!
Its time for a short demo.
OSGi?
What about
WHAT CAN WE INFER?
WITH WHAT WE HAVE SEEN SO FAR,
1. EXPOSE SEAMS OF THE SYSTEM
Seams?
2. ARCHITECT ALL THE WAY DOWN
WHAT CAN I DO NOW?
I WANT TO PREVENT OR FIX MY PROJECT
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 feature
5 PLAN A separate release for restructuring
6 CAMPAIGN And get the buy-in from stakeholders
7 RESTRUCTURE The system to modularity
If nothing is working, there’s always …
THANK YOU @its_param
http://www.adam-bien.com/roller/abien/entry/how_to_kill_an_osgi#comments 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