Die Pfadfinderregel

So erstmal ein paar Worte in eigener Sache. Wir sind nämlich so Web 2.0, dass wir jetzt eine eigene Facebook Seite haben. Neidisch? Wahrscheinlich nicht! Trotzdem könnt ihr gerne Fan werden. Könnt mich auch gerne adden, wenn ihr schon dabei seid. Obwohl, es darf mich nur jemand adden, der mindestens 42 Artikel von mir gelesen hat. Ist dann familiärer. Amilio hat übrigens auch eine Seite spendiert bekommen, da könnt ihr aber auch gerne den Twitter Account hinzufügen, falls ihr gerne über die netten Bildchen informiert werden wollt. Und wer will nicht ab und zu mal lachen/weinen/…. Genug aber jetzt über uns.

Heute wollen wir mal wieder eine Regel besprechen, mit der ich eigentlich die letzten Jahre ziemlich gut gefahren bin. Die Pfadfinderregel. Helft alten Omas über die Straße! Fertig. Nein eigentlich geht es um eine andere, die Jungs und Mädels haben da nämlich was über den Zeltplatz erzählt, was man sich merken sollte. Aber holen wir doch mal ein paar Zeilen aus.

Wir kennen alle Code, der unsere Vorgänger verbockt haben. Legacy Code, den man am liebsten nicht anfassen will. Um ihn neu zu schreiben fehlt einem aber die Zeit. Kennen wir alle, brauche ich glaube ich nicht drauf einzugehen. Stile ändern sich eben und Programmierer lernen dazu. Wir haben also die Situation, dass wir zum Beispiel eine Methode erweitern sollen. Diese Methode ist eine Milliarde Zeilen lang (ich habe solche Methoden gesehen, “ungelogen”). Was machen. Der erste Ansatz ist: ich schaue mir die Stelle an, wo es ungefähr rein muss, schreibe da noch eine Zeile Code rein – unendlich plus eins ist schließlich immer noch unendlich – und tue so, als ob nie was gewesen wäre. Hab ich oft genug selbst so gemacht. Zumindest der alte Nils.

Die Pfadfinderregel, die ich meine lautet: Hinterlasse den (Zelt-)Platz immer schöner, als du ihn vorgefunden hast. Und das können wir hier auch anwenden. Wenn dich schon neue Funktionalität reinprogrammiere, dann bitte schön in eine separate Methode. Und wenn ich schon dabei bin, dann kann ich mir einen kleinen Teil der Methode vornehmen. Einen, den ich verstehe. Ich muss ja einen Teil verstehen, denn sonst sollte ich die Methode gar nicht anfassen. Ok wir nehmen also einen kleinen Teil, den wir verstehen und Refactorn ihn. Meistens wird es sich wohl um “Extract Method” handeln.

Das schöne daran ist, dass der Code nicht schlechter wird. Im Gegenteil, peut á peut verbessert er sich. Ok, es gibt Projekte, das muss ich hunderte von Jahren so handeln, damit man etwas mitbekommt, aber zumindest ich fühle mich als Weltverbesserer, wenn ich den Code sauberer hinterlasse, als ich ihn vorgefunden habe. Und Zeit kostet es auch nicht wirklich, zumindest nicht im Gegensatz zum Einarbeiten in die Methode.

20 Kommentare »

• 
  

  Christian Schäfer

  am 14. Januar 2010 um 07:48 Uhr

  Dem stimme ich voll und ganz zu!

  Was die meisten aber dennoch vor der Befolgung einer solchen Regel abhält ist die Angst, was kaputt zu machen.

  Das einzige, was da hilft ist den Platz nicht nur etwas schöner, sondern auch etwas getesteter zu hinterlassen. Ich muss also Tests schreiben, die den von mir zu verändernden Teil abdecken (nicht die ganzen Milliarden von Zeilen!), um zu wissen, dass nach meiner Änderung all das funktioniert, was auch vorher der Fall war. Erst nach der Erstellung solcher Tests, kann ich zB mit Extract Method das Refactorn beginnen.

