taming coupling & cohesive beasts with modularity patterns and spring

Post on 17-Sep-2014

16 Views

Category:

Technology

1 Downloads

Preview:

Click to see full reader

DESCRIPTION

Speaker: Param Rengaiah By now you should have heard about coupling and cohesiveness. These concepts, and their third cousin, polymorphism, is what we as developers chase day-in and day-out. They tease us with reusability and the promise of comprehensiveness of our code. They entice us with promises of code quality and testability. They came in the form of "Object Oriented' design, followed by GoF and SOLID Design Patterns, DDD, BDD.. but none of them delivered what they promised. Now, the new kids on the block are Functional Programming and Modularity Patterns. What happens when you choose to go through large refactoring exercise on the back of Modularity Patterns, in a large, complex enterprise project? The journey was long, arduous and gruesome. On the way, I made many enemies and found some new friends. This talk will highlight the issues, both technical and otherwise, and how it was overcome; where did Spring help and where did it hurt. In the end, was it worth it? Come to this session and you will find out.

TRANSCRIPT

© 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.

top related