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.