Top Legacy Sins - Speaker Deck

Slide 1

Slide 1 text

Top Legacy Sins Eberhard Wolff Fellow @ewolff

Slide 2

Slide 2 text

http://microservices-buch.de/ http://microservices-book.com/

Slide 3

Slide 3 text

What should a Software Architect do?

Slide 4

Slide 4 text

Create a Proper Architecture.

Slide 5

Slide 5 text

Create a Proper Architecture. Agree??

Slide 6

Slide 6 text

I’m a Software Architect. But I’m not doing architecture. !

Slide 7

Slide 7 text

How important is Software Architecture?

Slide 8

Slide 8 text

Why would we care about Software Architecture?

Slide 9

Slide 9 text

Software Architecture =Structure

Slide 10

Slide 10 text

Architecture Goals: Quality > All kinds of quality > Performance > Security > … > Focus of this presentation: Changeability > Architects must understand customers & priority

Slide 11

Slide 11 text

Architects must understand customer

Slide 12

Slide 12 text

Software Architecture Set of structures comprise software elements, relations among them, and properties of both.

Slide 13

Slide 13 text

Why? > Can work on modules in isolation > Can work on collaboration of modules > Fits in my head Dan North

Slide 14

Slide 14 text

Does He Care?

Slide 15

Slide 15 text

Why? Great Architecture Software Easy to change High productivity Low Cost

Slide 16

Slide 16 text

He Cares €

Slide 17

Slide 17 text

Why? Great Architecture Software Easy to change High productivity Low Cost

Slide 18

Slide 18 text

What He Cares About Great Architecture Software Easy to change High productivity Low Cost

Slide 19

Slide 19 text

Is architecture the only factor for changeability?

Slide 20

Slide 20 text

What is the best thing we can have in a legacy code?

Slide 21

Slide 21 text

Great architecture or automated tests?

Slide 22

Slide 22 text

No Automated Tests > No way to find bugs > Changes almost impossible > Legacy code = code without tests > Michael Feathers Working Effectively with Legacy Code

Slide 23

Slide 23 text

Let’s add some automated UI tests

Slide 24

Slide 24 text

Automated UI Tests > Easy to implement > Exactly what testers do manually > Easy to understand for customers > Test business processes > Safety net

Slide 25

Slide 25 text

Unit Tests or automated UI tests?

Slide 26

Slide 26 text

Many UI Tests Worse > Fragile: Changes to UI break test > Business meaning of tests easily lost > Takes long > Often not reproducible

Slide 27

Slide 27 text

Automated UI Tests Automated Integration Tests Unit Tests Manual Tests

Slide 28

Slide 28 text

Automated UI Tests Automated Integration Tests Unit Tests Manual Tests

Slide 29

Slide 29 text

Slow Unreliable Expensive

Slide 30

Slide 30 text

Alternatives to automated UI tests?

Slide 31

Slide 31 text

Textueller Akzeptanztest

Slide 32

Slide 32 text

Szenario > Möglicher Ablauf in einer Story > Standardisierte Bestandteile: > Gegeben... (Kontext) > Wenn... (Ereignis) > Dann... (erwartetes Ergebnis)

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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); }

Slide 35

Slide 35 text

@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); } }

Slide 36

Slide 36 text

Test is about handling risk

Slide 37

Slide 37 text

Tests for Risks > Algorithm / calculation wrong: Unit test > System failures: Unit tests > Wiring / collaboration: Integration tests > Business process: Integration test > UI: UI test

Slide 38

Slide 38 text

Example: User Registration > Unit test Validations Database failure > Integration test Process > UI test Everything shown?

Slide 39

Slide 39 text

Not Tested > UI won’t test validation > …or algorithms > …or the process > Risks handled elsewhere

Slide 40

Slide 40 text

Automated UI Tests Automated Integration Tests Unit Tests Manual Tests

Slide 41

Slide 41 text

Automated UI Tests. Automated Integration Tests Unit Tests Manual Tests Test Pyramid

Slide 42

Slide 42 text

Test Pyramid instead of Automated UI Tests

Slide 43

Slide 43 text

Great architecture or fast & easy deployment?

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

Leseprobe: http://bit.ly/CD-Buch

Slide 46

Slide 46 text

Continuous Delivery: Build Pipeline Commit Stage Automated Acceptance Testing Automated Capacity Testing Manual Explorative Testing Release

Slide 47

Slide 47 text

Continuous Delivery > Testing > + automated deployment > Testing: reduce probability of errors > Automated deployment: better mean time to repair

Slide 48

Slide 48 text

Continuous Delivery > Make software easier to change > & deploy > Reliable and reproducible tests > Automated deployed > Fast & reliable

Slide 49

Slide 49 text

What is a great architecture?

Slide 50

Slide 50 text

UI Logic Database

Slide 51

Slide 51 text

Is Three Tier a great architecture?

Slide 52

Slide 52 text

Three Tier > Actually layer: no distribution > By technology > Layers can be replaced > Layers can be developed independently

Slide 53

Slide 53 text

Do you replace e.g. the persistence layer?

Slide 54

Slide 54 text

Is it really simple to add e.g. mobile clients?

Slide 55

Slide 55 text

A better reason: Fits in my head.

Slide 56

Slide 56 text

Redo the order processing!

Slide 57

Slide 57 text

Add feature to the registration! Can we change the persistence technology instead? Please?

Slide 58

Slide 58 text

What is a persistence technology??

Slide 59

Slide 59 text

Registration Order Billing UI Logic

Slide 60

Slide 60 text

Architecture > Should support changes > …with business value > Needs to model the domain > Hard to get right > Architect needs to understand the domain

Slide 61

Slide 61 text

Is a great architecture free of cyclic dependencies?

Slide 62

Slide 62 text

A B A depends on B Changes to B influence A

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

Is a great architecture free of cyclic dependencies?

Slide 65

Slide 65 text

Cyclic dependencies: Architects’ Mortal Sin

Slide 66

Slide 66 text

A B A B 42 2 200

Slide 67

Slide 67 text

Other Architecture Metrics > High cohesion > Elements of a module should belong together > Low coupling > Modules should not depend on each other

Slide 68

Slide 68 text

Great Architecture > Don’t overrate cyclic dependencies! > Consider other metrics > Architecture by domain

Slide 69

Slide 69 text

The worst legacy problems?

Slide 70

Slide 70 text

The project has a lot of cyclic dependencies! I know. …but that doesn’t cause a lot of trouble

Slide 71

Slide 71 text

Architects must understand customer & his quality demands

Slide 72

Slide 72 text

Quality > Changeability > Performance > Security > …

Slide 73

Slide 73 text

No two projects are alike.

Slide 74

Slide 74 text

No general rules.

Slide 75

Slide 75 text

Sorry!

Slide 76

Slide 76 text

Software Easy to change Automated tests Test pyramid Fast & easy deployment Great Architecture No cyclic dependencies Low coupling High cohesion

Slide 77

Slide 77 text

What should a Software Architect do?

Slide 78

Slide 78 text

Create a Proper Architecture.

Slide 79

Slide 79 text

Create a Proper Architecture.

Slide 80

Slide 80 text

I’m a Software Architect. But I’m not doing architecture. There is more to changeable software than architecture.

Slide 81

Slide 81 text

Thank You! @ewolff