Ist quick wirklich dirty?
"Ich hab das mal eben quick and dirty eingehackt. Wir machen das aber später noch ordentlich." kann man als Projektleiter gelegentlich hören. Blick und schuldbewusster Tonfall des Mitarbeiters machen aber deutlich, dass er sich der Ungehörigkeit seines Verhaltens bewusst ist oder zumindest weiß, dass er so tun muss.
Natürlich werden diese Quick Hacks nur selten tatsächlich korrigiert. Wenn etwas in Systemen Bestand hat, dann gerade die Quick Hacks und das hat einen guten Grund: Ihre Qualität ist nicht so schlecht wie ihr Ruf. Denn im Allgemeinen bedeutet quick and dirty, dass das schöpferische Unterbewusst¬sein in die Tasten gehauen hat.
Es gibt eine Sichtweise auf Softwareentwicklung, die ungefähr folgendes besagt:
- Softwareentwicklung ist eine ernsthafte Angelegenheit
- Wenn man nicht permanent total aufpasst, können schlimme Dinge passieren
- Es tritt immer der schlechtestmögliche Fall ein.
- Ist da irgendwo ein Fehler, dann tritt er auch auf und richtet den denkbar größten Schaden an.
Deshalb müssen wir uns permanent anstrengen und disziplinieren, sauber zu programmieren.
In der Folge legen sich Kontrolle und Korrekturzwang über das, was einfach so spontan aus uns herausfließen würde, wenn wir vor uns hinprogrammieren, wie uns der Schnabel gerade gewachsen ist.
Hat man das mal ein paar Jahre so gemacht, dann merkt man gar nicht mehr, wieviel Energie hier blockiert wird. Man merkt es erst, wenn aus irgendwelchen Gründen der Damm bricht. Zum Beispiel unter Zeitdruck oder wenn man es so richtig satt hat oder wenn man sich ganz privat Sachen selbst entwickelt. Letzteres kann als Methode nur empfohlen werden, weil es einen Weg darstellt, den eigenen ganz individuellen Programmierstil kennenzulernen und zu entwickeln, ohne dass irgendwer darüber die Nase rümpfen kann.
Man kann sich klar machen, dass die allgemeine Vorstellung, wie guter Programmcode auszusehen hat, nicht unbedingt wahr ist. Sie sieht nur so unglaublich wahr aus, weil
- der Professor an der Uni, die internationale Koryphäe, hats gesagt
- der Chef (der keine Ahnung vom Programmieren hat, aber Fachzeitschriften liest) hats auch gesagt
- wohlmeinende Senior-Developer in Foren korrigieren die Codeschnipsel, die man selber einstellt, indem sie sie mit Fehlerzweigen und überflüssigen Kommentaren dermaßen zupflastern, dass die eigentlich wichtigen Anweisungen keine 10 Prozent mehr ausmachen.
Woher weiß man dann aber, wie guter Programmcode nun auszusehen hat?
Beim Programmieren in sich reinlauschen und reinsehen:
- Wird Energie frei oder blockiert?
- Geht etwas leicht von der Hand oder muss man sich zwingen es zu tun?
- Flutscht es ordentlich raus oder treten innere Widerstände auf?
Freude, Begeisterung und Energie sind die besten Programmierlehrer, die man sich wünschen kann.