Software-Sanierung

Josef Adersberger, Johannes Siedersleben, Johannes Weigend

München, Februar 2017

Sanierung vs. Neubau vs. WartungBeispiel: schlechter Start, erfolgreiche Sanierung

2

0%

100%Neubau

Wartung

Jahre

technischer

Erneuerungsanteil

Zweistrang-Sanierung

Einstrang-Sanierung

Uralt-Systeme

saniert man selten

Zweistrang-Sanierung: Zwei Teams, aufgeräumte Baustellen, klare Verantwortung, aber Risiko beim Merge

3

Trunk

Branch, neuer Trunk

Branch Merge 2Merge 1

Sanierungsprojekte sind so unwillkommen wie ein selbstverschuldeter Krankenhausaufenthalt

4

Niemand will sie.

• Niemand will zahlen.

• Niemand akzeptiert die Verschiebungen.

• Wie konnte es dazu kommen?

• Wer ist schuld?

• Welches Team kann die Sanierung machen?

Und sie beginnen oft chaotisch.

• Das musste ja so kommen.

• Auf mich hat ja niemand gehört.

• Wie macht man ein Sanierungsprojekt überhaupt?

• Jetzt machen wir alles anders.

• Jetzt machen wir alles neu.

Die drei Dimensionen der Software-Sanierung:Psychologie, Management, Technik

5

Psychologie:

• Wer war schuld? Entwickler, Architekten oder Manager?

• Wie kann man Schuldfrage ausklammern?

• Wer ist Teil des Problems, wer ist Teil der Lösung?

• Was rechtfertigt die Annahme, dass bei der Sanierung

keine alten Fehler wiederholt und nur wenige neue eingebaut werden?

• Wie kann man dem Team Mut machen?

Management:

• Holt das nötige Budget und die nötige Zeit.

• Stellt ein schlagkräftiges Team auf.

• Schützt das Team vor (zu vielen) fachlichen Anforderungen.

• Entscheidet mit den Entwicklern über Ein-Strang oder Zwei-Strang

• Stellt sicher, dass die nächste Sanierung erst in 20 Jahren fällig ist.

Technik

• Rest des Vortrags

Qualitätsschulden und Software-Bankrott.

6

Software von

angemessener

Qualität

Änderungskosten in €

Zeit

degenerierte

SW-Qualität

Budget

Software-

Qualitätsschulden

(Technical Debt - Ward Cunningham, 1992)

(Technical Bankruptcy –

Laura Thomson, 2010)

(Broken Windows Theory –

Wilson & Kelling, 1982)

Die drei Dimensionen von Sanierungstechnik:Handwerk, Architektur, Prozess

7

Handwerk:

• Mangelhafte Programmierrichtlinien

• Zu wenige Testfälle

• Mangelndes Qualitätsbewusstsein.

Architektur

• Ungeeignete Frameworks (selbstgebaut)

• Fehlende Konzepte z. B. zu Security, Robustheit, Skalierbarkeit

• Keine Komponenten

• usw.

Prozess:

• Schlechte Tools

• Ungeschickter Einsatz von VCS

• Ungeschickter Einsatz von Maven, Jenkins, sonstigen Tools

• Ungeeignetes Vorgehensmodell (Kommunikation im Team,

Meetings, Verantwortung)

Software-Sanierung bedeutet:

8

Reparatur, Renovierung und Modernisierung der Software und des

Entwicklungsprozesses, um die Zukunfts- und Leistungsfähigkeit

(wieder-) herzustellen. Dazu werden Produktivitätsbremsen beseitigt,

Anomalien behoben und Qualitätsschulden abgebaut. Nach einer

erfolgreichen Sanierung sind die Qualitätsschulden nahe Null, und der

Stand der Technik ist erreicht.

9

Diagnose und Therapie: Handwerk

Viele Qualitätsschulden lassen sich auf 10 Ursachen zurückführen.

10

1. Zu viele Code-Anomalien

2. Uneinheitlich formatierter Code

3. Zu viel duplizierter Code

4. Zu viele Paket-übergreifenden Zyklen

5. Zu wenig Kommentare

6. Mangelnde Testüberdeckung

7. Komplexitätsnester

8. Unüberlegter Einsatz von (Open-Source-) Bibliotheken und Frameworks

9. Keine Softwarekomponenten mit Schnittstellen, sondern nur Schichten oder

gar keine Ordnung

10.Mangelnde Konsistenz zwischen Architektur und Code

SonarQube überwacht die Code-Qualität

11

Trends!

Die wichtigsten Metriken

Anomalien

12

Trends

Attraktoren

Code-Qualität ist öffentlich

Code Reading ist oft der beste Weg, um die Lage zu beurteilen.

13

Code Reading (alleine oder mit Entwickler)

Typischen Durchstich entlang lesen

Typische Änderungsszenarien durchspielen

… dabei die Möglichkeiten von intelliJ nutzen

(Code-Navigation, Visualisierung von Abhängigkeiten, Re-

Formatierung)

