Sauber bleiben! Ein paar Ansätze.

Erstmal ein wenig feiern. (Hier könnt ihr euch jetzt einen wild tanzenden Nils vorstellen) Gestern haben sich nämlich drei zukünftige Autoren und Autorinnen gemeldet. Ich war und bin  freudig überrascht. Die drei bekommen heute übrigens noch eine Mail von mir, also immer schön ins Postfach schauen.

Aber genug Einleitung, auf zum Thema. Wir kennen das ja alle, wir arbeiten in Projekten, bei denen man oft denkt, dass doch niemand sowas programmieren kann. Die What The Fucks pro Sekunde sind da manchmal relativ hoch. Ich mache das mit der Webentwicklung ja schon eine ganze Weile, aber jedes Projekt, dass älter als 2 Jahre war, hatte irgendwie grobe Schnitzer drinnen. Der Satz „das sollte man komplett neu machen“ hab ich öfters als einmal gehört. Das immer schlechter werden von Code heißt übrigens Software-Erosion, falls euch der Fachbegriff interessiert.

Aber woran liegt das? Termindruck ist sicherlich einer der Hauptgründe für so etwas. Alles muss schnell schnell gehen und Hauptsache es funktioniert, schön machen wir es ein anderes mal. Neue inhaltliche Anforderungen bringen natürlich auch neue technische Anforderungen und die muss das System ja nicht immer einfach abbilden.

Jetzt wollen wir das natürlich verhindern. Aber vorher muss ich noch sagen, dass wir es nicht unendlich lange in Projekten ausgehalten haben permanent sauber zu bleiben. Aber dazu kommen wir gleich:

• Statische Code-Analyse: Es gibt Tools, die Source-Code analysieren können und einen groben Überblick darüber geben, wo Schwachstellen sein können. Softwaremetriken wäre hier zum Beispiel ein Buzzword. Diese über jeden neuen Code laufen zu lassen ist nicht teuer, hat aber einen netten Effekt.
• Automatismen: Passend zur statischen Analyse muss natürlich ein Automatismus her. Keine hat Lust alles per Hand zu testen, also müssen Mechanismen gebaut werden, die einem den manuellen Aufwand abnehmen. Continuous Integration ist wohl die beliebteste Lösung.
• Testabdeckung: Vielleicht der wichtigste Punkt. Zum einen ist testbarer Code meistens besser strukturiert, da komplexer und komplizierter Code ja um einiges schwerer zu testen ist. Der aber noch wichtigere Punkt ist, dass hohe Testabdeckung auch bedeutet, dass ich Code refaktorieren kann. Ist also gar nicht so schlimm, falls mal was nicht ganz so schön aussieht.
• Aufräumsprints: Wie wäre es, wenn man sich alle paar Wochen/Monate mal hinsetzt und keine neuen Features implementiert, sondern einfach aufräumt. Das muss man natürlich dem Kunden verkaufen, aber das sollte schon klappen, denn er sieht ja, dass es immer länger dauert je länger man ein Projekt am laufen hat.
• Prozesse: Es muss dem Entwickler ins Blut übergehen, dass das Schreiben von schlechten Code irgendwann auf einen zurückfällt. Prozesse sind dabei so eine Art Rückendeckung von oben. Wenn man einen Code-Review in den Entwicklungszyklus einbaut, dann geht schon mal nicht mehr so viel schief. Also auch wenn Prozesse irgendwie spießig sind, helfen sie einem dann doch in vielen Situationen.

Das waren jetzt erstmal ein paar Ansätze, die ich für gangbar halte. Ihr habt sicherlich auch ein paar zu bieten und ich würde mich freuen, wenn ihr wie immer ergänzende Worte findet.