Top Legacy Sins
7 likes8,354 views
This document discusses what makes for a great software architecture and the role of the software architect. It argues that while architecture is important, other factors like automated tests, deployment practices, and understanding customer priorities are also critical for building changeable software. Cyclic dependencies alone do not determine how problematic a codebase is. The software architect's role is to create an architecture that supports business needs while also enabling qualities like changeability, performance and security. There are no universal rules and each project's context is unique.
Top Legacy Sins
- 1. Top Legacy Sins Eberhard Wolff Fellow @ewolff
- 3. What should a Software Architect do?
- 6. I’m a Software Architect. But I’m not doing architecture. !
- 8. Why would we care about Software Architecture?
- 10. Architecture Goals: Quality > All kinds of quality > Performance > Security > … > Focus of this presentation: Changeability > Architects must understand customers & priority
- 12. Software Architecture Set of structures comprise software elements, relations among them, and properties of both.
- 13. Why? > Can work on modules in isolation > Can work on collaboration of modules > Fits in my head Dan North
- 14. Does He Care?
- 16. He Cares €
- 18. What He Cares About Great Architecture Software Easy to change High productivity Low Cost
- 19. Is architecture the only factor for changeability?
- 20. What is the best thing we can have in a legacy code?
- 22. No Automated Tests > No way to find bugs > Changes almost impossible > Legacy code = code without tests > Michael Feathers Working Effectively with Legacy Code
- 23. Let’s add some automated UI tests
- 24. Automated UI Tests > Easy to implement > Exactly what testers do manually > Easy to understand for customers > Test business processes > Safety net
- 25. Unit Tests or automated UI tests?
- 26. Many UI Tests Worse > Fragile: Changes to UI break test > Business meaning of tests easily lost > Takes long > Often not reproducible
- 30. Alternatives to automated UI tests?
- 32. Szenario > Möglicher Ablauf in einer Story > Standardisierte Bestandteile: > Gegeben... (Kontext) > Wenn... (Ereignis) > Dann... (erwartetes Ergebnis)
- 33. Szenario: Beispiel Szenario: Kunde registriert sich erfolgreich Kontext Ereignis Erwartetes Ergebnis Erwartetes Ergebnis Gegeben ein neuer Kunde mit EMail eberhard.wolff@gmail.com Vorname Eberhard Name Wolff Wenn der Kunde sich registriert Dann sollte ein Kunde mit der EMail eberhard.wolff@gmail.com existieren Und es sollte kein Fehler gemeldet werden
- 34. RegistrationService registrationService; // Initialisierung RegistrationService // ausgelassen private User kunde; private boolean fehler = false; @Given("ein neuer Kunde mit "+ "EMail $email Vorname $vorname"+ " Name $name") public void gegebenKunde(String email, String vorname, String name) { kunde = new User(vorname, name, email); }
- 35. @When("der Kunde sich registriert") public void registerKunde() { try { registrationService.register(kunde); } catch (IllegalArgumentException ex) { fehler = true; } } @Then("sollte ein Kunde mit der EMail $email existieren") public void existiert(String email) { assertNotNull(registrationService.getByEMail(email)); } @Then("es sollte kein Fehler gemeldet werden") public void keinFehler() { assertFalse(fehler); } }
- 36. Test is about handling risk
- 37. Tests for Risks > Algorithm / calculation wrong: Unit test > System failures: Unit tests > Wiring / collaboration: Integration tests > Business process: Integration test > UI: UI test
- 38. Example: User Registration > Unit test Validations Database failure > Integration test Process > UI test Everything shown?
- 39. Not Tested > UI won’t test validation > …or algorithms > …or the process > Risks handled elsewhere
- 42. Test Pyramid instead of Automated UI Tests
- 43. Great architecture or fast & easy deployment?
- 44. Deployment > Manual deployment is error prone > Slow deployment > Lots of code developed but not deployed > i.e. more lean waste > Slow feedback > Slow time to recovery
- 47. Continuous Delivery > Testing > + automated deployment > Testing: reduce probability of errors > Automated deployment: better mean time to repair
- 48. Continuous Delivery > Make software easier to change > & deploy > Reliable and reproducible tests > Automated deployed > Fast & reliable
- 49. What is a great architecture?
- 51. Is Three Tier a great architecture?
- 52. Three Tier > Actually layer: no distribution > By technology > Layers can be replaced > Layers can be developed independently
- 53. Do you replace e.g. the persistence layer?
- 54. Is it really simple to add e.g. mobile clients?
- 55. A better reason: Fits in my head.
- 57. Add feature to the registration! Can we change the persistence technology instead? Please?
- 60. Architecture > Should support changes > …with business value > Needs to model the domain > Hard to get right > Architect needs to understand the domain
- 61. Is a great architecture free of cyclic dependencies?
- 62. A B A depends on B Changes to B influence A
- 63. A B A depends on B Changes to B influence A B depends on A Changes to A influence B In fact one component Should be two components
- 64. Is a great architecture free of cyclic dependencies?
- 66. A B A B 42 2 200
- 67. Other Architecture Metrics > High cohesion > Elements of a module should belong together > Low coupling > Modules should not depend on each other
- 68. Great Architecture > Don’t overrate cyclic dependencies! > Consider other metrics > Architecture by domain
- 70. The project has a lot of cyclic dependencies! I know. …but that doesn’t cause a lot of trouble
- 71. Architects must understand customer & his quality demands
- 72. Quality > Changeability > Performance > Security > …
- 73. No two projects are alike.
- 75. Sorry!
- 76. Software Easy to change Automated tests Test pyramid Fast & easy deployment Great Architecture No cyclic dependencies Low coupling High cohesion
- 77. What should a Software Architect do?
- 80. I’m a Software Architect. But I’m not doing architecture. There is more to changeable software than architecture.