Motivation

Beispiele aus meiner Karriere (1/2)

CIM Fortschreibung

Ein Modul war kaum mehr um neue Features erweiterbar. Alle Änderungen haben extrem lange gedauert. Alles musste nach jeder Änderung durchgetestet werden. Auch bei Fehlerbehebungen.
Ursache:

• Vertrauen in die Korrektheit: 0
• Motivation der Mitarbeiter: 0
• Zufriedenheit des Managements: 0

Trotzdem hatte es lange gedauert, bis das Re-Design dieses Moduls genehmigt wurde.

Abschreckende Beispiele von der SAP - CL_IDENTITY

• 60.313 Zeilen Code
• 357 Methoden, davon
  • 153 öffentlich
    • davon 100 in 10 verschiedenen Interfaces definiert
  • 202 privat
  • 2 Methoden speziell für Unit-Tests:
    • SET_UNIT_TEST_MODE
    • RESET_UNIT_TEST_MODE
• Einige Methoden deutlich über 1000 Zeilen, z.B.
  • cua_get_changes_for_distribute()
  • instantiation_by_mode()
  • nodes_prefetch()

Clean Code in ABAP

Grundsätze

Entkopplung

Abhängigkeiten sollen gering gehalten werden. Wenn ich eine Klasse ändere, sollte das nur innerhalb der Klasse Auswirkungen haben.

Klare Namen

Jede Klasse, Methode, Variable, Tabelle usw. hat Namen, die uns sagen, was wir dahinter erwarten können.

Kleine Einheiten

Eine Methode ist nur so lang, dass man die Übersicht behält. Klassen haben nur die Methoden, die für einen Aspekt relevant sind.

YAGNI - You Ain’t Gonna Need It

Das YAGNI-Prinzip (You Ain ´ t Gonna Need It) ist eines der einfachsten in der Softwareentwicklung – und doch wohl das nach dem DRY-Prinzip am häufigsten verletzte Prinzip
( Clean Code Developer, YAGNI )

Implementiere immer nur das, was heute konkret gebraucht wird. Mögliche, zukünftige Anforderungen werden noch nicht implementiert. Generische Methoden für alle möglichen künftigen Erweiterungen sind zu vermeiden.

Unkonkrete Anforderungen sind kein Grund für Flexibilität, die eigentlich nicht gebraucht wird.

Das führt heute zu schlankerem, einfacherem Code. Es gibt weniger Abhängigkeiten und reduzierte Komplexität.

Nur generisch, wenn das auch gefordert ist

Falls die Flexibilität ein Feature ist, dann muss diese aber auch vollständig spezifiziert sein. Und natürlich auch so dokumentiert und getestet werden.

Namen

Viele Dinge im Quellcode haben Namen:

• Methoden
• Klassen
• Tabellen
• Variablen
• Felder
  ...

Die Qualität der Namen ist wichtig für eine gute Lesbarkeit.

Ungarische Notation

Die Präfixe für Datentypen und Geltungsbereich werden als Ungarische Notation bezeichnet. Ihre Verwendung ist umstritten.

Aussagekräftige Namen

Variablen sollten das ausdrücken, was man erwarten kann.

• Users - Lokale Interne Tabelle mit Benutzerdaten
• InactiveUsers - Lokale Interne Tabelle mit inaktiven Benutzern
• ZCL_USER_MANAGEMENT - Klasse zur Verwaltung von Benutzern

Das Plural-S in den Beispielen weist übrigens auf eine Tabelle hin.

Schlecht sind Namen, die nichts sagen oder verwirren:

• TMP - Temporär - das ist klar. Aber was steht da drin
• VAR_1 - Durchnummerieren ist immer schlecht, das sagt nichts über den Inhalt
• T005T - Der Bezug auf technischen Namen von anderen Objekten ist ungünstig. Orientierung an dem VDM View I_CountryNames ist doch viel hübscher.
• I - Wird gerne als Laufvariable verwendet. Lieber LV_INDEX verwenden...

Abkürzungen

• Nur wenn notwendig verwenden
• Durchgängig verwenden, siehe Domänenbegriffe
• Fokus auf den Unterschied

Methodennamen

In Methodennamen verwenden wir Verben.

• GET_USER
• DEACTIVATE
• DELETE
• CREATE_INSTANCE

Typische Muster sollten mit Präfixen standardisiert werden:

• Zugriffsmethoden auf Variablen mit GET und SET
  • GET_USER
  • SET_USER
• Logische (Boolsche) bzw. Prädikatsmethoden mit IS
  • IS_USER_ACTIVE
• Prüfungen, ob eine Bedingung erfüllt ist mit CHECK. Falls nein wird hier eine Ausnahme ausgelöst.
  • CHECK_PERIOD

Konstante

• Zentral definieren
• Gleichartige Konstanten in einer Struktur unterbringen

    TYPES t_rgb TYPE c LENGTH 7.
    CONSTANTS: BEGIN OF cs_color,
                 red   TYPE t_rgb VALUE '#FF0000',
                 green TYPE t_rgb VALUE '#00FF00',
                 blue  TYPE t_rgb VALUE '#0000FF',
               END OF cs_color.

• Enumerations verwenden - die kommen später noch

TODO Kommentare

Schlüsselwörter in Kommentaren, die den weiteren Entwicklungsprozess steuern sollen sind auch möglich. Durch Konventionen kann man ihnen eine einheitliche Bedeutung geben und gezielt danach suchen.
Beispiele:

