Umfrage 1

Wie viel Zeit verwendet Ihr täglich , um Code zu schreiben?

Nur schreiben ohne

• Meetings
• Dokumentation erstellen
• Testen
• Konzepte schreiben
• Bestehenden Code analysieren, z.B. wegen Wartungsaufgaben (Debugging, Performance Optimierungen etc. )

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.

Die Sprache ABAP

Jede Programmiersprache ist anders - auch ABAP.

Besonderheiten von ABAP

• Viele obsolete oder veraltete Konstrukte
• Sehr großer Sprachumfang
• Viele Anweisungen und Schlüsselwörter
• Begrenzungen bei der Länge von Klassen-, Methoden- und Tabellennamen
• Alles muss 100% Abwärtskompatibel sein.
• Anweisungen und Funktionsaufrufe sind teilweise sehr groß und gehen über viele Zeilen.

Darum müssen die Clean Code Prinzipien aus dem gleichnamigen Buch an die Sprache angepasst werden.

Granularität

Damit man den Quellcode gut erfassen kann, muss man auf allen Ebenen sauber und sorgfältig arbeiten.

Ebenen

DRY - Don't Repeat Yourself

Wiederhole dich nicht. Wenn der exakt gleiche Code mehrfach vorkommt, machen wir etwas falsch!

Sobald man etwas noch einmal braucht, sollte man sich überlegen, wie man eine wieder verwendbare Logik implementieren kann.

KISS - Keep it simple, stupid

Alles sollte so einfach wie möglich gemacht werden, aber nicht einfacher.
(Albert Einstein)

Bei mehreren Optionen entscheiden wir uns immer für die einfachere, klarere und verständlichere.

Ungarische Notation

Die Präfixe für Datentypen und Geltungsbereich sind umstritten. Weil diese meines Wissens bei der Bahn aber üblich sind, werde ich diese verwenden:

Bei kleinen Codeeinheiten ist die ungarische Notation nicht notwendig, weil sie dort keinen Mehrwert bietet. Sie steht aber einem einfachen Refactoring entgegen.

Aussagekräftige Namen

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

• LT_USERS - Lokale Interne Tabelle mit Benutzerdaten
• LT_INACTIVE_USERS - 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
• T004T - Der Bezug auf technischen Namen von anderen Objekten ist ungünstig
• 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?