Eine gemeinsame Sprache: Coding Guidelines in Software Engineering

Coding Guidelines sind für alle Teams relevant

Lok Lam, klär uns auf, braucht jeder Coder eigene Coding Guidelines?

Im Studium schreiben viele von uns alleine an ihren Programmen. Selbst verstehen wir den Code natürlich ganz gut. Erst sobald mehrere Personen an einem Code arbeiten, merkt man: „Okay, wir brauchen gewisse gemeinsame Regeln.“ Alle müssen beispielsweise Konventionen, etwa beim Naming, einhalten. Dann verstehen später auch diejenigen das Programm, das sie nicht selbst geschrieben haben.

Bei Capgemini arbeiten sehr erfahrene Programmierer*innen. Nutzen sie auch solche Programmierrichtlinien?

Auf jeden Fall. In meinem derzeitigen Projekt schreiben zweihundert Menschen an einem Programm. Ich nutze gerne folgendes Beispiel zur Veranschaulichung: Stell dir vor, wir würden gemeinsam ein Bild malen, wobei jeder ein kleines Fleckchen Leinwand koloriert. Am Ende trittst du als Projektmanager vor das Bild und siehst, dass absolut nichts zusammenpasst. Coding Guidelines sind wie die Anleitung, in welchem Stil gemalt wird, damit am Ende ein harmonisches Gesamtbild entsteht.

Zweihundert Entwickler*innen auf ein einheitliches Vorgehen zu fokussieren ist bestimmt eine Herausforderung.

Das ist es manchmal, aber der Austausch in einem solchen Team ist sehr inspirierend. Vor allem, weil wir international zusammenarbeiten. Einige von uns sitzen in Deutschland, andere in Polen und Indien. Alle arbeiten an einer zentral abgelegten Codebasis. Den Code, den einzelne Entwickler*innen schreiben, laden sie in ein solches Repository hoch. Da ist es elementar wichtig, dass die einzelnen Elemente – wir sprechen hier von Modulen –, die von verschiedenen Entwicklern geschrieben werden, exakt zueinander passen.

Gibt es in der Branche Best Practices, an die sich jeder hält? Oder sind eure Coding Guidelines so gesehen Capgemini-spezifisch?

Das Spannende ist, bei Capgemini haben wir gar keine starren Coding Guidelines, die für alle Projekte gelten, da wir für so unterschiedliche Kunden aus verschiedenen Branchen Projekte realisieren. Wir haben aber ein Grundgerüst, damit alle Projekte ähnlich gebaut sind. Das ist sehr wichtig, weil wir ja oft zwischen Projekten wechseln. Anhand dieses Grundgerüsts kann jemand Neues sich sehr schnell in ein Projekt einarbeiten.

Was zeichnet dieses Grundgerüst für Coding Guidelines aus? Kannst du uns Beispiele nennen?

Zum Beispiel unser Vier-Augen-Prinzip. Jede Codezeile wird von einem Kollegen oder einer Kollegin geprüft, damit sie am Ende nicht gegen das Regelwerk verstößt. Auch eine vernünftige Dokumentation ist selbstverständlich. Modulare Programmierung ist uns ebenfalls wichtig: Wir arbeiten mit kleinen, gut strukturierten Codeblöcken, die sich in verschiedenen Kontexten wiederverwenden lassen.

Objektive Kriterien für eine gute Codequalität

Was sind die spezifischen Merkmale, die in Coding Guidelines gefordert werden?

Da wären Testbarkeit und Wartbarkeit. Beide zeichnen guten Code aus. Hier spielt zum einen die Modularisierung hinein: Wir verzichten auf  tausend Zeilen Code und coden stattdessen sinnvoll gegliederte und idealerweise wiederverwendbare Abschnitte. Außerdem muss der Code leicht verständlich sein – ich würde sogar sagen: selbsterklärend.

Wann würdest du von einem selbsterklärenden Code sprechen?

Es geht darum, Code zu schreiben, der möglichst einfach ist. Idealerweise ist die Logik, beispielsweise einer Methode, bereits am Namen zu erkennen. Dann müsste man nur in Ausnahmefällen einen Kommentar hinzufügen, der erklärt, warum der Coder einen ungewöhnlichen Code programmiert hat. Ich würde sagen, je weniger Kommentarbedarf ein Code hat, desto besser.

Wenn Code selbsterklärend sein soll, deutet eine umfassende Dokumentation dann auf schlechte Codequalität hin?

Nein, das nicht. Aber überall dort, wo die Entscheidungen von Codern nicht eindeutig nachvollziehbar sind, ist eine Dokumentation notwendig. Wenn wir aus Performancegründen komplizierte Befehle schreiben, dann ist es wichtig, unseren Gedankengang dahinter zu dokumentieren. Die Dokumentation ist außerdem noch der Ort, an dem Schnittstellen nach außen sichtbar gemacht werden müssen.

Nachhaltigkeit als Merkmal der Codequalität

An welchen Merkmalen misst du die Codequalität sonst noch?

Für mich sollte Code nicht nur leicht zu warten sein, sondern gerne auch erweiterbar. Ich halte das für eine Frage der Nachhaltigkeit. Tausende Zeilen Code sind kaum mehr wartbar. Deshalb empfiehlt es sich, lieber kleinere Abschnitten zu coden, die sich mehrfach nutzen lassen. Bei Capgemini wollen wir so coden, dass sich ein Programm auf ähnliche Business Cases übertragen lässt. Außerdem stellt die sogenannte Boy-Scout-Rule, auf die sich jede*r Entwickler*in committen sollte, nachhaltig die Codequalität sicher.

