1

Mastering the hard way

Einführung von Code Profiler in einer gewachsenen

Applikationslandschaft

2 2

Agenda

Vorstellung EWE und Referent

Problemstellung

Ein Blick zurück

Vorgehen mit CodeProfiler

Lessons Learned

Ganzheitliche Lösungen in drei Schlüsselbranchen

3

EWE bündelt mit Energie, Telekommunikation

und Informationstechnologie

die Schlüsselkompetenzen

für nachhaltige, intelligente Energiesysteme

EWE – eines der größten Unternehmen im

Nordwesten

4

Umsatz 8,9 Mrd. €

Ergebnis 57,2 Mio. €

Mitarbeiter Ø 9.162

Sehr guter Service, Beratung und die Nähe zu

unseren Kunden sind unsere Stärke

5

2013

1,4 Mio. Stromkunden

1,6 Mio. Gaskunden

680.000 Telekommunikationskunden

EWE Regionen in Deutschland, Polen, Türkei

6

7 7

Vorstellung Markus Theilen

Diplom-Informatiker

2001 – 2012 bei BTC AG als Software-Entwickler und Software-

Architekt in easy+-Entwicklung (ABAP) tätig

• Erstellung und Etablierung von Entwicklungsvorgaben

• Einführung von automatisierten Prüfungen von Entwicklungsobjekten

seit 2012 als IT-Koordinator für E-IT-Gruppe Abrechnung und

Marktpartner-Kommunikation (AMK), zuständig für

Entwicklungskoordination und Betrieb easy+

Seit 2009 stellv. Sprecher des DSAG-Arbeitskreis Development

•Co-Autor “Best Practice Leitfaden Development - Praxistipps rund um das

Thema ABAP Development”

Autor einer der meistgelesenen Präsentation über ABAP-

Codeanalyse:

http://www.slideshare.net/therealtier/static-abap-code-analyzers

8 8

Vorstellung easy+

Vollständige Eigenentwicklung auf Basis von SAP ERP 6.0

Umfasst die Komponenten Ablesung, Abrechnung, Fakturierung und

Forderungsmanagement, Marktkommunikation und

Reporting/Controlling für Energiedienstleistungen des EWE-Konzerns

Funktional in etwa vergleichbar mit SAP IS-U

Komplett in ABAP entwickelt, seit 1995 im produktiven Einsatz

Rund 100 Personen in der Entwicklung tätig

9 9

Warum „Mastering the hard way“?

Über Jahrzehnte gewachsene Applikation

Teilweise über 100 Entwickler mit sehr heterogenen Skill-Leveln

involviert

Keine ausgeprägte Kapselung von internen Modulen (ultra-depandenter

Monolith)

Selten Überprüfung der Einhaltung von Entwicklerrichtlinien

Regressionstests vollständig manuell, auch bei rein technischen

Änderungen notwendig

10 10

Technische Daten rund um easy+

8 TByte Datenvolumen

10 Mio. Lines of Code

1.600 Pakete

11.000 Programme

8.600 Klassen und 1.500 Interfaces

1.500 Funktionsgruppen

4.400 Tabellen

11 11

Zu viel Code für manuelle Reviews

Mit Größe des Codes kann die Komplexität

exponentiell wachsen

Code kann lokal gut aussehen, aber im

Kontext einer Aufrufhierarchie schlimme

Folgen haben

Diese Komplexität lässt sich manuell nicht

prüfen

Internes Paradigma:

„Keine Entwicklerrichtlinie aufstellen, die

sich nicht automatisiert prüfen läßt!“

12 12

Ein Blick zurück

Bis 2009 keine statischen Analysewerkzeuge in Benutzung

Auch keine regelmäßigen Code Reviews

Keine belastbaren Aussagen über Code-Qualität

„Gefühlt“ schlechte Qualität in alten Coding-Teilen, erwartete bessere

Qualität in neuen Code-Teilen

13 13

Einführung eines Konkurrenzproduktes

2009 Start der Einführung eines Konkurrenzproduktes in der easy+-

Entwicklung bei BTC

Schwerpunkt ABAP, aber auch einsetzbar für Java, C/C++, .NET-

Sprachen usw.

Fokus auf Auswertungen auf Management-Ebene

14 14

Licht…

