Programmieren ist (k)ein Hobby

Die ganze Nacht durch programmieren, viele Energy Drinks und die gute alte Bildschirm-Bräune. Klischees über Nerds gibt es viele, jedoch sind diese keine Gewohnheiten im Arbeitsalltag eines (guten) Programmierers. Dieser Artikel richtet sich an alle Programmierer und die, die es mal werden wollen. Als kleine Stütze, um nicht dieselben Fehler zu begehen, die ich einst begangen habe und die sich leider immer noch ab und zu einschleichen.

1. DRY – Don't Repeat Yourself

Sicherlich hast du dich schon einmal in der Situation vorgefunden, in welcher du dachtest: "Hey, dieser Code-Abschnitt sieht ähnlich aus wie in Zeile 132..."

Da sollten sofort die Alarm-Glocken läuten – denn doppelten Code gilt es zu vermeiden. Doppelt vorkommende Funktionen oder Codes machen dein Programm aufwendiger in der Pflege, denn wenn in diesem Stück Code Anpassungen vorzunehmen sind, müssen diese an vielen verschiedenen Stellen ebenfalls nachgepflegt werden. Hierdurch ist die Wahrscheinlichkeit, dass sich ein Bug im Code einschleicht, deutlich erhöht.

Als gute Praxis gilt die DRY [2] Methode. Das bedeutet, sobald du dich dabei ertappst, wie du einen Code zum zweiten Mal schreibst, solltest du mit der Refaktorierung des Codes beginnen. Unterteile deinen Code in kleine Abschnitte und Funktionen, die du innerhalb deines Programms aufrufen kannst.

2. Wenn du glaubst, du bist fertig – Code refaktorieren!

Die meisten Programmierer – vor allem die mit weniger Erfahrung – denken oft ihr Programm ist fertig, sobald ihr Programm funktioniert. Aber im Wörtchen "fertig" steckt mehr als nur ein bisschen Code für ein cooles Feature.

Jetzt denkst du bestimmt: "Hauptsache, das Ding funktioniert, oder?"

Korrekt. Aber bevor du dich jetzt der nächsten Aufgabe widmest, solltest du dennoch deinen Code überarbeiten – im Fachjargon nennen wir dies Refactoring[3]. Das Überarbeiten (Refaktorieren) deines Code verbessert dessen Lesbarkeit deutlich. Dein Code muss vielleicht nicht der sauberste der Welt sein. Doch Formulierungen, die für dich selbstverständlich, sind es für andere Programmierer unter Umständen nicht. Ergo stell dir stets die Frage: Was denken wohl andere Entwickler, wenn sie diesen Code lesen? Ist er verständlich und logisch? Sei kritisch dir selbst gegenüber!

Der nachfolgende Code ist ein sehr einfaches Beispiel für eine Code-Refaktorierung. Es geht nicht nur um einen effizienteren Aufbau und die Dezentralisierung von Funktionen, sondern auch um Grundlagen z.B. das effektive Anwenden von nativen Methoden der jeweiligen Programmiersprache.

Ein Code-Schnipsel aus dem Javascript Bereich:

Das gleiche Ergebnis (Output) kann man auch mit nur einer Zeile Code erreichen:

Ein refaktorierter Code hilft auf jeden Fall die Komplexität zu vereinfachen und eine erhöhte Wartungsfreundlichkeit zu gewährleisten. Auf lange Sicht macht sich die Refaktorierung auf jeden Fall bezahlt.

3. Der Business-Fokus

Programmierer neigen dazu, sich zu sehr auf den technischen Part ihres Jobs zu fokussieren – z.B. eine neue Programmiersprache zu lernen oder eine neue Javascript Bibliothek zu testen. Hierbei gerät oft das Business aus dem Blickfeld. Auf dem Weg zum Meister deines Faches ist es wichtig, sein eigenes Geschäftsfeld im Auge zu behalten. Warum programmierst du?

Leider ist es so, dass manchem Programmierer die wirtschaftlichen Faktoren seines Tuns nicht interessieren, sie bilden jedoch die existenzielle Grundlage ihrer Arbeit.