• 
  

  David Müller

  am 14. Januar 2010 um 07:49 Uhr

  Puh, das ist sone Gewissensfrage. Wenn ich das Schlamassel erstmal aufgedeckt hab und nur einen kleinen refactore (schlimmes Wort), dann hab ich ab diesem Moment die Schludrigkeit des kompletten Rests im Hinterkopf und das ganz besonders dann, wenn ich wirklich die von dir angesprochene Milliarde Jahre brauchen würde, eh sich wirklich was bewegt. Bei Startups ists ähnlich, meine Motivation fadet nach jeder Zeile “Schmuddelcode” ein Stückchen und das lässt mir solang keine Ruhe, bis ich mich nach einiger Zeit des sinnierens über schönere Lösungen dransetze und alle Baustellen picobello aufräume. Diesen Perfektionszwang sollte ich mir wohl abgewöhnen…

• 
  

  Stefan Riedels Blog

  am 14. Januar 2010 um 08:10 Uhr

  Jo also ich persönlich würde sone 1.000.000.000 Zeilen Methode auch nicht einfach mit nem “Methoden – Einschub” wieder zurücklassen und aufs Produktivsystem pusten. Aber das wohl auch ne Glaubensfrage.

• 
  

  Bastian

  am 14. Januar 2010 um 08:26 Uhr

  Oh ja… Das kenne ich. Ich versuche auf dem Zeltplatz dann immer einen Haufen Schilder zu hinterlassen: ‘Das nicht wegräumen! oder Hier werkelt eine Ameisenfamilie!, …’ Oder auch mal, wie du sagst, was richtig aufzuräumen.

• 
  

  Sebastian

  am 14. Januar 2010 um 08:33 Uhr

  Full ACK @David
  Scheiss auf Zeitpläne der Code muss geil sein

  Das ist schon ein Problem mit dem Refactoring. Den gleichen Ansatz verfolgt übrigens auch Martin Fowler in seinem Buch Clean Code.

  Er empfiehlt auch ein Stück für Stück Refactoring. Alles andere ist unwirtschaftlich.

  Gruss
  Sebastian

• 
  

  KingCrunch

  am 14. Januar 2010 um 09:19 Uhr

  Irgendwie wirkt es ungesund in Methoden, die man “nur so halb” versteht rumzuwerkeln… Würde auch eher richtig aufräumen, anstatt nur nen Flicken drauf zu pappen.

• 
  

  Robert Kummer

  am 14. Januar 2010 um 09:42 Uhr

  @KingCrunch: Für mehr als flicken zahlt der Kunde meist nicht. Denn “es hat doch bisher auch funktioniert”…

• 
  

  Mathias Methner

  am 14. Januar 2010 um 10:07 Uhr

  Man werkelt nicht an Methoden rum, die man nicht versteht. Man refactored Methoden _bis_ man sie versteht, und das nie, ohne vorher Tests geschrieben zu haben. (Learning Tests)

  Dein Pfadfinderleitsatz findet sich in Clean Code von Uncle Bob auch wieder. Dort ist es einer der fundamentalsten Leitsätze.

  Das Problem an funktionierendem Code ist folgendes:
  running code != clean code
  Die Wartung von altem Code ist wesentlich teurer als ihn aufzuhübschen und beim nächsten Mal mit gutem Gewissen und einer wasserdichten Testsuite Änderungen im Handumdrehen und wesentlich geringerem Bugpotential umzusetzen.

• 
  

  Nils Langner

  am 14. Januar 2010 um 10:30 Uhr

  @KingCrunch: Richtig aufräumen kannst du nicht, zumindest nicht in der realen Welt. Ich weiß noch nicht mal, ob es immer Sinn macht das Ding komplett umzubauen. Würde sogar glauben, dass es Momente gibt, wo man das sein lassen sollte.
  Mit dem Pfadfinderansatz machen wir den Code sogar besser, ohne viel Zeit zu verlieren. Ich denke, dass ist ganz praktikabel in den meisten Situationen.

