Taming coupling and cohesive beasts

1,112 views

Published on

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

No Downloads
Views
Total views
1,112
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
10
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • http://blogs.msdn.com/b/karchworld_identity/archive/2011/04/01/lehman-s-laws-of-software-evolution-and-the-staged-model.aspxAccording to several sources, and perhaps counter to intuition, the maintenance of software comprises from 50% to 90% of the overall lifecycle costs (Pigoski, 1997; Lientz & Swanson, 1980)
  • http://www.ohloh.net/p/spring/analyses/latest/languages_summary
  • One large WAR module
  • Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.
  • 5.3.1 – Hinder Maintenance5.3.2 – Prevent Extensibility5.3.3 – Inhibit Reusability5.3.4 – Restrict Testability5.3.5 – Hamper Integration5.3.6 – Limit UnderstandingThere are four primary symptoms that tell us that our designs are rotting. They are not orthogonal, but are related to each other in ways that will become obvious. they are: rigidity, fragility, immobility, and viscosity.
  • Big Ball of Mud
(a.k.a. Shantytown, Spaghetti Code)Throwaway Code
(a.k.a. Quick Hack, Kleenex Code, Disposable Code, Scripting, Killer Demo, Permanent Prototype, Boomtown)Piecemeal Growth
(a.k.a. Urban Sprawl, Iterative-Incremental Development)Keep It Working
(a.k.a. Vitality, Baby Steps, Daily Build, First Do No Harm)Shearing LayersSweeping It Under The Rug
(a.k.a. Potemkin Village, Housecleaning, Pretty Face, Quarantine, Hiding it Under the Bed, Rehabilitation)Reconstruction
(a.k.a. Total Rewrite, Demolition, Plan to Throw One Away, Start Over)
  • Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.
  • All told eight laws were formulated:(1974) Continuing Change — E-type systems must be continually adapted or they become progressively less satisfactory.[3](1974) Increasing Complexity — As an E-type system evolves its complexity increases unless work is done to maintain or reduce it.[3](1974) Self Regulation — E-type system evolution process is self-regulating with distribution of product and process measures close to normal.[3](1978) Conservation of Organisational Stability (invariant work rate) - The average effective global activity rate in an evolving E-type system is invariant over product lifetime.[3](1978) Conservation of Familiarity — As an E-type system evolves all associated with it, developers, sales personnel, users, for example, must maintain mastery of its content and behaviour to achieve satisfactory evolution. Excessive growth diminishes that mastery. Hence the average incremental growth remains invariant as the system evolves.[3](1991) Continuing Growth — The functional content of E-type systems must be continually increased to maintain user satisfaction over their lifetime.(1996) Declining Quality — The quality of E-type systems will appear to be declining unless they are rigorously maintained and adapted to operational environment changes.(1996) Feedback System (first stated 1974, formalised as law 1996) — E-type evolution processes constitute multi-level, multi-loop, multi-agent feedback systems and must be treated as such to achieve significant improvement over any reasonable base.
  • Modularity Patterns – Manages Structural ModularityGoF Patterns – Manages Logical ModularitySOLID helps us define the boundary for classes and packages
  • Second System Syndrome
  • Second System Syndrome
  • Second System Syndrome
  • Second System Syndrome
  • Second System Syndrome
  • Second System Syndrome
  • Second System Syndrome
  • Second System Syndrome
  • Second System Syndrome
  • Second System Syndrome
  • Taming coupling and cohesive beasts

    1. 1. © 2013 Spring, by Pivotal TAMING COUPLING & COHESIVE BEASTS WITH MODULARITY PATTERNS AND SPRING Param Rengaiah, Experience Architect @its_param
    2. 2. 22 Creating enterprise software system is incredibly HARD.
    3. 3. 33 Keeping it useful and relevant is even more HARDER! http://www.flickr.com/photos/teddyllovet/9421262432/
    4. 4. 44 70% That’s the percentage cost spent on maintaining large enterprise applications.
    5. 5. 55 CHANGE is not only essential but desirable
    6. 6. 66 SPRING FRAMEWORK LOC on March 2004 – 14 K LOC on August 2013 – 1.3 M
    7. 7. 77 WHY? is it difficult to modify and enhance an application?
    8. 8. 88 BACKSTORY My personal journey and why I am passionate about this subject.
    9. 9. 99 Possible Reasons  Development spends too much time in understanding existing implementation  Class names are too generic and hence the responsibility of a class gets wide and complex  Business rules are spread across multiple architectural layers  Too many if / else and switch / cases in classes  Direct usage of implementation classes in parent modules
    10. 10. 1010 TECHNICAL DEBT Section 5.2 on [5], [6] and [7]
    11. 11. 1111 “Technical Debt is a wonderful metaphor developed by Ward Cunningham… In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. - Martin Fowler
    12. 12. 1212 DESIGN ROT Section 5.3 on [5]
    13. 13. 1313 “There are four primary symptoms that tell us that our designs are rotting. They are not orthogonal, but are related to each other in ways that will become obvious. they are: rigidity, fragility, immobility, and viscosity. - Uncle Bob
    14. 14. 1414 BIG BALL OF MUD Visit the links [2], [3] and [4]
    15. 15. 1515 QUESTION TIME Open your most recent project and search for classes with *util*, *helper* and *manager*
    16. 16. 1616 SUFFERING Essentially leads to
    17. 17. 1717 SUCH AS  Forcing your team to continuously work long hours.  Burning out your best team members.  High churn rate of resources.  Create psychological divide between development, testing and operations team.  Setting up your team member to just play safe.  Basically, unpleased work environment. At the worst - completely scrapping the project.
    18. 18. 1818 BEAST !!! Congratulations!!! You have unleashed the
    19. 19. 1919 TAME THE BEAST? So, how do we
    20. 20. 2020 DREAM Lets
    21. 21. 2121 CONFIDENCE While embracing change
    22. 22. 2222 PIVOT The design with least amount of cascading disruption.
    23. 23. 2323 UNDERSTAND The business and the business constrains through CODE
    24. 24. 2424 LEHMAN’S LAW Introducing
    25. 25. 2525 Second Law. As a system evolves, its complexity increases unless work is done to maintain or reduce it. Specifically, “
    26. 26. 2626 REFACTORING THE DESIGN So the magic ingredient is …
    27. 27. 2727 PHYSICAL & STRUCTURAL DESIGN Specifically,
    28. 28. 2828 DESIGN Modularity Patterns SOLID Design Principle GoF Design Patterns
    29. 29. 2929
    30. 30. 3030
    31. 31. 3131
    32. 32. 3232 TOOLS Spring Tool Suite App Server Hibernate, Spring, Spring Boots, Groovy
    33. 33. 3333 COHESIVE MODULES Module behavior should serve a singular purpose
    34. 34. 3434
    35. 35. 3535
    36. 36. 3636
    37. 37. 3737
    38. 38. 3838
    39. 39. 3939 ABSTRACT MODULES Depend upon the abstract elements of a module.
    40. 40. 4040 SEPARATE ABSTRACTIONS Place abstractions and the classes that implement them in separate modules.
    41. 41. 4141
    42. 42. 4242 SPEC AND IMPL MODULES Also fulfills SRP and DIP in SOLID Principles Leads us to create
    43. 43. 4343 IMPLEMENTATION FACTORY Use factories to create a module’s implementation classes.
    44. 44. 4444 SPRING AND EXTENSION Injecting extensions in a non-intrusive way.
    45. 45. 4545
    46. 46. 4646 MANAGE RELATIONSHIPS Design module relationships.
    47. 47. 4747 ACYCLIC RELATIONSHIPS Module relationships must be acyclic.
    48. 48. 4848 DDD – BOUNDED CONTEXT Anti-Corruption Layer
    49. 49. 4949 ADAPTER Modules And corresponding SPEC and IMPL modules
    50. 50. 5050
    51. 51. 5151 DEMO TIME
    52. 52. 5252 SEAMS OF THE SYSTEM Expose
    53. 53. 5353 ALL THE WAY DOWN Architect
    54. 54. 5454 MODULAR Design? Why not start with a
    55. 55. 5555 RECORD Design debts, hacks and quick wins
    56. 56. 5656 REVIEW The Inventory every six month
    57. 57. 5757 PLAN A separate release for paying the principle
    58. 58. 5858 BUY-IN From stakeholders Get the
    59. 59. 5959 REFACTOR To Modularity
    60. 60. 6060 THANK YOU !!! Connect me on twitter at @its_param Email me at param.rengaiah@aspiresys.com
    61. 61. 6161 Please come. SPRING CONFERENCE
    62. 62. 6262 http://panelpicker.sxsw.com/vot e/22263 Please share and vote! UX DESIGN
    63. 63. 6363 https://medium.com/@its_param Please visit. MY BLOG
    64. 64. 6464 References 1. http://www.jsjf.demon.co.uk/thesis/Thesis.html 2. http://www.laputan.org/mud/ 3. http://www.codinghorror.com/blog/2007/11/the-big-ball-of-mud- and-other-architectural-disasters.html 4. http://stackoverflow.com/questions/1030388/how-to-overcome-the- anti-pattern-big-ball-of-mud 5. http://www.kirkk.com/modularity/2009/12/chapter-5-taming-the- beast/ 6. http://en.wikipedia.org/wiki/Technical_debt 7. http://martinfowler.com/bliki/TechnicalDebt.html 8. http://interactiveasp.net/blogs/softwarepsychology/archive/2009/12 /23/the-blame-game.aspx
    65. 65. 6565 References 9. http://en.wikipedia.org/wiki/Lehman's_laws_of_software_evolution 10. http://www.kirkk.com/modularity/pattern-catalog/ 11. http://www.ohloh.net/p/spring/analyses/latest/languages_summary

    ×