Facebook
Twitter
Google+
Kommentare
5

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.

Über den Autor

Nils Langner

Nils Langner ist der Gründer von "the web hates me" und auch der Hauptautor. Im wahren Leben leitet er das Qualitätsmanagementteam im Gruner+Jahr-Digitalbereich und ist somit für Seiten wie stern.de, eltern.de und gala.de aus Qualitätssicht verantwortlich. Nils schreibt seit den Anfängen von phphatesme, welches er ebenfalls gegründet hat, nicht nur für diverse Blogs, sondern auch für Fachmagazine, wie das PHP Magazin, die t3n, die c't oder die iX. Nebenbei ist er noch ein gern gesehener Sprecher auf Konferenzen. Herr Langner schreibt die Texte über sich gerne in der dritten Form.
Kommentare

5 Comments

  1. Erst mal hallo ^^

    Danke für den ordentlichen Lacher der die „Wtfs/sec“ bei mir und hier im Büro verursacht haben.
    Traurig aber war….
    Ich sitze hier gerade ebenfalls an einem Projekt das mehr als 4 Jahre auf dem Buckel hat und mein Wunsch mit dem Kopf gegen die Tischplatte zu hämmern steigt vom Minute zu Minute…
    “das sollte man komplett neu machen” ^^
    Wir lösen das Ganze heute in Form von Fest definierten Standards, einem (naja, mehr oder weniger) ordentlichen Code-Review und einer Dokumentation des Quelltextes bei dem grobe bis mittlere Schnitzer relativ leicht auffallen.
    Bei wirklich schlechtem Code oder groben Schnitzern ist ein Mittagessen fällig :-)
    Über den Einsatz von Tools wird zwar immer wieder diskutiert, führte aber noch zu keinem Ergebniss 😉
    Grüße
    Markus

    Reply
  2. Ich denke das Problem ist, dass wir fast täglich neue Dinge lernen. Ich reg mich selbst über meinen eigenen Code vor 2 Jahren auf, aber man wusste es damals nicht besser :-) Und ich bin sicher in 2 Jahren, reg ich mich über Code auf den ich heute geschrieben habe :-)

    Reply
  3. Hallo Nils,

    bei uns ist es im Moment ähnlich. Viel Zeitdruck verursacht bei uns viel schlechten Code. Wie du es schon geschrieben hast.

    Wir haben jetzt anfangen, dass verschiedene Entwickler, Zeitslots bekommen, in dem sie sich über ein QA-Thema auseinandersetzen können.
    Ähnlich wie bei google die 20% Regel, die ein Arbeitnehmer für ein beliebiges Projekt nehmen darf. So, halt nur für QA :)

    Wenn genug Informationen vorhanden sind, setzen wir uns immer zusammen und diskutieren es in der Runde. Danach wird abgeschätzt, wie groß der Migrations-Aufwand ist und dementsprechend wird der Prozess, etc. aufgenommen. Toll finde ich auch, das bei uns viele Entwickler auch richtig lust darauf haben und gerne mal auch nach 17:00 Uhr noch hier sind.

    Bisher haben wir so phpcs, php_beautifier, hudson … aufgenommen.
    Weiter geht es jetzt mit OOP-Analyse-Prozesse, Scrum/XP …

    @Markus, da gibts doch auch das tolle Bild dazu: http://blog.meyju.net/wp-content/uploads/2010/02/wtfm.jpg :)

    Reply

Leave a Comment.

Link erfolgreich vorgeschlagen.

Vielen Dank, dass du einen Link vorgeschlagen hast. Wir werden ihn sobald wie möglich prüfen. Schließen