Code-Qualität? Klar doch, ich baue meine Sachen immer gut. Soll ja jeder damit arbeiten können, deshalb auch keine überflüssigen Berechtigungsprüfungen.
Umfassend testen? Kann man später immer noch. Erstmal fertigmachen.
Richtlinien beachten? Arbeite ich dran. Wann immer Zeit ist, aber leider haben wir es oft eilig…
Die Doku reiche ich nach, die braucht im Moment sowieso noch keiner.
F4-Hilfe? Ja … stimmt. Wäre wahrscheinlich gut. Aber andererseits – damit arbeiten ja eh nur Leute, die wissen, was man in das Eingabe-Pflichtfeld P_DODEL eingeben muss. (Day of Delivery ist das!)

Jeder kennt das. „Code-Qualität? Total wichtig! Aber …

Dieser Blogbeitrag soll Entwicklerinnen, Entwicklern und Produktverantwortlichen helfen, den Sinn von Code-Reviews sowie einige Punkte daraus näher kennenzulernen. Denn wie sieht es mit den Problemen aus, die eine nicht reviewte Entwicklung bereiten kann?

Ganz einfach: die Entwicklung leistet nicht, was sie soll, ist nicht performant und nicht sicher, bietet weder Hilfen noch Dokumentation an, ist schlecht strukturiert,

Konsequenz: solche Entwicklungen sind weder gut bedienbar noch gut wartbar, aber fehleranfällig und problembehaftet. Daraus geht u.U. weiterer erheblicher Aufwand hervor. Daher sind sie auch noch teuer! Und am Ende ist niemand zufrieden, nicht einmal die Entwickler, vor allem aber nicht die Kunden!

Ein Code-Review, der spätestens vor einer „offiziellen Testphase“ erfolgen muss, hilft allen Beteiligten, Softwareentwicklungen qualitäts- und sicherheitstechnisch zu prüfen und ggfs. zu optimieren, um insgesamt zu einer besseren, sicheren Lösung zu kommen – und einen Lerneffekt bei allen Beteiligten zu erzielen.

Im Idealfall wird ein Code-Review jedes Mal schneller ablaufen,  z. B. wenn problematische Konstrukte erkannt und nicht immer wieder neu verwendet werden und weil die Richtlinien zunehmend verinnerlicht werden.

Sinn und Ziel von Code-Reviews

Wie schon im Blogbeitrag zum Threat-Modeling geschrieben wurde:

Das Ziel von Prüfungen in der Softwareentwicklung ist stets Verfügbarkeit, Verlässlichkeit und Vertraulichkeit des Systems zu wahren. Diese drei Prinzipien dürfen durch keine Softwareentwicklung bzw. Applikation beeinträchtigt werden.

Daher muss man neue Entwicklungen bzw.  deren Codestrecken genau daraufhin prüfen, dass sie diese Prinzipien nicht beeinträchtigen.

Konkrete Absichten, Fragen, Durchführung:

  • Verbesserung durch gemeinsame Arbeit
    Einen Code Review sollte jede/r Entwickler/in mindestens einmal im Jahr erleben bzw. anfordern.
  • Verbesserung durch Erklärung des Codes
    Programme und Code, die man anderen zeigt und erklärt, sieht man in dem Moment selbst auch anders. An dieser Stelle erfolgt dadurch schon die Klärung der Frage: Macht der Code, was er soll?
  • Verbesserung durch Zuhören
    Die Reviewer können sagen, was vielleicht noch fehlt und besser gemacht werden kann!
  • Verbesserung durch gemeinsame Standards
    Wurden die Richtlinien eingehalten (bei internen wie externen Entwicklungen)?
    Ist der Code übersichtlich?
  • Verbesserung durch Performance-Maßnahmen
    Man kann aus dem Code heraus Aussagen über die Performance treffen, wenn bestimmte Konstrukte und Verfahrensweisen beachtet werden.

    • Beispiel 1:
      Keine Select * from [dbtab], sondern nur der erforderlichen Felder und
      keine wiederholten identischen Selects, sondern READ from [itab]
    • Beispiel 2:
      Anwendung des PUSH-DOWN-Vorgehens durch Verwendung von CDS-Views
    • Generell beim Ablauf in einem System mit realistischen Daten:
      Performance-Trace ausführen und analysieren
  • Verbesserung durch bessere Beschreibung
    Existiert eine Dokumentation und sind Eingabefelder mit [F1] und [F4]-Hilfen versehen?
  • Verbesserung durch mehr Sicherheit
    Sind z.B. Berechtigungsprüfungen vorgesehen?
    Sind Pflegeviews mit einer Tabellenberechtigungsgruppe verbunden, damit nicht jeder Daten verändern kann?
  • Verbesserung durch Tests und Fehlerbehandlung
    Sind die Prüfergebnisse formalisierter Tests OK? => Mindestens keine Fehler mit Prio 1 in den Werkzeugen „Erweiterte Syntaxprüfung (SLIN), ABAP Test Cockpit (ATC) oder Code Inspector( CI)?
    Sind Unit-Tests vorhanden?

Code Review: Was wird dabei betrachtet?

Hier eine Übersicht der Checkliste des Templates der Inwerken-Entwicklungs-Fachgruppe Code-Review.

Ressourcen beachten

Es soll noch erwähnt werden, dass generell die Funktionalität ebenso auf Sicherheit, wie auch dahingehend geprüft werden muss, dass sie nicht zu viele Ressourcen des SAP-Systems verschlingt. Wenn eine Abfrage fachlich richtig ist, aber zu viele Ergebnissätze findet, kann sie das System womöglich beeinträchtigen. Die Antwortzeiten sind dann zu lang oder das System antwortet gar nicht mehr.
Wird z.B. zu viel Speicher verbraucht oder werden zu viele Sperren gesetzt und gehalten, werden andere Benutzerinnen und Benutzer behindert.

Ergebnisse im Rahmen eines Code-Reviews

Am Ende eines Code-Reviews mit Checkliste steht idealerweise ein OK für die Code-Qualität der Entwicklung. Oder eine Liste von Maßnahmen wird beschlossen, die zur Verbesserung der Code-Qualität durch den Entwickler/die Entwicklerin durchgeführt und von Reviewern nachkontrolliert werden.

Zusammengefasst:

Ein Code-Review in der Softwareentwicklung soll seinen Teil dazu beitragen, die wichtigsten Erfordernisse der Entwicklung zu erfüllen: Sachangemessenheit, Einhaltung vorgegebener Richtlinien und Sicherheitsstandards, Les- und Wartbarkeit des Codes.

Er tut dies durch die Verfolgung des oben dargestellten Ansatzes zur Prüfung der Softwareentwicklung und ermöglicht die Besprechung von allgemeinen Qualitäts- und Sicherheitsstandards aus unterschiedlichen Bereichen.

Das Ziel ist stets in einem der aktuellen Entwicklung angemessenen Rahmen größtmöglichen Codequalität zu gelangen. Kundenzufriedenheit und Wirtschaftlichkeit sind zu beachten – wobei aus Kundenzufriedenheit auch neue Projekte entstehen können, weshalb sie auch höher zu priorisieren ist.