• FIXME - Markierung eines Fehlers, der behoben werden sollte. Warum macht man das nicht gleich?
• TODO - Hier fehlt noch etwas im Code. Das muss aber noch vor der Freigabe des Codes erledigt werden.
• XXX - Funktioniert fehlerfrei, kann aber noch verbessert werden.

Bitte diese nur verwenden, wenn

1. das im Team einheitlich verwendet wird und
2. die Kommentare auch abgearbeitet werden. Dazu sollte es einen Nächtlichen Testlauf geben, der die Kommentare zählt.

Ansonsten ist das pure Prokrastination von Arbeit.

Beispiele für Formatierung - vorher und nachher

SELECT CASE WHEN ls_tmax_ut > '000000000000000' and ls_tmax_ut < '99991231235959' THEN
CAST ( TO_VARCHAR( UTCTOLOCAL( TO_TIMESTAMP (
SUBSTRING( :ls_tmax_ut,1, 12  )
|| REPLACE(SUBSTRING( :ls_tmax_ut, 13, 2  ), '60', '59' )
), 'CET' ), 'YYYYMMDDHH24MISS' ) as DEC ( 15,0 ) )
ELSE CAST ( :ls_tmax_ut as DEC ( 15,0 ) ) END
INTO ls_tsmax_lt FROM DUMMY;

SELECT CASE WHEN ls_tmax_ut > '000000000000000' 
             and ls_tmax_ut < '99991231235959' 
             THEN CAST ( TO_VARCHAR( UTCTOLOCAL( TO_TIMESTAMP ( SUBSTRING( :ls_tmax_ut,
                                                                           1, 
                                                                           12  
                                                                ) || REPLACE( SUBSTRING( :ls_tmax_ut, 
                                                                                       13, 
                                                                                       2  
                                                                               ), 
                                                                            '60', 
                                                                            '59' 
                                                                     ) 
                                                  ), 
                                                  'CET' 
                                        ), 
                          'YYYYMMDDHH24MISS' ) as DEC ( 15,0 ) )                         
             ELSE CAST ( :ls_tmax_ut as DEC ( 15,0 ) ) 
          END
INTO ls_tsmax_lt FROM DUMMY;

Wrapper um andere Module

Wenn wir in unseren Programmen an 100 Stellen die gleichen Methoden eines anderen Moduls( oder Framework, Projekt, Produkt, ...) aufrufen, dann sollten wir diese Kapseln. D.h. wir bauen eine Klassen, die das andere Modul repräsentiert.

Damit haben wir nur noch eine Klasse, die von dem anderen Modul abhängt. Änderungen im anderen Modul können an einer Stelle zentral ausgeglichen werden. Das andere Modul hat nur eine Abhängigkeit statt 100.

Whiteboard

Eine Methode arbeitet nur auf einer logischen Ebene

Single Level of Abstraction (SLA)

Anweisungen können auf unterschiedlichen logischen Ebenen liegen. Beispielsweise

• Zeichenketten zusammensetzen
• SELECT Anweisung
• Aufruf von anderen Methoden
• COMMIT WORK

Wir sollten innerhalb einer Methode immer nur auf einer logischen Ebene arbeiten. Das erhöht die Lesbarkeit und erleichtert es, passende Namen für die Methoden zu finden.

Wenige Parameter verwenden

Je weniger Parameter eine Methode hat, desto besser lässt sie sich testen. Wenige Parameter helfen auch beim Verständnis einer Methode.

Wenn Parameter zusammengehören, können diese auch in einem Objekt oder in einer Struktur gebündelt werden.

Statt optionaler Parameter sollte lieber eine neue Methode angelegt werden.

Auch für Boolsche Parameter gilt: Einfach zwei Methoden anlegen.

Wenn eine Methode mehrere EXPORTING Parameter hat, dann macht sie sicherlich mehrere Dinge. Das widerspricht der Forderung, dass eine Methode nur eine Aufgabe haben soll.

Am besten wird ein RETURNING Parameter verwendet. Dieser sollte den Namen RESULT haben.

Objektorientierte Prinzipien

• Instanzmethode über statische Methoden
• Komposition über Vererbung
• Liskov Substitution Principle

Prinzip der Schnittstellentrennung

Interface Segregation Principle (ISP)

Wenn wir keine konkreten Klassen sondern Interfaces referenzieren, dann können diese flexibel ausgetauscht werden. Entweder zu Testzwecken oder weil es irgendwann eine weitere Implementierung gibt.

Interfaces sollen nur die Methoden enthalten, die Verwender wirklich benötigen. Lieber mehrere Interfaces definieren, die dann von einer Klasse implementiert werden.

Performance (1/2)

Premature optimization is the root of all evil

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
( Donald Knuth )

Rules of Optimization:
Rule 1: Don’t do it.
Rule 2 (for experts only): Don’t do it yet.
( M.A. Jackson )

More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason – including blind stupidity.
( W.A. Wulf )

Legacy-Code - Der alte Sch...

Der Begriff „Legacy Code“ wird in der Software-Technik verwendet und bedeutet übersetzt so viel wie „Altcode“. Dabei handelt es sich um älteren Code, der in der Regel nicht mehr aktiv weiterentwickelt wird. ( Ionos Website )

• Wir fassen alten Code nur an, wenn dort Änderungen notwendig sind.
• Jedes Mal wenn man dort etwas ändern muss, kann man Kleinigkeiten optimieren. Auch "Pfadfinder Regel" genannt.
• Neuen Code grundsätzlich nach Clean Code Prinzipien aufbauen.

Und wie geht es weiter?