Das Dokument beschreibt die Einführung eines Code Profilers bei EWE, einem Unternehmen in der Energie-, Telekommunikations- und IT-Branche, um die Qualität des über Jahre gewachsenen, komplexen ABAP-Codes zu verbessern. Trotz anfänglicher Schwierigkeiten mit einem Konkurrenzprodukt wurde der Code Profiler ab 2012 erfolgreich implementiert, wodurch die Feedbackzyklen verkürzt und die Entwickler aktiv in den Prozess der Regeldefinition einbezogen wurden. Zu den Lehren gehören die Notwendigkeit transparenter Code-Qualität und eine schrittweise Einführung von Regeln, um Akzeptanz bei den Entwicklern zu fördern.

1. 1
Mastering the hard way
Einführung von Code Profiler in einer gewachsenen
Applikationslandschaft

2. 22
Agenda
Vorstellung EWE und Referent
Problemstellung
Ein Blick zurück
Vorgehen mit CodeProfiler
Lessons Learned

3. Ganzheitliche Lösungen in drei Schlüsselbranchen
3
EWE bündelt mit Energie, Telekommunikation
und Informationstechnologie
die Schlüsselkompetenzen
für nachhaltige, intelligente Energiesysteme

4. EWE – eines der größten Unternehmen im
Nordwesten
4
Umsatz 8,9 Mrd. €
Ergebnis 57,2 Mio. €
Mitarbeiter Ø 9.162

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

6. EWE Regionen in Deutschland, Polen, Türkei
6

7. 77
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. 88
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. 99
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. 1010
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. 1111
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. 1212
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. 1313
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. 1414
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. 1515
…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. 1616
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. 1717
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. 1818
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. 1919
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. 2020
Ä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. 2121
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. 2222
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. 2323
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. 2424
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. 2525
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. 2626
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. 2727
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. 2828
Evolution der Feedback-Zyklen
14 Tage
x mal pro Woche
ständig
Konkurrenz-
Produkt
CodeProfiler
ADT mit CP
und anderen
Tools

29. 2929
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. 3030
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. 31
Fragen und Diskussion

32. 32
Kontaktdaten:
Markus.Theilen@ewe.de
@therealtier

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