Taming coupling and cohesive beasts
•Transferir como PPTX, PDF•
3 gostaram•1,164 visualizações
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a Taming coupling and cohesive beasts
Semelhante a Taming coupling and cohesive beasts (20)
Último
Último (20)
Taming coupling and cohesive beasts
- 1. © 2013 Spring, by Pivotal TAMING COUPLING & COHESIVE BEASTS WITH MODULARITY PATTERNS AND SPRING Param Rengaiah, Experience Architect @its_param
- 2. 22 Creating enterprise software system is incredibly HARD.
- 3. 33 Keeping it useful and relevant is even more HARDER! http://www.flickr.com/photos/teddyllovet/9421262432/
- 4. 44 70% That’s the percentage cost spent on maintaining large enterprise applications.
- 5. 55 CHANGE is not only essential but desirable
- 6. 66 SPRING FRAMEWORK LOC on March 2004 – 14 K LOC on August 2013 – 1.3 M
- 7. 77 WHY? is it difficult to modify and enhance an application?
- 8. 88 BACKSTORY My personal journey and why I am passionate about this subject.
- 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. 1010 TECHNICAL DEBT Section 5.2 on [5], [6] and [7]
- 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. 1212 DESIGN ROT Section 5.3 on [5]
- 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. 1414 BIG BALL OF MUD Visit the links [2], [3] and [4]
- 15. 1515 QUESTION TIME Open your most recent project and search for classes with *util*, *helper* and *manager*
- 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. 1818 BEAST !!! Congratulations!!! You have unleashed the
- 19. 1919 TAME THE BEAST? So, how do we
- 20. 2020 DREAM Lets
- 22. 2222 PIVOT The design with least amount of cascading disruption.
- 23. 2323 UNDERSTAND The business and the business constrains through CODE
- 25. 2525 Second Law. As a system evolves, its complexity increases unless work is done to maintain or reduce it. Specifically, “
- 26. 2626 REFACTORING THE DESIGN So the magic ingredient is …
- 28. 2828 DESIGN Modularity Patterns SOLID Design Principle GoF Design Patterns
- 29. 2929
- 30. 3030
- 31. 3131
- 32. 3232 TOOLS Spring Tool Suite App Server Hibernate, Spring, Spring Boots, Groovy
- 33. 3333 COHESIVE MODULES Module behavior should serve a singular purpose
- 34. 3434
- 35. 3535
- 36. 3636
- 37. 3737
- 38. 3838
- 39. 3939 ABSTRACT MODULES Depend upon the abstract elements of a module.
- 40. 4040 SEPARATE ABSTRACTIONS Place abstractions and the classes that implement them in separate modules.
- 41. 4141
- 42. 4242 SPEC AND IMPL MODULES Also fulfills SRP and DIP in SOLID Principles Leads us to create
- 43. 4343 IMPLEMENTATION FACTORY Use factories to create a module’s implementation classes.
- 44. 4444 SPRING AND EXTENSION Injecting extensions in a non-intrusive way.
- 45. 4545
- 47. 4747 ACYCLIC RELATIONSHIPS Module relationships must be acyclic.
- 49. 4949 ADAPTER Modules And corresponding SPEC and IMPL modules
- 50. 5050
- 51. 5151 DEMO TIME
- 53. 5353 ALL THE WAY DOWN Architect
- 54. 5454 MODULAR Design? Why not start with a
- 55. 5555 RECORD Design debts, hacks and quick wins
- 56. 5656 REVIEW The Inventory every six month
- 57. 5757 PLAN A separate release for paying the principle
- 60. 6060 THANK YOU !!! Connect me on twitter at @its_param Email me at param.rengaiah@aspiresys.com
- 62. 6262 http://panelpicker.sxsw.com/vot e/22263 Please share and vote! UX DESIGN
- 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. 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
Notas do Editor
- 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