… dabei auf seinen Bauch hören (Bad Smells, Antipatterns)

Manche VCS können die Historie visualisieren.

14

http://gource.io

Wie man kranken Code zu verbessert.

15

Quality Friday

Lokale Anomalien beheben Globale Anomalien beheben Testüberdeckung erhöhen

Komplexitätsnester und neuralgische

Stellen sofort überdecken mit > 60%

Bei jedem Bug vorher einen Test-

Reproducer schreiben

In der Breite für Coverage sorgen mit

automatisierten UI- und

Komponententests

Refactoring Roboter

AOP:

ungenutzte Features wegwerfen

Proprietären Code durch Open

Source ersetzen

Redundanzen entfernen

Ungenutzte oder schwach

genutzte Abhängigkeiten entfernen

Abstraktionen einziehen

Code-Diät

+ im Vorbeigehen beheben

Ziel war: Null Blocker, Critical / Major deutlich reduzieren. Das ist gelungen.

16

Vorher: 26.10.2016 Nachher: 29.10.2016

Vorher Nachher Differenz

Blocker 2 0 2

Critical 7.191 5.368 1.823

Major 103.064 99.748 3.316

Minor 121.280 118.979 2.301

Info 24.932 24.870 62

7.504

Ergebnis

■ Keine Blocker mehr

■ 7.504 Meldungen reduziert!

■ 25% der Criticals entfernt!

Bewertung

■ Und das alles, ohne mit „False Positives“ und „Excludes“ zu arbeiten.

■ Wir sind besser als Sonar glaubt ;-) Mit 10 Leuten an 1d Debt im Wert von 271d ausgebaut!

■ Zero-Violation-Policy ist definitiv möglich!

Praxisbeispiel

Quality Friday

Zielsetzung war: 0 Blocker, Critical / Major deutlich reduzieren. Das ist gelungen.

17

Vorher: 26.10.2016 Nachher: 29.10.2016

Vorher Nachher Differenz

Blocker 2 0 2

Critical 7.191 5.368 1.823

Major 103.064 99.748 3.316

Minor 121.280 118.979 2.301

Info 24.932 24.870 62

7.504

Ergebnis

■ Keine Blocker mehr

■ 7.504 Meldungen reduziert!

■ 25% der Criticals entfernt!

Bewertung

■ Und das alles, ohne mit „False Positives“ und „Excludes“ zu arbeiten.

■ Wir sind besser als Sonar glaubt ;-) Mit 10 Leuten an 1d Debt im Wert von 271d ausgebaut!

■ Zero-Violation-Policy ist definitiv möglich!

Praxisbeispiel:

Quality Friday

Ca. 100-1.000 Violations pro Entwickler und Tag, je nachdem,

wie generisch sich manche Violations lösen lassen.

Diagnose und Therapie von Performance-Anomalien.

18

Diagnostizierbarkeit herstellen

Laufzeitanomalien erkennen

Laufzeitanomalien beseitigen

Leaks

Locks

DB-Zugriffe

Remote Calls

Naive Programmierung

Bottlenecks

Events (Logs, ...)

Metriken

Traces

Laufzeitumgebung verbessern: JDK Upgrade / Konfiguration

Bugfixing

Infrastruktur erweitern: CDN, Proxy, …

Diagnostizierbarkeit

Dynamische Analyse

Der Lasttest-Werkzeugkasten

20

Selenium

WireMockGatling F5-Lasttest

Selber schreiben

21

Invasiv vs. Aussagekraft

Applikation

Invasiv

Wenig Invasiv

Software-EKG

Betriebssystem

JProfilerWireshark

strace / perf

DTrace / BCC, BPF

Prozess

top / lsof / netstat / … Applikationslogs

Zipkin, Dynatrace

Runtime

Das Software EKG ist ein Werkzeug mit dem verteilte Systeme über lange

Zeiträume (bis zu Jahren) in Produktion vermessen und visualisiert werden

können

23

24

Diagnose und Therapie: Architektur

https://martinfowler.com/bliki/DesignStaminaHypothesis.html

Statische Analyse

Bad Smell: Big Ball of Mud

25

Bad Smell: Integration per Datenbank (-Layer)

26

Bad Smell: Schichten als einzige Struktur

27

Bad Smells: Abhängigkeiten

28

Butterfly Breakable

Zyklen

Bad Smell: Komplexität über alle Pakete verschmiert

30

!

Größe

Komplexität

Open-Source-Abhängigkeiten: Sicherheitslücken, veraltete Versionen.

31

https://www.versioneye.com

Sicherheitslücken:

OWASP Dependency Analyzer

https://www.owasp.org/index.php/OWASP_Dependen

cy_Check

Versionsupdates (Technische Inflation):

Version Debt

https://github.com/portofrotterdam/versiondebt-plugin

Dependency Updates

http://www.mojohaus.org/versions-maven-

plugin/examples/display-dependency-updates.html

Mit structure101 kann der Umfang und die Stellen

der Nutzung von externen Bibliotheken ermittelt

werden („Show Externals“ aktivieren)

46