Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Resolving technical debt in software architecture

117 Aufrufe

Veröffentlicht am

Today programmers do not develop applications from scratch, but they spend their time fixing, extending, modifying and enhancing existing applications. The biggest problem in their daily work is that with time maintenance mutates from structured programming to defensive programming: The code becomes too complex to be maintained. We put in code we know is stupid from an architectural point of view but it is the only solution that will hopefully work. Maintenance is more and more difficult and expensive. Our software accumulates technical debts.
In this talk, you will see how you should improve your architecture and source code to prevent technical debt growing unrestricted. With the proper knowledge about well-structured architecture, refactorings for tangled code can quickly be found. Complex code can be eliminated, and maintenance costs will be reduced.

Veröffentlicht in: Software
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Resolving technical debt in software architecture

  1. 1. WPS - Workplace Solutions GmbH //// Hans-Henny-Jahnn-Weg 29 //// 22085 HAMBURG Resolving technical debt in software architecture Dr. Carola Lilienthal Carola.Lilienthal@wps.de, @cairolali www.wps.de
  2. 2. @cairolali
  3. 3. @cairolali 7 41 63 128 72 bis 15 Mio bis 5 Mio bis 1 Mio bis 500.000 bis 100.000
  4. 4. @cairolali HOW DO WE SPEND OUR TIME? 70% 20% 10% Code verstehen Problem lösen Code schreiben Code comprehension Problem solving Writing code
  5. 5. @cairolali WELL-FORMED COMPLEX STRUCTURES = SAVING TIME! Cognitive Mechanisms HierarchiesChunking Schemata
  6. 6. @cairolali
  7. 7. @cairolali WELL-FORMED COMPLEX STRUCTURES = SAVING TIME! Cognitive Mechanisms HierarchiesChunking Schemata Well-formed architecture Modularity
  8. 8. @cairolali MODULARITY ▪High Cohesion and lose Coupling ▪Responsibility Driven Design ▪Separation of Concerns ▪Single Responsibility Principle
  9. 9. @cairolali WELL-FORMED COMPLEX STRUCTURES = SAVING TIME! Cognitive Mechanisms HierarchiesChunking Schemata Well-formed architecture Modularity
  10. 10. @cairolali HIERARCHIES  
  11. 11. @cairolali WELL-FORMED COMPLEX STRUCTURES = SAVING TIME! Cognitive Mechanisms HierarchiesChunking Schemata Well-formed architecture Modularity Hierarchical Layerng
  12. 12. @cairolali
  13. 13. @cairolali WELL-FORMED COMPLEX STRUCTURES = SAVING TIME! Cognitive Mechanisms HierarchiesChunking Schemata Well-formed architecture Modularity Hierarchical Layerng Pattern Consistency
  14. 14. @cairolali WRONG PATTERN STOP THE FLOW Domain Module Model View Con trol ValueObject Service BusinessObject Factory ✓ createBusinessObject() ✓ createValueObject() × calculate(BO) × process(BO)
  15. 15. @cairolali WELL-FORMED COMPLEX STRUCTURES = SAVING TIME! Cognitive Mechanisms HierarchiesChunking Schemata Well-formed architecture Modularity Hierarchical Layerng Pattern Consistency
  16. 16. @cairolali
  17. 17. @cairolali TWO DIMENSIONS IN ON ARCHITECTURE Technical layering Domain layering Tree violations that are easy to resolve Difficult violations One component cuasing several problems One component causing a problem
  18. 18. @cairolali DOMAIN LAYERING IS MISSING Technical layering No domain layering Some violations of the technical layering Allmost all domain components need each other
  19. 19. @cairolali 119 classes from 4 components + 28 other classes
  20. 20. @cairolali 327 classes from 8 components That all need each other
  21. 21. @cairolali WELL-FORMED COMPLEX STRUCTURES = SAVING TIME! Cognitive Mechanisms HierarchiesChunking Schemata Well-formed architecture Modularity Hierarchical Layerng Pattern Consistency
  22. 22. @cairolali MICROSERVICES
  23. 23. @cairolali DOMAIN MODULES? UseCase-Driven
  24. 24. @cairolali DOMAIN MODULES? Models integrated in UseCasesUseCase-Driven
  25. 25. @cairolali UNEVEN MODULES 9 Components = 17 Subsystems
  26. 26. @cairolali 128 BUILD UNITS WITH NUMBER OF CLASSES ▪ 3 Mio of 9 Mio LOC ▪ 1/3 of the system
  27. 27. @cairolali 5.270 CLASSES IN ONE CYCLE IN ONE BUILDUNIT
  28. 28. @cairolali WELL-FORMED COMPLEX STRUCTURES = SAVING TIME! Cognitive Mechanisms HierarchiesChunking Schemata Well-formed architecture Modularity Hierarchical Layering Pattern Consistency
  29. 29. @cairolali User Interface Domain Application Domain Module Domain Module Domain Module Window GUI Model View C o n tr ol ValueObject Service BusinessObject Layeringbypattern
  30. 30. @cairolali PATTERN CONFORMITY: GOOD EXAMPLE ☺ 90% of the source code can be assigned to pattern ☺ 0,1% violations between the pattern Eventer Processes Service
  31. 31. @cairolali
  32. 32. 463 tangled classes belonging to 10 different components
  33. 33. @cairolali entities valueObjects
  34. 34. @cairolali entities valueObjects
  35. 35. @cairolali184 tangled classes left
  36. 36. @cairolali
  37. 37. @cairolali WELL-FORMED COMPLEX STRUCTURES = SAVING TIME! Cognitive Mechanisms HierarchiesChunking Schemata Modularity Hierarchical Layerng Pattern Consistency → Consistent and integrated pattern → Use a pattern language → No cycles neither on architectural level nor on class level → responsibility → coupling → size → interfaces
  38. 38. @cairolali 612.869 LOC 14.756.435 LOC 252.062 LOC 804.093 LOC 543.388 LOC 1.035.668 LOC 486.358 LOC 175.258 LOC 42.311 LOC 193.383 LOC 643.466 LOC 245.754 LOC 2.890.204 LOC 141.696 LOC 512.086 LOC 9.988.363 LOC 200.591 LOC 922.949 LOC 22.658 LOC 663.862 LOC 3.270.188 LOC 1.521.357 LOC 0 2 4 6 8 10 MODULARITY MATURITY INDEX (MMI)
  39. 39. @cairolali @cairolali cl@wps.de Available in English Summer 2019 www.langlebige-softwarearchitekturen.de www.sustainable-software-architecture.com THANK YOU FOR YOUR ATTENTION!

×