Titelbild zum Beitrag Clean Code und TDD in SAP-Projekten mit ABAP-Code und TDD-Zyklus.

Clean Code und TDD in SAP-Projekten – Anspruch und Realität

VonStephan

In den letzten Jahren begegnen einem in nahezu jeder Stellenausschreibung und in vielen Projekten die Begriffe Clean Code, Clean Architecture und Test-Driven Development (TDD).

Die Realität in vielen SAP-Systemen sieht allerdings anders aus:

  • 1.000-Zeilen-Methoden
  • Copy & Paste über mehrere Reports hinweg
  • globale Variablen
  • kaum oder gar keine Unit-Tests
  • Business-Logik direkt in Dynpros, BAdIs oder RAP-Handlern

Dabei sind Clean Code und TDD keine akademischen Konzepte. Richtig eingesetzt machen sie den Alltag als Entwickler deutlich einfacher.

Vor allem für Junior-Entwickler können schon wenige Grundregeln einen großen Unterschied machen.

Das Ziel ist nicht perfekter Code

Viele Entwickler machen den Fehler, Clean Code mit möglichst vielen Klassen, Interfaces und Design Patterns gleichzusetzen.

Das ist nicht das Ziel.

Guter Code ist:

  • einfach zu verstehen,
  • einfach zu ändern,
  • einfach zu testen und
  • schwer kaputt zu machen.

Wenn ein Kollege deinen Code in sechs Monaten liest und sofort versteht, was passiert, hast du bereits viel richtig gemacht.

Die drei wichtigsten Clean-Code-Regeln für SAP-Entwickler

1. Kleine Methoden schreiben

Wenn eine Methode nicht mehr auf einen Bildschirm passt, ist sie meistens zu groß.

Schlecht

METHOD save_order.

  " Validierung
  " Preisfindung
  " Statusermittlung
  " Datenbankupdate
  " E-Mail Versand
  " Logging

ENDMETHOD.

Besser

METHOD save_order.

  validate_order( ).

  determine_price( ).

  determine_status( ).

  persist_order( ).

  send_notification( ).

ENDMETHOD.

Die Methode liest sich fast wie eine Dokumentation.

2. Aussagekräftige Namen verwenden

Schlecht

DATA lv_x TYPE c.
DATA lt_data TYPE TABLE.

In sechs Monaten weiß niemand mehr, was das bedeutet.

Besser

DATA lv_is_released TYPE abap_bool.
DATA lt_open_orders TYPE ztt_order.

Der Code erklärt sich selbst.

3. Eine Methode sollte nur eine Aufgabe haben

Schlecht

Die Methode calculate_price:

  • berechnet Preise,
  • liest Stammdaten,
  • schreibt Logs,
  • verschickt E-Mails.

Besser

Die Methode calculate_price berechnet ausschließlich den Preis. Alles andere gehört in eigene Methoden.

Mein wichtigster Tipp für Junior-Entwickler

Wenn ihr eine Methode schreibt, stellt euch folgende Frage:

Kann ich den Methodennamen mit einem „und“ ergänzen?

Zum Beispiel:

Die Methode validiert den Auftrag und verschickt eine E-Mail.

Dann macht die Methode wahrscheinlich zu viel.

Diese einfache Regel hilft erstaunlich oft.

Weniger Copy & Paste

Copy & Paste ist einer der größten Wartungskiller in SAP-Systemen.

Schlecht

SELECT SINGLE *
  FROM kna1
  WHERE kunnr = iv_kunnr.

Derselbe Code an fünf verschiedenen Stellen.

Besser

DATA(ls_customer) = get_customer( iv_kunnr ).

Wenn sich die Logik ändert, müsst ihr nur eine einzige Stelle anpassen.

TDD – Anspruch und Realität

Theoretisch lautet der TDD-Zyklus:

  1. Test schreiben
  2. Test schlägt fehl
  3. Code schreiben
  4. Test wird grün
  5. Refactoring

In vielen SAP-Projekten passiert das nicht.

Und das ist völlig in Ordnung.

Ich kenne kaum Projekte, in denen jede Zeile Code streng nach TDD entstanden ist.

Wo TDD in SAP wirklich sinnvoll ist

Business-Regeln

Zum Beispiel:

  • Preisfindung
  • Statuslogik
  • Berechtigungen
  • Validierungen
  • Berechnungen

Hier sind Unit-Tests Gold wert.

Ein einfaches Beispiel

METHOD determine_discount.

  IF iv_amount > 1000.
    rv_discount = 10.
  ELSE.
    rv_discount = 0.
  ENDIF.

ENDMETHOD.

Der dazugehörige Test:

METHOD should_give_discount.

  cl_abap_unit_assert=>assert_equals(
    act = cut->determine_discount( 1500 )
    exp = 10 ).

ENDMETHOD.

Wenn später jemand die Logik ändert, merkt ihr sofort, ob etwas kaputtgeht.

Wo ich selten Unit-Tests schreibe

Nicht alles muss getestet werden.

Ich schreibe selten Unit-Tests für:

  • einfache CRUD-Anwendungen,
  • reine SELECT-Anweisungen,
  • CDS-Projektionen,
  • Getter und Setter,
  • einfache RAP-Handler ohne Business-Logik.

Der Aufwand sollte immer im Verhältnis zum Nutzen stehen.

TDD pragmatisch einführen

Viele Entwickler denken:

Entweder wir machen TDD komplett oder gar nicht.

Das ist ein Fehler.

Ich empfehle einen schrittweisen Einstieg.

Stufe 1

Schreibt überhaupt Unit-Tests.

Stufe 2

Schreibt Tests für neue Business-Logik.

Stufe 3

Schreibt vor dem Coding zuerst den Test.

Stufe 4

Beginnt mit echtem TDD.

Drei sofort umsetzbare Tipps für Junior-Entwickler

✅ Jede neue Methode sollte möglichst unter 30 Zeilen bleiben.

✅ Wenn ihr Code kopiert, prüft zuerst, ob daraus eine Methode werden sollte.

✅ Schreibt bei jeder neuen Business-Regel mindestens einen Unit-Test.

Wenn ihr nur diese drei Dinge konsequent umsetzt, seid ihr bereits weiter als viele bestehende SAP-Systeme.

Mein persönlicher Ansatz

Ich versuche nicht, jedes Projekt dogmatisch nach Lehrbuch umzusetzen.

Stattdessen stelle ich mir bei jeder Entwicklung drei Fragen:

  1. Ist der Code leicht verständlich?
  2. Ist die Logik einfach testbar?
  3. Kann ein Kollege die Änderung in einem Jahr noch nachvollziehen?

Wenn die Antwort dreimal „Ja“ lautet, ist der Code meistens gut genug.

Fazit

Clean Code und TDD sind keine Religionen.

Sie sind Werkzeuge.

Der beste SAP-Entwickler ist nicht derjenige mit den meisten Design Patterns oder den meisten Unit-Tests.

Der beste SAP-Entwickler schreibt Code,

  • den seine Kollegen verstehen,
  • den er selbst in einem Jahr noch warten kann und
  • der Änderungen möglichst schmerzfrei übersteht.

Und genau dabei helfen Clean Code und TDD.

Wie sind eure Erfahrungen?

Setzt ihr bereits Clean Code und TDD im SAP-Umfeld ein oder scheitert es im Alltag häufig an Zeit, Legacy-Code und Projektprioritäten?

Ähnliche Beiträge