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.

1. Erfahrungsbericht:
Datenbankbasierte Metrikverarbeitung
für Clean Code Development in
Brownfieldprojekten
Software Engineering & Management 2015

2. 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

3. Inhalt
Motivation
Herausforderung Brownfield
Verarbeitung von Metriken
Datenbank

4. Steadily adding value

5. Well-crafted software

6. Realität im
Brownfieldprojekt

7. Workarounds

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

11. MATCH
(p1:Package)-[:DEPENDS_ON]->(p2:Package),
path = shortestPath(
(p2)-[:DEPENDS_ON*]->(p1:Package))
WHERE
p1<>p2
RETURN
p1 AS package,
EXTRACT(p IN NODES(path) | p.fqn) AS cycle
ORDER BY
package.fqn;
Zyklenfreiheit

12. MATCH
(c:Class)-[:DEPENDS_ON]->(d:Type
{fqn: 'org.jmock.Mockery'})
WHERE
not(c.fqn =~ 'de.kontext_e.tim.EmployeeTest')
and not(c.fqn =~ 'de.kontext_e.tim.ProjectTest.*')
RETURN
c.fqn
ORDER BY
c.fqn;
jMock => Mockito

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

15. ...
WHERE
c.fqn =~ 'de.kontext_e.tim.domain.*'
...
Testabdeckung bzgl.
Änderungshäufigkeit und
Kerndomäne

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

18. Studenten:
Visualisierungen
IDE: Advanced Refactoring
C#
...

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