Manche Softwaresysteme sind Intensivpatienten: Sie können nur mit hohem Aufwand weiter am Leben gehalten werden. Sämtliches Budget wird verbraucht, um Qualitätsschulden zurück zu zahlen: Bugs fixen; Performance tunen; Sicherheitslöcher stopfen; Architekturbrüche auflösen. Wir stellen im Vortrag die 4 Schritte der Software-Sanierung vor: Erstens, die Probleme erfassen. Hierbei hilft uns ein Diagnoseverfahren, das der Medizin entlehnt ist. Zweitens, die Ursachen identifizieren. Hier zählt es, die richtigen (Open-Source-) Werkzeuge einzusetzen zur statischen Analyse von Code- und Architekturanomalien und zur dynamischen Analyse von Laufzeitanomalien. Drittens, Maßnahmen ableiten und umsetzen sowie einen wirksamen und vernünftig priorisierten Maßnahmenkatalog erstellen und daraus Refactoringpläne ableiten und ausführen. Viertens, die Erfolge messen also bestimmen, wie wirksam die Maßnahmen wirklich waren, ob das Ziel schon erreicht ist, oder ob weitere Maßnahmen angegangen werden müssen. Neben dem eigentlichen Ablauf beschreiben wir eine Reihe an Methoden, Best Practices und Werkzeuge, die dabei erfolgskritisch sind.

1. 1
30 Minuten
Software-Sanierung: Wie man kranke Systeme wieder gesund macht.
Dr. Josef Adersberger (josef.adersberger@qaware.de)

2. 2
Manch Software ist ein Intensivpatient.
http://www.klinikum.uni-heidelberg.de

3. Grund 1: Das Ding läuft nicht richtig.
3
https://developers.facebook.com/status
MTTR: ~46 Stunden
Äußere Qualität

4. Grund 2: Qualitätsschulden und Software-Bankrott.
4
Software von angemessenerQualität
Änderungskosten in €
Zeit
Software von degenerierterQualität
Budget
Erste zerbrochene Fensterscheibe
Software-
Qualitätsschulden
Innere Qualität

5. 5
Doch wie helfen?
http://www.starflash.de/stars/dr.-house-fanclub-266439.html

6. 6
1: Anamnese
Erhebung der Leidensgeschichte des Patienten.

7. 7
Was ist das Fehlerbildvor Kunde? Wie hoch ist der Schaden?
Wann wurde der Fehler erstmalig gemeldet und wie häufig tritt er seitdem auf (MTTF)?
Wie lange dauert es, um das System nach dem Fehler wieder lauffähig zu bekommen (MTTR)?
Kann der Fehler reproduziert werden?
Sind Logsoder Monitoring-Daten für vor, während und nach dem Fehler verfügbar?
Gab es vor dem Fehler ein besonderes Ereignis (z.B. betrieblicher Eingriff, ausgefallenes Nachbarsystem oder Request-Spitze)?
Welche Ideen gibt es für die Fehlerursachen?
Wie lange wird die Software bereits entwickelt?
Wie viele Entwickler haben daran entwickelt und wie hoch war ihre Fluktuation?
Wie umfangreich ist die Software (z.B. in Lines-of-Code)?
Was sind die größten Produktivitätshemmnisse bei den Entwicklern?
Wo drückt der Schuh?
Gibt es ein Architekturbildder Software?
Bei Laufzeitproblemen:
Bei Qualitätsschulden:
Welche Technologienwerden eingesetzt?

8. 8
Untersuchung
Messungen und Inspektionen am Patienten durchführen:
Vitalfunktionen
Symptombezogen
Gesamtheitlich

9. 9
http://www.siemens.com/press/pool/de/pressebilder/2013/healthcare/imaging-therapy-systems/HIM201311007
Eine Frage der Werkzeuge

10. Das Software-EKG + ein guter Profiler.
10
Viele Knoten und Prozesse
Non-invasive Messpunkte: SNMP, WPC, JMX, …
Hohe Abtastfrequenz
Integrierte Log-Analyse
Explorative Analyse-UI

11. EKGpi: Eine Software-Blackbox.
11

12. SonarQube: Ein Vital-Monitor der inneren Softwarequalität.
12
Trends!
Die wichtigsten Metriken
Alarme
Anomalien

13. Structure101: Ein Röntgenapparat für Code.
13
Architekturkonsistenz
Komplexitätsverteilung
Zyklen
Refactoring-Simulation

14. 14
Diagnose
Symptom: Ein Zeichen, das auf eine Erkrankung hinweist.
Befund: Ergebnis einer Untersuchung (pathologisch weist auf Erkrankung hin)
Beschwerde: Aussage des Patienten
Diagnose: Krankheitsursache erschließen. Dafür sind neben den Symptomen oft weitere Untersuchungen notwendig.
Ausschluss-Diagnose: Ursachen ausschließen.
Differenzial-Diagnose: Iterative risiko-und wahrscheinlichkeitsorientierte Eingrenzung.
Verdachtsdiagnose: Auf Verdacht behandeln.