Handelt es sich bei der Boy-Scout-Rule um eine Art Pfadfinder-Regel für Entwickler*innen? 

Genau, die Boy-Scout-Rule ist eine übergeordnete Regel, ich möchte sogar sagen: die goldene Regel für alle Entwickler*innen. „Lass den Code in besserem Zustand zurück, als du ihn vorgefunden hast.“ Wenn jemand einen fremden Code durchgeht, etwa eine Erweiterung schreibt, und erkennt, dass etwas nicht optimal geschrieben ist, dann verbessert er oder sie die betreffende Stelle. Wie eine dieser guten Taten, die Pfadfinder*innen für das Team leisten.

Coding Guidelines und weitere Freiheiten: Arbeiten bei Capgemini

Du erwähntest bereits, dass es kein allgemeingültiges Set an Coding Guidelines bei Capgemini gibt. Habt ihr eher Coding Guidelines für Java, Coding Guidelines für Python, und so fort?

Genauso musst du dir das vorstellen. Manche Kolleg*innen coden da klassisch mit Java, andere arbeiten schon Cloud-basiert. Somit variiert der Fokus immer wieder. Genau diese Vielseitigkeit ist ein Grund, neben vielen weiteren, weshalb ich meinem Job bei Capgemini mag. Hier probieren wir Vieles aus. Beim Wechsel zwischen unterschiedlichen Projekten lerne ich verschiedene Branchen kennen und bleibe trotzdem bei einem Arbeitgeber. Diese Abwechslung mag ich sehr.

Bildet Capgemini euch in dieser Hinsicht auch aktiv weiter?

Bei Capgemini wird grundsätzlich viel Wert auf lebenslanges Lernen gelegt. Hierzu haben wir ein breites Fortbildungsangebot sowohl von internen als auch externen Schulungen und Zertifizierungen. Dabei geht es nicht um Coding Guidelines im engeren Sinne, aber um Design Principles. Was sind allgemein anerkannte Designprinzipien? Welche Design Patterns gibt es?

Zudem haben wir bei Capgemini sowohl eine deutschlandweite, als auch eine lokale Engineering-Community. Ich organisiere beispielsweise von meinem Standort Hamburg aus die Hamburger Engineering Community. Hier tauschen wir uns über technische Themen aus, aber auch über Möglichkeiten zur persönlichen Weiterentwicklung.

Hier dürfen Bewerber*innen ihr Coding-Talent im Team einbringen

Zieht dieses Klima bestimmte Bewerber*innen an, die bei Capgemini arbeiten wollen?

Die meisten Kolleg*innen haben eines gemeinsam: Große Offenheit und die Bereitschaft, Neues zu lernen. Das wünschen wir uns auch von Bewerber*innen bei Capgemini. Fast noch höher bewerten wir aber den Teamspirit. Wir sind eine fachlich breit aufgestellte Truppe, sehr vielfältig und divers, mit vielseitigen Stärken. Jeder Kollege und jede Kollegin kann sich hier voll einbringen. Darauf sollten Bewerber*innen Lust haben, Spaß an kniffligen Aufgaben mitbringen und Leidenschaft für die Ziele des Teams entwickeln.

Welches Vorwissen erwartet ihr von Bewerber*innen beim Job-Einstieg?

Die meisten Einsteiger*innen bringen Grundlagenwissen aus dem Studium mit, zum Beispiel mindestens eine Programmiersprache und der Umgang mit Datenbanken. Erste praktische Erfahrungen sind natürlich immer gut, vor allem wenn man schon einmal eine Entwicklungsumgebung gesehen hat. Aber unsere Teams nehmen alle, die neu dazukommen, bestmöglich an die Hand. Das wichtigste lernt man auch im Job. Insgesamt glaube ich: Wenn Anfänger*innen logische Denkweisen beherrschen und schwer zu lösende “große” Probleme in kleine lösbare Probleme herunterbrechen und aufteilen können, dann arbeiten sie sich auch schnell in den Rest ein.

Viele Bewerber*innen suchen genau das Umfeld, das du beschrieben hast. Willst du ihnen noch etwas persönliches mitgeben?

Ich möchte Bewerberinnen und Bewerbern gerne sagen, dass ich nur wenige Unternehmen kenne, die sich wie Capgemini für die Entwicklungsmöglichkeiten ihrer Mitarbeitenden einsetzen. Capgemini entwickelt sich auch selbst ständig weiter, um uns neue Perspektiven zu eröffnen. Ein gutes Beispiel ist der aktualisierte Karrierepfad im Unternehmen, der für Software Engineers vorgesehen ist. Capgemini hat das Potenzial der Entwickler*innen erkannt und neue Aufstiegsmöglichkeiten geschaffen. So können Softwareingenieur*innen jetzt über die Senior- bis zur Managing-Ebene aufsteigen. Das empfinde ich als eine große Wertschätzung durch unseren Arbeitgeber.

Vielen Dank für das spannende Gespräch über Coding Guidelines und deine Arbeit bei Capgemini, Lok Lam.

Wollen auch Sie Ihr Coding-Talent in vielfältigen Projekten einbringen? Dann werden Sie Teil des Capgemini-Teams. Bewerben Sie sich als (Junior) Software Engineer (w/m/d) oder IT-Architekt (w/m/d). Weitere offene Stellen finden Sie in unserem Jobportal.