• 
  

  halloman

  am 14. Januar 2010 um 11:42 Uhr

  Ihr sieht das alles viel zu eng. Einfach draufpacken bis es nicht mehr geht und wenn eine änderung kommt die nicht mehr geht muss man halt alles neu schreiben (mit “sauberem” code). der begriff sauber ist aber ein recht lächerlicher. was vor 5 jahren als sauber galt ist heute der reinste horror. und das subjektive sauber hängt auch nur vom eigenen wissenstand und es gibt immer einen der schauer ist, da könnt ihr euch drauf verlassen.

• 
  

  Ralph Meier

  am 14. Januar 2010 um 13:03 Uhr

  Ich beschäftige mich momentan sehr mit Clean Code. Dazu gibt es schon einige wenige Artikel auf http://daraff.ch

  - http://daraff.ch/2010/01/terminbudgetqualitats-probleme-in-softwareprojekten/
  - http://daraff.ch/2010/01/der-lange-weg-zum-clean-code-developer-im-realen-leben/
  - http://daraff.ch/2010/01/clean-code-produzieren-was-sind-die-probleme/

  Ich halte mich auch strikt an die Pfadfinderregel und ich versuche ihn auch soviel Leuten wie möglich weiterzuvermitteln. Bei unseren Lehrlingen im Geschäft trägt es bereits erste Früchte.

  Es gibt eine deutsche Seite/Bewegung http://www.clean-code-developer.de/ welche sich ausschliesslich mit Clean Code beschäftigt. Die Prinzipien stammen hauptsächlich aus dem Buch Clean Code von Uncle Bob (wie von Mathias Methner schon erwähnt wurde).

  Es wurde das Thema Test Driven Development erwähnt. Ich experimentiere momentan auch mit TDD (PHPUnit) herum. Konnte einfache Code Katas mit objektorientiertem Ansatz gut lösen. Ich habe aber Probleme bestehenden Code so zu refaktorisieren, dass er testbar wird (z.B. Statische Klassen und Funktionen oder globale Variablen usw.).
  Hat da evtl. jemand Tips, wo es infos zu diesem Thema gibt und wie man diese Probleme lösen kann?

• 
  

  Mathias Methner

  am 14. Januar 2010 um 13:41 Uhr

  @hallomann:
  Clean Code hat nichts damit zu tun sich besonders hervozuheben, seinen Code vor den anderer zu stellen, sowie komplizierte Sachverhalte in wenigen Zeilen zu verpacken um sich danach schlauer als andere zu fühlen. Clean Code ist Kommunikation und damit die Weitergabe der Erkenntisse beim Bearbeiten von altem Code an die Kollegen. (Noch nie in der Situation gewesen Quelltext zu bearbeitet, der vor langer Zeit von längst nicht mehr angestellten Entwicklern geschrieben wurde?)

  Es gibt Situation in denen man nicht nicht refactored, ja.
  Als Gründe dafür kann man sicherlich Zeit und Kosten / Nutzen anführen, allerdings ist es dann zumindest sinnvoll im Code / Bugtracker zu vermerken das nachgearbeitet werden muss.

• 
  

  Christian

  am 14. Januar 2010 um 19:51 Uhr

  @Ralph Ich hätte da tatsächlich einen Tipp für dich
  http://test.ical.ly/2010/01/06/buchtipp-working-effectively-with-legacy-code/

  Das Buch habe ich vor kurzem für mich entdeckt und finde es spitzenmässig, weil es eben genau auf deine Fragen pragmatische und keine akademischen Antworten gibt.

• 
  

  ragtek

  am 15. Januar 2010 um 07:39 Uhr

  Mein Standpunkt/Erfahrung ist auch, dass der Kunde für so etwas kaum zahlen wird, da es in der Vergangenheit ja auch funktioniert hat…

  Einige haben ja geschrieben, dass man die Methode komplett verstehen sollte, bevor man sie umbaut/neu programmiert.
  Sollte man dann nicht eventuell die komplette Klasse verstehen und sich mit jeder einzelnen Methode beschäftigen?
  Ab und zu ist es ja so, dass es mehrere Methoden gibt, die im Grunde dasselbe machen. Hier könnte man vorgreifen und gleich 2,3 Methoden “refactoren”(gibt es dafür kein schöneres Wort??)
  Nur wer Zahlt das? Der Kunde eher nicht, da es ja in der Vergangenheit ja sowieso funktioniert hat…

  PS:
  Eventuell sollte man die Ideenschmiede mal aktualisieren, da zB die Pfadfinderregel ja nun rausfliegen sollte.
  Eventuell gibt es noch einige Punkte, die schon umgesetzt wurden.

