In einem neuen Projekt ("Greenfield Project") gleich mit Clean Code Development (CCD) zu beginnen ist der Wunschtraum eines jeden Entwicklers. Was aber, wenn man ein Legacy Project hat? Unit Tests - wenn sie überhaupt vorhanden sind - laufen nicht, sind langsam oder bieten eine zu geringe Testabdeckung. Zyklen in Abhängigkeiten, wohin man schaut. Zu große Packages, zu lange Methoden, zu hohe zyklomatische Komplexität sind nur einige der häufig auftretenden Symptome. Einige CCD-Tugenden wie Pfadfinderregel, Pair Programming, Iterationen, VCS oder CI sind davon nicht betroffen. Sobald man aber Metriken erhebt und ggf. den Build abbricht, stößt man an die Grenzen. Erstmal ein Riesenrefactoring zu machen, ist wirtschaftlich ausgeschlossen. Die Investition in Codequalität ist nur in kleinen Schritten möglich. Wichtig ist auch die psychologische Komponente: im Team muss der Fortschritt sichtbar sein. Im Beitrag werden Erfahrungen vorgestellt, die dabei gesammelt wurden. Zentraler Bestandteil ist das Sammeln aller verfügbaren Informationen in einer (Graphen-)Datenbank: Codestatistiken, Modulabhängigkeiten, Unit Test Abdeckung, Ergebnisse der Statischen Codeanalyse, VCS-Metadaten, Tracing-Logs aus Systemtest und Betrieb usw. Hinzu kommen Informationen aus einer Basiserhebung des Qualitätsstands des Brownfieldprojekts. Damit kann die datenbankgestützte Verarbeitung und Auswertung erhobener Metriken und Softwarestrukturinformationen unter besonderer Berücksichtigung der Besonderheiten von Brownfieldprojekten erfolgen. Es ist die sinnvolle Definition eines Quality Gates im CI-Server sowie die Festlegung organisatorischer und technischer Maßnahmen möglich.
8. Ziele
Größere Kontrolle
Einheitliche Art der Regelprüfung
Automatisierung der Regelprüfung vorantreiben
Verknüpfung der Daten aus verschiedenen Quellen
Bessere Planung der Investitionen in Codequalität
9. Eine Lösung
Alle Informationen in eine Datenbank
Dazu Architektur-Struktur
Metriken kombinieren
Regelverletzungen mittels DB-Abfrage finden
IDE-Plugin
13. MATCH (cl:JacocoClass)--(m:JacocoMethod)--
(c:JacocoCounter {type: 'COMPLEXITY'})
WHERE c.missed + c.covered > 5
AND NOT(m.signature = 'boolean equals(java.lang.Object)')
AND NOT(m.signature = 'int hashCode()')
AND NOT(cl.fqn =~ 'de.kontext_e.tim.jsf_ui.*')
WITH m AS method, cl.fqn AS fqn, m.signature AS signature,
c.missed + c.covered AS complexity
MATCH (m)--(branches:JacocoCounter {type: 'BRANCH'})
WHERE m = method AND branches.covered * 100 /
(branches.covered + branches.missed) < 90
RETURN fqn, signature, complexity, branches.covered * 100 /
(branches.covered + branches.missed) AS coverage
SKIP 2
Testabdeckung
14. MATCH (c:GitCommit)--(f:GitCommitFile)
WITH f.relativePath AS path
WHERE path =~'.*.java'
WITH count(path) AS cnt, parseToFullQualifiedName AS gitfqn
ORDER BY cnt DESC LIMIT 10
MATCH (cl:JacocoClass)--(m:JacocoMethod)--
(c:JacocoCounter {type: 'COMPLEXITY'})
WHERE gitfqn = cl.fqn AND c.missed + c.covered > 3
AND NOT(m.signature ='boolean equals(java.lang.Object)')
AND NOT(m.signature ='int hashCode()')
...
Testabdeckung bzgl. Änderungen
17. Zusammenfassung
Alle erhobenen Daten in einer gemeinsamen
Datenbank speichern
Datenbankabfragesprache nutzen, um
Regelverletzungen zu finden
Definierte Ausnahmen und Verknüpfung von Daten aus
verschiedenen Quellen ermöglicht bessere Steuerung
der Investitionen in die Codequalität
Einheitliche technische Basis vereinfacht Pflege
erheblich
19. Jens Nerche
Leiter Anwendungsentwicklung
Kontext E GmbH
www.kontext-e.de
Email j.nerche@kontext-e.de
Twitter @jensnerche
Blog
Slides http://de.slideshare.net/jensnerche
Samples https://github.com/jensnerche
Feedback http://speakerrate.com/jensnerche
Jens Nerche
Leiter Anwendungsentwicklung
Kontext E GmbH
www.kontext-e.de
Email j.nerche@kontext-e.de
Twitter @jensnerche
Blog http://techblog.kontext-e.de
Slides http://de.slideshare.net/jensnerche
Samples https://github.com/jensnerche
Feedback http://speakerrate.com/jensnerche
Notas del editor
Unit Tests, Test Coverage
Statische Codeanalyse
Architektur- und Designvorgaben
Automatische Integrations-, System- und Lasttests
Continuous Integration & Delivery
Versionsverwaltungssysteme
Ergebnisse getrennt oder lose aggregiert, z.B. mittels SonarQube
die Testabdeckung unzureichend
die statische Codeanalyse nicht vorhanden
kein Mechanismus zur Durchsetzung von Architektur- und Designregeln vorhanden
somit der Abbruch des CI-Builds bei Regelverletzungen nicht sinnvoll
die Nachverarbeitung der Metriken als Kriterium für eine Buildabbrung zwingend nötig
Groovy-Script für die Testabdeckung
XSLT für Checkstyle und FindBugs
ganze Module bei der Prüfung durch JDepend (zyklische Abhängigkeiten) ausgelassen
keine Prüfung von Architektur- und Designregeln (außer wenn durch Checkstyle möglich)
manuelle Prüfung: Code Reviews, Pair Programming, Common Code Ownership
Groovy-Script für die Testabdeckung
XSLT für Checkstyle und FindBugs
ganze Module bei der Prüfung durch JDepend (zyklische Abhängigkeiten) ausgelassen
keine Prüfung von Architektur- und Designregeln (außer wenn durch Checkstyle möglich)
manuelle Prüfung: Code Reviews, Pair Programming, Common Code Ownership