yagni – You ain’t gonna need it

Lesetipps

1. Äquivalenzklassen beim Testen

Heute möchte ich über eines meiner Lieblingsregeln beim Programmieren reden, besonders da ich damit so oft schon mit anderen aneinander geraten bin. Aber vielleicht erkläre ich einfach erstmal worum es hier geht. You ain’t gonna need it – Du wirst es eh nicht brauchen. Sollte man also eine Methode entwickeln die man momentan nicht braucht, nur weil es gerade gut rein passen würde und irgendwann bestimmt mal hilfreich sein wird? Nein! Wir programmieren nur Sachen, die wir auch tatsächlich benötigen. Wer weiß denn schon, was wir in ein paar Wochen oder Monaten brauchen? Vielleicht haben wir Glück und die Anforderung ist ähnlich mit dem, was wir implementiert haben. Aber was wenn nicht? Dann müssen wir und in die Methode und wahrscheinlich auch in die ganze Klasse wieder einarbeiten, um sie zu refaktorisieren. Also lassen wir doch einfach die Finger von uns machen es nur bei Bedarf, wenn die Anforderungen und der Kontext der Funktion klar sind.

Natürlich gibt es auch ein starkes Gegenargument gegen dieses Verhalten. Es wird immer einfacher sein diese Methode zu implementieren, wenn man gerade mitten in der Thematik steckt. Aber wie oft hat man eine Methode geschrieben, die dann nie zum Einsatz kam. Und diesem toten Code gilt es zu verhindern. Nicht umsonst gibt es Tools, die einem Stellen im Code anzeigen, die nie verwendet werden, denn so ein Code ist nicht sehr hilfreich bei der Wartung einer Anwendung.

Ich weiß, dass sich die Geister bei diesem Programmierparadigma scheiden. Ich werde es auf jeden Fall weiter betreiben, da ich in der Vergangenheit immer sehr gut mit gefahren bin.

3 Kommentare »

• 
  

  Daniel

  am 11. Oktober 2008 um 10:44 Uhr

  Aus dem Artikel werde ich gerade nicht wirklich schlau. Beim Lesen habe ich nur darauf gewartet, dass Du am Ende alles auflöst und uns schreibt, dass Du natürlich Methoden so schreibst, dass Du sie in Zukunft auch nutzen kannst. Der ganze Text hatte einen leichten ironischen Touch.
  Aber Du hast es am Ende nicht als Ironie aufgelöst, also schreibst Du nur das, was Du aktuell brauchst?
  Ich bin der Meinung, dass man vieles wiederverwenden kann, auch wenn Projekte sich inhaltlich nicht ähneln. Und das Einarbeiten in alten selbstgeschrieben Code halte ich für einfacher und schneller als das Neu-Schreiben von ähnlicher Funktionalität. Natürlich eine vernünftige Kommentierung im Code vorausgesetzt

• 
  

  Psaniko

  am 11. Oktober 2008 um 13:08 Uhr

  Interessante Einstellung, aber imho nicht immer hilfreich. Natürlich sollte man versuchen, überflüssigen Code zu vermeiden, um die insgesamte Entwicklungszeit der Application zu minimieren, aber in einigen Fällen ist so etwas praktisch.
  Aber auch nur, wenn man dann diesen Code nicht genau auf diese Application zuschneidet, sondern eher als eine Art geschlossene Klasse, optimalerweise ein Plugin für ein Framework schreibt.
  Ich habe letztens auch die MCrypt-Funktionalität von PHP gebraucht, was bisher noch nicht der Fall war und auch nicht so oft ein wird. Aber als ich mich in die Funktionen von mcrypt eingearbeitet hatte, habe ich eine Komponente für mein Framework Cube geschrieben und kann diese nun in allen Projekten einsetzen, sollte ich mcyrpt je wieder brauchen.
  Damit vermeide ich lange Einarbeitszeit =)

• 
  

  Nils Langner

  am 11. Oktober 2008 um 17:09 Uhr

  Naja, ich denke ich den meisten Fällen ist es ja wirklich so, dass man den Code, den man da entwirft nicht braucht oder nicht so braucht, wie man es zu einem anderen Zeitpunkt “erraten” habt. Aber natürlich ist dies ja keine verpflichtende Regel, sondern eher eine Anregung zum Nachzudenken.
  Ich schreibe meine Klassen trotzdem allgemein und nicht nur auf ein Problem zugeschnitten, dass ihr mich da nicht falsch versteht. Ich werde nur nicht eine Breitensuche implementieren, wenn ich eine Tiefensuche brauch, nur weil ich gerade tief in der Thematik drin bin.

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

Hinterlasse einen Kommentar