Archiv 2010

Manchmal ist es schon kurios. Beim Design von Software achtet man auf schöne Strukturen, sauberen Quellcode und irgendwann kommt der Zahn der Zeit. Üblicherweise in Gestalt eines Kunden oder Benutzers der unbedingt dieses oder jenes Feature haben möchte. Die schönen Strukturen werden etwas aufgeweicht, der Quellcode bekommt ein paar Entscheidungsbäume mehr und alle sind erstmal zufrieden. Natürlich nimmt man sich vor das alles im nächsten Release besser zu machen aber sind wir mal ehrlich, wer macht das wirklich, bzw. wer hat die Zeit dafür.

Und das ganze kommt oft noch schlimmer, nach ein paar Monaten wird die Funktion gar nicht mehr gebraucht. Eine neue Implementierung wird hinzugefügt und das Design wird weiter aufgeweicht, denn den unbenutzen Code tastet man inzwischen nicht mehr an, weil man nicht mehr weiß wer ihn noch braucht oder man meint ihn nochmal brauchen zu können.

Ich für meinen Teil habe in letzter Zeit an mehrfach festgestellt wie befreiend es sein kann alten Ballast über Board zu werfen. Und solches Refaktoring macht sogar noch Spaß, denn am Ende sieht man wieder ein wenig Licht. Die Strukturen die man sich einstmals erdacht hat schimmern wieder durch das Gewirr von Anpassungen hindurch und plötzlich wird einem wieder klar wie schön Software doch eigentlich sein kann.

So habe ich im Backend meines CMS immer daran festgehalten Texte mittels BB-Code zu formatieren und war auch irgendwie der Meinung das ein Umbau nicht lohnt und wahnsinnig aufwendig sei. Inzwischen habe ich das System umgebaut, die Daten migriert und alles was mit BB-Code zu tun hat weitestgehend entfernt. Und siehe da das System ist ein wenig schneller geworden, der Code etwas lesbarer und ich kann sogar ohne Probleme einen WYSIWYG Editor im Backend verwenden, einfach nur indem ich eine Altlast beseitigt habe.

Um den Pragmatic Programmer zu zitieren: "Don't live with Broken Windows", wenn der Code hässlich oder ineffizient wird dann tu etwas dagegen. Die Zeit verzeiht keine Fehler und wenn man etwas nicht mehr braucht sollte man den Mut haben es zu entfernen, genauso wie man eine fehlerhafte Lösung korrigieren sollte wenn man sie entdeckt.

0

0 Kommentare / 0 Trackbacks

... eine fehlerhafte Dokumentation. Es gibt da draußen Orte an denen sind Quellcode-Kommentare ganz wichtig. Sind sie ja manchmal auch. Ich bin zwar der festen Auffassung das Quellcode sich selbst-dokumentieren sollte und das Quellcode der einer umfangreichen Erklärung bedarf eigentlich gar keine Daseinsberechtigung besitzt aber es gibt Zeiten da geht es eben nicht anders.

Gerade stoße ich auf Quellcode aus meiner eigenen Vergangenheit, aus einer Phase als oben geschriebenes noch nicht galt und ich selbst der Meinung war es wäre schick jede Methode zu dokumentieren, dabei bemerke ich einfach das ich diese Dokumentation zwar angelegt, aber nie aktualisiert habe.

Und voller Scham fällt mir das Kapitel "The Evils of Duplication" aus dem Pragmatic Programmer ein, denn Quellcode Kommentare sind, so sie von Hand geschrieben werden eine ganz klare Form von Duplikation. Merke: DRY - Don't repeat yourself!!!

0

0 Kommentare / 0 Trackbacks

Unter dem verheißungsvollen Titel "When can I use..." habe ich gerade eine schöne Übersicht über die ganzen schicken neuen Webtechniken wie HTML5, CSS3, SVG & Co. gefunden. Übersichtlich gegliedert werden die allgemeinen Browsergruppen (IE, Firefox, Webkit, Chrome und Opera) in ihren verschiedenen Versionen und deren Unterstützung für verschiedene Features dargestellt.

Schöne Übersicht wenn man mal wieder rumspielen will und sicherstellen will das wenigstens die aktuellen Browser später mit dem neuen Spielkram auch umgehen können.

0

0 Kommentare / 0 Trackbacks