„Konventionen sind gut“ oder „Was den Braten zarter macht…“

Blog – Technik und Methoden
Verfasst von Stefan Geidies am 5. Oktober 2018

Eine Konvention ist eine Regel, die von einer Gruppe von Menschen aufgrund eines beschlossenen Konsenses eingehalten wird (frei nach wikipedia). Als Entwickler kommt man zwangsläufig und häufig in Kontakt mit Konventionen. Das ist bekannt und wohl unstrittig. Es gibt sie als Designregel, bei der Organisation von Dateien, als Namenskonventionen, bei Kommentaren, dem Einrücken von Code, Leerzeichen, Klammern, … aber darum soll es an dieser Stelle nicht gehen.

Konventionen einzuhalten führt üblicherweise zu vielerlei positiven Effekten. Manch Dokumentation behauptet sogar, jede Konvention sei besser als gar keine. Vorteile bei der Anwendung von Konventionen sind unter anderem:

  • Die Lesbarkeit und somit die Wartbarkeit von Code wird erhöht. Der Codebestand kann demnach leichter von verschiedenen Programmierern (gleichzeitig und auch nacheinander) verwaltet und weiterentwickelt werden. Es gibt nur wenige Programme, die von der ersten Zeile bis zum letzten Wartungszyklus vor dem Verschwinden der Software durchgängig von denselben Programmierern entwickelt werden. Dieser Vorteil ist besonders bei der Entwicklung von Software in einem Team von großer Bedeutung.
  • Aber auch mit Blick auf die Wartung und Pflege von Software gibt es gute Gründe. Die Verwaltung einer Software nimmt auf lange Sicht deutlich mehr Zeitaufwand in Anspruch als die Entwicklung. Dokumentierte Werte liegen da teilweise bei ca. 60 – 80% des Gesamtaufwandes. Konventionen helfen auch hier, Zeit und Geld zu sparen.
  • Sind die jeweiligen Konventionen in „Fleisch und Blut“ übergegangen, stellen sich viele Fragen einfach nicht mehr.

Die Aufzählung wird sicher gerade gedanklich von Euch noch um einige Punkte erweitert. Und auch darum soll es an dieser Stelle gar nicht gehen. Stattdessen möchte ich eine kleine Geschichte erzählen:

Was den Braten zarter macht…

Meine Frau bereitet zum Wochenende manchmal einen leckeren Schweinebraten zu. Ich habe sie letztens dabei beobachtet und festgestellt, dass sie die Ecken abschneidet, bevor der Braten in den Topf und dieser dann in den Ofen kommt. Ich habe sie gefragt: „Warum schneidest Du denn die Ecken ab?“ Sie hat geantwortet: „Der Braten wird zarter, die Soße wird dunkler, und meine Mama macht das auch so.“

Ich habe dann bei Gelegenheit meiner Schwiegermutter dieselbe Frage gestellt. Meine Schwiegermutter antwortete: „Ist doch klar. Der Braten wird zarter, die Soße wird dunkler und meine Mutter macht das auch so.“

Also ging ich zu ihrer Mutter und fragte: „Großmutter, warum schneidest Du die Ecken vom Braten ab, bevor er in den Ofen kommt?“ Großmutter antwortete: „Damit er in den Topf passt.“

Wir sprechen bei der Anwendung von Konventionen über Software und Qualität. Um die Qualität der von uns entwickelten Software zu erhöhen, wenden wir (unter anderem) Konventionen an. Man könnte gar glauben, je mehr, desto besser.

Auch wenn es auf den ersten Blick so wunderbar einfach aussieht, verbirgt sich der Teufel im Detail. Wende ich die jeweilige Konvention an, weil sie einen Mehrwert bringt, oder um der Konvention willen? Also im übertragenen Sinne, damit der Braten in den Topf passt (realer Mehrwert), oder damit die Soße dunkler wird (imaginärer Mehrwert)?

Noch einmal anders ausgedrückt: Ist die Konvention, die ich gerade anwende, aus einem Qualitätsbewusstsein heraus richtig und sinnvoll, oder ist es eher so etwas wie Selbstbefriedigung? Und weiß ich es vielleicht nicht einmal?

Die Antwort auf diese Frage könnte man mit der oben erwähnten Direktive beantworten: „Jede Konvention ist besser als keine.“ Wäre da nicht ein Kunde mit seinem Recht auf effizienten Einsatz seiner Ressourcen.

Fakt ist, durch das Festlegen und Anwenden von Konventionen kann man die Qualität zu entwickelnder Software signifikant erhöhen. Es gibt Konventionen mit hohem, mit weniger hohem und mit eher imaginärem Mehrwert. Deswegen ist es nicht nur wichtig, Konventionen zu kennen und anzuwenden, sondern auch zu wissen warum. Nur dann kann man entscheiden, ob und mit welchem Mehrwert sie die Qualität der Software erhöhen. Dies gilt dann im jeweiligen Kontext und für das entsprechende Projekt und sollte immer eine bewusste Entscheidung sein.

Und der nächste konsequente Schritt ist, festzulegen, wie weit man dies alles treiben will. Nicht jede Konvention ist es wert, in jedem Projekt perfekt umgesetzt zu werden. Je weiter ich die Qualität verbessern will, desto höher wird mein Aufwand. Und der Aufwand für das Prädikat „Perfekt“ geht gegen unendlich. Meist ist dieser Vorgang jedoch über ein „Budget“ begrenzt, womit klar sein sollte, dass diese Aspekte einen sinnvollen Abgleich zueinander benötigen.

Jetzt könnte man meinen, als Entwickler muss ich mich nur um die Qualität meiner Software kümmern. Budget ist nicht meins, das machen andere. Da wir aber im Idealfall in selbstorganisierten agilen Teams arbeiten, ist die Effizienz des Teams in Summe sehr wohl ein Thema für alle.
Oder etwa nicht?

Fragen über Fragen, vielleicht als Themen zur Diskussion oder für weitere Posts?!

  • Wie kommen neue Kollegen an die benötigten Infos über im Haus oder im jeweiligen Projekt angewendete Konventionen und „best practices“?
  • Gibt es eine übergreifende, aktuelle Sammlung (sinnvoller) Konventionen?
  • Gibt es einen Austausch über Projekt-/Teamgrenzen hinweg?
  • Was macht man mit Projekten, deren Budget nicht das Qualitätsbewusstsein des agierenden Teams widerspiegelt? Auf Qualität verzichten? Aufwand in der Entwicklung sparen und damit in die Wartungsphase verschieben (und die Kundenzufriedenheit beziehungsweise letztendlich den Verlust des Kunden riskieren)? Auf das Projekt verzichten?

 

Herzliches Knuddeln als Danke für die Hilfe beim Redigieren geht an Marion, Lena und Tammo 😉