Sauber bleiben! Ein paar Ansätze.

Lesetipps

1. Ein paar Gedanken zur Konsensorientierung
2. Magento für PHP 5.3 anpassen und dabei kompatibel bleiben
3. Ein paar Zend_Mail Tricks

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.

5 Kommentare »

• 
  

  Markus

  am 1. Dezember 2010 um 09:18 Uhr

  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

• 
  

  Ralf Kronen

  am 1. Dezember 2010 um 11:25 Uhr

  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

• 
  

  DaRaFF

  am 1. Dezember 2010 um 13:37 Uhr

  Hallöchen an alle.
  Durch den Artikel von Nils und die Kommentare wurde ich inspiriert gerade einen eigenen Artikel zu diesem Thema zu schreiben. Ich würde mich also über Feedback freuen.
  http://daraff.ch/2010/12/crap-code-warum-gibt-es-so-viel-schlechte-software/

• 
  

  BennyGrimm

  am 1. Dezember 2010 um 18:27 Uhr

  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

• 
  

  Re: Crap Code – Warum gibt es so viel schlechte Software? // der php hacker – ein php blog

  am 2. Dezember 2010 um 09:01 Uhr

  [...] hat sich vom letzten Artikel von Nils inspirieren lassen, und seine Antwort als eigenen Post verfasst. Find ich gut und hab ich auch [...]

RSS Feed für Kommentare zu diesem Artikel. TrackBack URL

Hinterlasse einen Kommentar