Stelle dir selbst also immer mal wieder die 100.000-Euro-Frage:
Arbeite ich an etwas, dass meinem Geschäft einen finanziellen Mehrwert bringt?

4. Commit-Häppchen – das Horsd’œuvre der Nerds

In der Programmierung ist es ratsam eine Versionskontrolle wie z.B. GIT[4] einzusetzen. Dies ermöglicht es mehreren Programmierern gleichzeitig dezentral an einem Code zu arbeiten, Änderungen zu protokollieren und damit nachvollziehen zu können. Jedes mal, wenn ein Programmierer eine Änderung im Code vornimmt und diese dem Projekt hinzufügt, sprechen wir von einem Commit.

Dein Code lässt sich bei kleineren Commits auch schneller debuggen. Es ist einfacher, vorangegangene kleine Commits zu prüfen, durch die sich eventuell ein Bug eingeschlichen haben könnte. Sobald der "verbuggte Commit" gefunden wurde, gibt es weniger Code zu inspizieren, welcher den Bug verursacht haben könnte.

Derjenige, der deinen Code reviewt, wird es dir danken. Er kann Änderung für Änderung gezielt prüfen – ohne Angstschweiss und Herzkasper.

5. Konsistenz – Schuster bleib bei deinen Leisten

Wenn du dich bei deinen Variablen dazu entschieden hast Camel Casing[5] in der Benamung zu verwenden, dann bleib auch dabei. Du magst keine Tabs sondern lieber Leerzeichen? Auch gut. Egal was du in deinem Code machst, mach es konsistent.

Das Problem der Inkonsistenz wird geschürt durch Zeit. Und Zeit zerstört Software. Je länger eine Software in ihrer Entwicklung verbleibt und je mehr Leute damit möglicherweise involviert sind, desto mehr Chaos kommt ins Spiel.

Was also kannst du machen, damit du konsistenter wirst?

Eines der ersten Dinge wäre: Leg dir einen Style-Guide zu. Damit meine ich keinen grafischen Style-Guide, der vorschreibt,welche Schriftart und welche Farben du zu verwenden hast. Sondern ein Dokument, das z.B. definiert, ob in Dateinamen Unterstriche vorkommen dürfen oder wie die Deklarationen für Variablen auszusehen haben. Ein Beispiel für einen solchen Style-Guide findest du hier: Google Javascript Style Guide

Merke: Konsistenz hat einen erheblichen Einfluss auf die Wartungsfreundlichkeit deines Codes.

6. Das Morgen stirbt nie

»Bugfix XY? Das mach ich gleich morgen.« Ich glaube, das haben wir uns alle schon mal sagen hören. Und wir alle wissen, wie oft Dinge dann tatsächlich am nächsten Tag erledigt werden – selten bis nie. Jedes Mal, wenn du einen ToDo-Comment im Code entdeckst, hat jemand seinen Job nicht erledigt.

Arbeite an einem Stück Code, bis er komplett fertig ist!

Und was bedeutet »komplett fertig«?

Für den Anfang zum Beispiel, dass dein Code bereits refaktoriert wurde. Nun muss dein Code noch ausgiebig getestet werden – für viele nicht immer der Lieblingspart ihres Berufes. Und Testen bedeutet nicht einfach, nur genau das anzuklicken, was jeder Benutzer auch tun würde. Du solltest auch komplexere Szenarien in deine Tests aufnehmen, z.B. was passiert, wenn plötzlich das Netz ausfällt? Und wenn du die Erwartungen übertreffen willst, dann schreib am besten noch ein paar automatisierte Tests.

7. Die Lorbeeren

Täglich kommen neue Technologien auf den Markt und im wahrsten Sinne des Wortes – täglich! Und oft ist es wirklich schwierig, Schritt zu halten mit den neuesten Trends. Aber man sollte nie aufhören, zu lernen und sich nicht auf seinen Lorbeeren ausruhen.

Nur durch das Erlernen neuer Technologien ist es uns möglich, heute und vor allem auch morgen noch unserem Beruf gerecht zu werden.