• 
  

  David Müller

  am 15. Januar 2010 um 07:46 Uhr

  Man könnte es mit dem Argument versuchen, dass zukünftige Änderungen in wesentlich kürzerer Zeit umgesetzt werden können – Ob das allerdings gelten gelassen wird, wage ich zu bezweifeln.

• 
  

  ragtek

  am 15. Januar 2010 um 07:54 Uhr

  Ja, ich auch. Wobei ich mir denke, dass es vor allem vom Kunden und vom Projekt/Projektgröße abhängt.

  Ich kann mir schon vorstellen, dass bei größeren Projekten und Kunden die eine Ahnung von der IT haben, ab und zu ein “Ja” auf die Frage kommen wird.

  Persönlich hatte ich noch nie die Ehre, bei wirklich größeren Projekten mitzuarbeiten.
  Bei den kleinen Umsetzungen war es dann aber IMMER ein „wieso?“ Es funktioniert doch bis jetzt auch hervorragend, also wieso soll ich die 10h Mehraufwand investieren?

  Auch wenn es nicht wirklich zum Thema passt, ein Beispiel: Das „ärgerlichste“ war eine Firmenseite, die noch auf Frames basierte.
  Da konnte man argumentieren was man wollte, die Firma die ihm die Seite erstellt hat, hat wohl erfolgreich Gehirnwäsche betrieben, da er sich einfach nicht umstimmen lies.

• 
  

  Nils Langner

  am 15. Januar 2010 um 08:08 Uhr

  @ragtek: Ideenschmiede wird im neuen Layout anders aussehen. Das Problem, was du mit dem Kunden beschreibst ist glaube ich eine Zwickmühle. Nehmen wir an, du hast eine wirklich miese Methode, da musst du aber nur 3 mal im ganzen Jahr was anfassen. Jetzt setzt du dich hin und refaktorierst sie. Das dauert vll. 1 Tag. Der Kunde wird niemals das Gefühl haben, dass sich dadurch an der Situation was verbessert hat, nehme ich an.
  In so einer Situation wüsste ich aber selbst nicht, was ich anordnen würde.

• 
  

  Mathias Methner

  am 15. Januar 2010 um 10:31 Uhr

  @Christian
  Spitzen Buchtipp. WIrd gleich bestellt

  @ragtek
  Argumente vorm Kunden zu finden ist sicher schwierig, da bin ich bei dir. ‘Never change a running system’, wer kennt den Satz nicht?

  Allerdings gibt es auch eine andere Seite, und zwar die Inhouse-Entwicklung. Hier muss man vor dem Chef argumentieren, was ich in aller Regel für etwas einfacher halte.

• 
  

  ragtek

  am 15. Januar 2010 um 16:39 Uhr

  Jein, beim Chef ist es auch nicht so ohne.
  Hier habe ich eine extrem schlechte Erfahrung gemacht, die dazu geführt hat, das ich gekündigt habe.

  Habe das Problem auch hier http://www.php.de/off-topic-diskussionen/62989-kollegen-und-chefprobleme.html gepostet, jedoch ist dort leider niemand auf die Diskussion/Frage eingegangen.
  Mein ehemaliger Chef war genau so einer.
  Schnelles Profit + never change a running System.
  Na hurra, perfekte Arbeitsbedingungen.

• 
  

  Kleine Schritte sind besser als keine Schritte « Stephan Schmidt

  am 6. Februar 2010 um 07:56 Uhr

  [...] an dem Tag, als ich den Eintrag schreiben wollte, kamen mir jedoch Nils und Holger zuvor. Mein erster Impuls war, meinen Eintrag einfach zu löschen und das Thema zu den [...]

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

Hinterlasse einen Kommentar