Aussagen über Code-Qualität waren mit Abstrichen möglich.

Es gab eine „Gewöhnung“ der Entwickler an Einsatz von Code-

Analysewerkzeugen.

Wissen über gutes und schlechtes Coding wurde über Informationen

aus dem Analysewerkzeug unter Entwicklern verbreitet

Sehr viele und aufschlussreiche Dashboards auf hoher Flughöhe

(Management-Ebene) lieferten teilweise erstaunliche Erkenntnisse.

15 15

…und Schatten

Eingekauftes Tool war teuer, schwerfällig in der Bedienung, langsam

und fehleranfällig.

Viele false positives oder komplett falsche Regeln führten zu stark

abnehmender Akzeptanz auf Entwicklerseite.

Auftreten von Benchmark Optimization mit negativen Auswirkungen

beobachtet.

Keine direkte Einbindung in ABAP-Entwicklungsprozess möglich

(Workbench, TMS), kein einfacher Weg für Entwickler zu „ihren“

Objekten

Unterscheidung zwischen unverändertem Bestandscoding und gerade

geändertem Coding kaum möglich => Korrekturen konnten nur über den

gesamten Bestand verteilt werden, was zusätzlichen manuellen

Testaufwand mit sich brachte.

16 16

Ein (letztes) Wort zum Konkurrenzprodukt

In anderen Entwicklungsumgebungen als ABAP ist dieses Produkt

deutlich stabiler und ausgereifter und der Hersteller besitzt in diesen

anderen Technologien auch deutlich mehr Inhouse-Kompetenz.

Weiterhin bietet es sehr interessante und aufschlussreiche

Analysewerkezuge auf Basis einer „Entwicklungsobjekts-DB“ mit

Metadaten und vielfältigen Beziehungen zwischen Objekten.

Die Fokussierung des Produktes geht in Richtung des Managements.

Wir haben erst im Laufe des Einsatzes gemerkt, dass wir eine andere

Richtung verfolgen und das wir dafür ein anderes Werkzeug brauchen.

17 17

Wechsel zu CodeProfiler

Ende 2012 Start einer Teststellung

Seit 2013 im produktiven Einsatz

Fokus vorerst auf Feedback für Entwickler, weniger Dashboarding für

Management

18 18

Positive Erfahrungen und Potential

Schnellere Analysen und geringere Anzahl an false positives

Guter und schneller Support

Gute Einflussmöglichkeit auf Weiterentwicklung

Durch Einbindung in TMS können Korrekturen gezielt in den

Entwicklungsobjekten erfolgen, die aus Projektgründen sowieso

geändert und damit auch getestet werden.

Spürbares ABAP-Know-How

Potential für weitere Verbesserung in Regelbasis und Usability wird

spürbar angegangen

19 19

Einführung von Scrum mit Auswirkungen auf die

Entwicklungsarbeit

Ebenfalls Ende 2012 startete die Transition der easy+-Entwicklung auf

Scrum als Vorgehensmodell der Projektumsetzung

Wichtiges Prinzip in Scrum: „Feedback early and often!“

Je kürzer die Feedbackzyklen sind, desto schneller und leichter kann

wieder das richtige Ziel angesteuert werden.

Begleitend findet Einführung von agilen Entwicklungspraktiken zur

Steigerung der Qualität statt.

Dieses Prinzip des schnellen Feedbacks soll auf die Einhaltung von

Entwicklungsrichtlinien übertragen werden.

=> Änderung des Verhaltens notwendig.

20 20

Änderung von Verhalten erfordert:

Feedback:

• regelmäßig alle Beteiligte sachlich und objektiv über

gute und schlechte Dinge informieren

Schmerzen und Belohnungen:

• Auswirkungen von „schlechtem“ Verhalten muss für

diejenigen spürbar sein, die es ändern können

• Positives Verhalten muss durch Belohnungen

verstärkt werden

21 21

Feedback mit Konkurrenzprodukt

Feedback gab es erst jeden Monat, dann alle zwei Wochen, aber immer

noch „zu spät“.

Auf Entwicklerseite entwickelte sich kein Bezug zwischen eigener Arbeit

und abstrakten „Managementzahlen“.

Es wurde aufgrund der zeitlichen Lücke zwischen Entstehung und

