Erfahrungsbericht:
Datenbankbasierte Metrikverarbeitung
für Clean Code Development in
Brownfieldprojekten
Software Enginee...
Jens Nerche
Leiter Anwendungsentwicklung
Kontext E GmbH
www.kontext-e.de
Email j.nerche@kontext-e.de
Twitter @jensnerche
B...
Inhalt
Motivation
Herausforderung Brownfield
Verarbeitung von Metriken
Datenbank
Steadily adding value
Well-crafted software
Realität im
Brownfieldprojekt
Workarounds
Ziele
Größere Kontrolle
Einheitliche Art der Regelprüfung
Automatisierung der Regelprüfung vorantreiben
Verknüpfung der Da...
Eine Lösung
Alle Informationen in eine Datenbank
Dazu Architektur-Struktur
Metriken kombinieren
Regelverletzungen mittels ...
MATCH
(p1:Package)-[:DEPENDS_ON]->(p2:Package),
path = shortestPath(
(p2)-[:DEPENDS_ON*]->(p1:Package))
WHERE
p1<>p2
RETUR...
MATCH
(c:Class)-[:DEPENDS_ON]->(d:Type
{fqn: 'org.jmock.Mockery'})
WHERE
not(c.fqn =~ 'de.kontext_e.tim.EmployeeTest')
and...
MATCH (cl:JacocoClass)--(m:JacocoMethod)--
(c:JacocoCounter {type: 'COMPLEXITY'})
WHERE c.missed + c.covered > 5
AND NOT(m...
MATCH (c:GitCommit)--(f:GitCommitFile)
WITH f.relativePath AS path
WHERE path =~'.*.java'
WITH count(path) AS cnt, parseTo...
...
WHERE
c.fqn =~ 'de.kontext_e.tim.domain.*'
...
Testabdeckung bzgl.
Änderungshäufigkeit und
Kerndomäne
Zusammenfassung
Alle erhobenen Daten in einer gemeinsamen
Datenbank speichern
Datenbankabfragesprache nutzen, um
Regelverl...
Studenten:
Visualisierungen
IDE: Advanced Refactoring
C#
...
Jens Nerche
Leiter Anwendungsentwicklung
Kontext E GmbH
www.kontext-e.de
Email j.nerche@kontext-e.de
Twitter @jensnerche
B...
Erfahrungsbericht Datenbankbasierte Metrikverarbeitung für Clean Code Development in Brownfieldprojekten
Erfahrungsbericht Datenbankbasierte Metrikverarbeitung für Clean Code Development in Brownfieldprojekten
Nächste SlideShare
Wird geladen in …5
×

Erfahrungsbericht Datenbankbasierte Metrikverarbeitung für Clean Code Development in Brownfieldprojekten

241 Aufrufe

Veröffentlicht am

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.

Veröffentlicht in: Software
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
241
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
8
Aktionen
Geteilt
0
Downloads
1
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie
  • Unit Tests, Test Coverage
    Statische Codeanalyse
    Architektur- und Designvorgaben
    Automatische Integrations-, System- und Lasttests
    Continuous Integration &amp; 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
  • Erfahrungsbericht Datenbankbasierte Metrikverarbeitung für Clean Code Development in Brownfieldprojekten

    1. 1. Erfahrungsbericht: Datenbankbasierte Metrikverarbeitung für Clean Code Development in Brownfieldprojekten Software Engineering & Management 2015
    2. 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. 3. Inhalt Motivation Herausforderung Brownfield Verarbeitung von Metriken Datenbank
    4. 4. Steadily adding value
    5. 5. Well-crafted software
    6. 6. Realität im Brownfieldprojekt
    7. 7. Workarounds
    8. 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. 9. Eine Lösung Alle Informationen in eine Datenbank Dazu Architektur-Struktur Metriken kombinieren Regelverletzungen mittels DB-Abfrage finden IDE-Plugin
    10. 10. 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
    11. 11. 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
    12. 12. 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
    13. 13. 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
    14. 14. ... WHERE c.fqn =~ 'de.kontext_e.tim.domain.*' ... Testabdeckung bzgl. Änderungshäufigkeit und Kerndomäne
    15. 15. 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
    16. 16. Studenten: Visualisierungen IDE: Advanced Refactoring C# ...
    17. 17. 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

    ×