15. 15
Diagnostik
Symptomatik
Anamnese: Anwendung macht hauptsächlich NW-IO. Kein Reproducer.
Beschwerde: Java-Web-System stürzt seit letztem Release erratisch nach wenigen Stunden Laufzeit ab.
Differenzialdiagnose„Systemausfall Web-System“.
Befund (o.B.): Keine Fehlermeldungen in den Applikations-und Systemlogs.
Befund (o.B.): Keine Speicherknappheit im Monitoring erkennbar.
Befund (o.B): Keine Korrelation des Ausfalls mit der Systemlast erkennbar.
Befund (o.B.): Keine Korrelation des Ausfalls mit einem bestimmten Request.
Befund (pathologisch): Zu gering gesetzte FileHandles(ulimit) im Betriebssystem.
Notfalltherapie: Watchdoginstallieren, der Neustart auslöst.
Therapie: FileHandlesper ulimiterhöht.
Untersuchung: Log-Level der System-Logs erhöhen und Logs aus anschließendem Produktionslauf monitoren.
Befund (pathologisch, Leitsymptom): System-Log zeigt weiterhin einen JVM-Exit mitSegmentation Error (ungültige Speicherreferenzierung).
Eingrenzung: Fehler entsteht nicht durch Java-Code. Er kannentstehen durch:
1.Einen Bug in einer verwendeten nativen Bibliothek
2.Einen Bug in der JVM
3.Eine fehlerhafte Konfiguration der JVM
4.Eine fehlerhafte Konfiguration des Systems
Ausschluss-Diagnose:
•Untersuchung: JVM-Shutdown-Hook ergänzen, der Core- Dumpbei Exit erstellt und in Produktion auf Fehler warten.
•Untersuchung: Alle JVM-Parameterder Anwendung ermitteln.
Befund (pathologisch): Segmentation Error im JVM-Codefür Netzwerk-IO.
Verdachtsdiagnose(nach Internet-Recherche): Bug in JVM 6 mit unpassendem Default-Wert für StackShadowPages.
Therapie:StackShadowPageserhöht.
Untersuchung: Produktion überwachen.
Befund (o.B.): Produktion läuft stabil.

16. Bei Qualitätsschulden ist die Diagnose einfacher: 90% der Symptome lassen sich auf wenige Ursachen zurückführen.
16
■Mangelnde Testüberdeckung.
■Unüberlegter Einsatz von (Open-Source-) Bibliotheken und Frameworks.
■Zu viele Code-Anomalien und uneinheitlich formatierter Code.
■Zu viel duplizierter Code.
■Zu wenig Kommentare an den wichtigen Stellen.
■Komplexitätsnester.
■Keine (vernünftige) Architektur.
■Fehlende Architekturkonsistenz.
Die Ursachen für die restlichen 10% lassen sich gut durch eine Woche Pair Programmingmit einem Stamm-Entwickler ermitteln.

17. 17
Dings
bums
Die ewig konsistente Architektur

18. Natürlich haben wir eine Architektur!
18

19. Qualitätsschulden entstehen jedoch insbesondere auch durch
mangelhafte fachliche Modularisierung.
19

20. 20
Therapie
Therapie: Maßnahmen zur Behandlung von Krankheiten.
Gezielte Therapie
Notfalltherapie
Verdachtstherapie

21. Der Therapie-Plan: Maßnahmenkatalog.
21
■Symptom (Auffälligkeit)
■(Therapie-) Maßnahme
■Was passiert, wenn man es nicht macht?
■Priorität
■Aufwand
■Wirkung

22. Wichtig ist die Nachsorge: Ein Qualitätskontrakt definiert ein verbindliches Qualitätsniveau und Qualitätsziele.
22
Tests
Code
Duplikate
Kommentare
Architektur
Komplexität
Funktionalität
Änderbarkeit
Metrik
rot
gelb
C1-Testüberdeckung über alle Testebenen
<60%
< 65%
Testerfolg
< 100%
Ignorierte Testfälle
> 0
Rot: Code-Duplikate (ohne Generate) mit mehr als 10 Anweisungen duplizierter Code-Struktur.
Metrik
rot
gelb
Dokumentierte API
<90%
<100%
Kommentarquote
< 10%
<25%
Rot: Verletzung gegen eine definierte Soll-Architektur existieren.
Rot: Abhängigkeitszyklen über Paketgrenzen hinweg.
Rot: Anteil am Code- Volumen der Methoden mit einer zyklomatischenKomplexität > 10 ist größer als 10%.
Metrik
rot
gelb
Code-Anomalien mit Schweregrad Blocker oder Critical oder Major.
> 0
Code-Anomalien mit Schweregrad Minor, Info
> 0
Semantik der Farben:
Rot: Zu keinem Zeitpunkt akzeptabel. Reißleinen- Prinzip.
Gelb: Muss vor einem Release blau sein.
Grau: Wenn nichts gemessen wird.
Blau: Wenn nicht gelb/rot/grau.

23. 23
Abweichungen
Trends
Attraktoren
Information Radiatorenmachen Qualität sichtbar

24. 24
Information Radiatorenmachen Qualität sichtbar
Featuring: Shake-to-Build

25. QAwareGmbH, Aschauer Str. 32, 81549 München, GermanyTel +49 89 232315-0, Fax +49 89 232315-129, info@qaware.de, www.qaware.de
QUANTENSPRUNG DANK ANDERSDENKEN
Josef Adersberger
josef.adersberger@qaware.de
@adersberger