Taming coupling and cohesive beasts

537 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
537
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Taming coupling and cohesive beasts

  1. 1. TAMING COUPLING & COHESIVE BEASTS WITH MODULARITY PATTERNS By Param Rengaiah (@its_param)
  2. 2. Creating enterprise software system is incredibly HARD
  3. 3. Keeping it useful and relevant is 10x HARDER
  4. 4. Cost percentage for maintenance is 70%
  5. 5. Accept and anticipate CHANGE
  6. 6. Change is not only desirable but ESSENTIAL
  7. 7. Spring framework growth from 14k loc in 2004 to 2013 is 1.3 MILLION
  8. 8. Changing and enhancing an application is challenging. WHY?
  9. 9. ARCHITECTS VISION
  10. 10. After a year or so, REALITY IS
  11. 11. Complicated, difficult to understand, and impossible to maintain is SPAGHETTI
  12. 12. BRIAN FOOTE “ JOSEPH YODER [ Big ball of mud / spaghetti ] systems show unmistakable signs of unregulated growth and repeated, expedient repair.
  13. 13. Tightly coupled code with excessive dependencies is known as DESIGN ROT
  14. 14. ROBERT C. MARTIN (UNCLE BOB) “ There are four primary symptoms that tell us that our designs are rotting : rigidity, fragility, immobility, and viscosity.
  15. 15. When you choose to defer internal things that will impede future development, you incur TECHNICAL DEBT
  16. 16. “ Development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments. MARTIN FOWLER
  17. 17. If we know all these things, why does it still happen? WHY?
  18. 18. Lets take the MASK OFF
  19. 19. 1 LOGICAL DESIGN FLAWS
  20. 20. “ There are only two hard things in Computer Science: cache invalidation and naming things. PHIL KARLTON
  21. 21. 2 PHYSICAL & STRUCTURAL DESIGN FLAWS
  22. 22. “ physical architecture The is the skeleton of the system – if it is malformed, there is no cosmetic remedy for alleviating its unpleasant symptoms. JOHN LAKOS
  23. 23. “ quality of the 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. JOHN LAKOS
  24. 24. THIS IS WHERE THE BEAST LIVES!
  25. 25. ARCHITECTS VISION
  26. 26. REALITY IS?
  27. 27. HOW DO WE KNOW IF WE HAVE TAMED THE BEAST?
  28. 28. 1 CONFIDENCE WHILE EMBRACING CHANGE
  29. 29. 2 PIVOT DESIGN WITH LEAST CASCADING DISRUPTION
  30. 30. 3 UNDERSTAND THE BUSINESS THROUGH CODE
  31. 31. MAINTAINING STATUS QUO IS NOT AN OPTION
  32. 32. Introducing LEHMAN’S LAW
  33. 33. “ a system evolves, its As complexity increases unless work is done to maintain or reduce it. - LEHMAN’S SECOND LAW MANNY LEHMAN
  34. 34. Should we REFACTOR?
  35. 35. “ Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. MARTIN FOWLER
  36. 36. “ heart is a series of small Its behavior preserving transformations. Each transformation does little, but a sequence such transformations can produce a significant restructuring. MARTIN FOWLER
  37. 37. Should we REDESIGN?
  38. 38. Apply oop design principles like S.O.L.I.D?
  39. 39. Tightly coupled code with excessive dependencies is known as DESIGN ROT
  40. 40. “ physical architecture The is the skeleton of the system – if it is malformed, there is no cosmetic remedy for alleviating its unpleasant symptoms. JOHN LAKOS
  41. 41. Consider RESTRUCTURING TO MODULARITY
  42. 42. “see refactoring as a very I specific technique to do the more general activity of restructuring. Restructuring is any rearrangement of parts of a whole. MARTIN FOWLER
  43. 43. What is a MODULE?
  44. 44. “ dancing! By God I’m 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
  45. 45. MANAGE RELATIONSHIPS
  46. 46. MODULE REUSE
  47. 47. COHESIVE MODULES
  48. 48. ACYCLIC RELATIONSHIPS
  49. 49. LEVELIZE MODULES
  50. 50. PHYSICAL LAYERS
  51. 51. CONTAINER INDEPENDENCE
  52. 52. INDEPENDENT DEPLOYMENT
  53. 53. PUBLISHED INTERFACE
  54. 54. EXTERNAL CONFIGURATION
  55. 55. DEFAULT IMPLEMENTATION
  56. 56. MODULE FAÇADE
  57. 57. ABSTRACT MODULES
  58. 58. IMPLEMENTATION FACTORY
  59. 59. SEPARATE ABSTRACTIONS
  60. 60. UTILITY PATTERNS
  61. 61. You need the right TOOLS
  62. 62. Spring Tool Suite TOOLS App Server Hibernate, Spring, Spring Boots, Groovy
  63. 63. Its time for a short demo. YAY!
  64. 64. What about OSGi?
  65. 65. WITH WHAT WE HAVE SEEN SO FAR, WHAT CAN WE INFER?
  66. 66. 1. EXPOSE SEAMS OF THE SYSTEM
  67. 67. Seams?
  68. 68. 2. ARCHITECT ALL THE WAY DOWN
  69. 69. I WANT TO PREVENT OR FIX MY PROJECT WHAT CAN I DO NOW?
  70. 70. 1 RECORD Design debts, hacks and quick wins
  71. 71. 2 REVIEW The inventory at least every six months
  72. 72. 3 REFACTOR Logical flaws as part of regular release cycles
  73. 73. 4 PILOT The restructure for an isolated feature
  74. 74. 5 PLAN A separate release for restructuring
  75. 75. 6 CAMPAIGN And get the buy-in from stakeholders
  76. 76. 7 RESTRUCTURE The system to modularity
  77. 77. If nothing is working, there’s always …
  78. 78. THANK YOU @its_param
  79. 79. REFERENCES AND ACKNOWLEDGEMENTS 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

×