Entdeckung keine direkt spürbaren „Schmerzen“ oder Unwohlsein

vermittelt.

Insgesamt: Kaum Anreiz zur Bewegung.

22 22

Feedback mit CodeProfiler

Feedback über eigene Entwicklung durch Integration in

Entwicklungsumgebung ist jederzeit möglich, spätestens aber bei

Transportfreigabe (mehrmals pro Woche oder Tag) und damit deutlich

näher am Entstehungszeitpunkt.

Spürbare „Schmerzen“: Die Verletzung von bekannten und

abgestimmten Regeln führt zu Freigabeverweigerung und

Genehmigungsprozess mit Rückfragen.

Ein Belohnungseffekt muss noch entwickelt werden (Gamification-

Ansatz).

23 23

Vorgehen bei Einführung von CodeProfiler

Im ersten Schritt stand nur die Integration des Tools in

Entwicklungswerkzeuge im Vordergrund.

Anschließend erfolgte eine Abstimmung mit repräsentativ ausgewählten

Entwicklern über aktivierte Regeln und solche, die Transportfreigaben

verhindern.

Daraufhin wurde eine Genehmigungsinstanz (Architekturteam) für

Ausnahmeanfragen eingerichtet.

Die Aktivierung der Transportblocker erfolgt in Wellen.

24 24

Aktueller Stand der Transportblocker pro Monat

Transporte ohne Findings: 499

mit Findings: 50 Korrigiert

44%

Ausnahmen 56%

∑ Findings: 87 *

* Legacy Code, technische Nachtransporte (Systemkopien), False Positives

25 25

Kriterien zur Regelauswahl

Die Auswahl der Regel, die aktiviert und sogar als Transportblocker

eingestellt werden, erfolgt im Entwicklergremium nach folgenden

Kriterien:

• Geschätzter Aufwand für Behebung oder Beseitigung

• Anzahl des Auftretens im bestehenden Code

• Schadenspotential

• Persönliche Meinung

26 26

Umgang mit Legacy Code

Legacy Code verletzt meistens deutlich mehr Regeln als neues Coding,

weil die Regeln zum Entstehungszeitpunkt nicht bekannt waren. Wie

geht man damit um ?

Genauso behandeln wie neuen Code

• Provoziert Aufschrei des Entsetzens

• Funktioniert aber bei sanfter Einführung von Regeln

Abgrenzen nach Erstellungsdatum

• Erleichtert den Einstieg

• Gefahr: Alte Fehler bleiben unbehandelt

Wir verwenden die erste Variante.

27 27

Nächste Stufen

Neu-Installation der CodeProfiler-BW-Komponenten für Management-

Auswertungen

Ausrollen von ABAP Development Tools (ABAP in Eclipse) mit

Integration von CodeProfiler ermöglicht noch direkteres Feedback beim

Tippen

ADT ermöglicht auch nahtlose Integration von weiteren

(Inhouse-)Werkzeugen in die Entwicklungsumgebung

28 28

Evolution der Feedback-Zyklen

14 Tage

x mal pro Woche

ständig

Konkurrenz-

Produkt

CodeProfiler

ADT mit CP

und anderen

Tools

29 29

Lessons Learned

Nicht alle sind über Transparenz der Code-Qualität glücklich, aber sie ist

notwendig, um Änderungen / Verbesserungen herbeizuführen

Einbindung des Betriebsrat so früh wie möglich, um Sorgen und Ängste

abzubauen

Beobachtung von „Benchmark Optimisation“, um negative Effekte zu

verhindern

30 30

Lessons Learned

Klein anfangen, dann weiter ausbauen:

• Schrittweise Erweiterung des Regelsets

• Schrittweise Vergrößerung der Code-Menge

Prüfwerkzeuge so gut und so früh wie möglich im Entwicklungsprozess

integrieren

Entwickler über aktivierte Regeln entscheiden lassen, um automatisch

für Akzeptanz zu sorgen

31

Fragen und Diskussion

32

Kontaktdaten:

Markus.Theilen@ewe.de

@therealtier

EWE Aktiengesellschaft

Donnerschweer Straße 22-26

26123 Oldenburg

Tel. 04 41 / 48 05-0

www.ewe.de

Vielen Dank für Ihre Aufmerksamkeit.

33