Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Erfahrungsbericht Datenbankbasierte Metrikverarbeitung für Clean Code Development in Brownfieldprojekten

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.

  • Sé el primero en comentar

  • Sé el primero en recomendar esto

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

    Sé el primero en comentar

    Inicia sesión para ver los comentarios

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.

Vistas

Total de vistas

500

En Slideshare

0

De embebidos

0

Número de embebidos

4

Acciones

Descargas

1

Compartidos

0

Comentarios

0

Me gusta

0

×