Kategorien
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.
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.
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…
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. 🙂
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.
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
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.
@KingCrunch: Für mehr als flicken zahlt der Kunde meist nicht. Denn „es hat doch bisher auch funktioniert“…
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.
@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.
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.
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?
@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.
@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.
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.
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.
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.
@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.
@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.
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.