Clean Code Developer

Clean Code Developer

Posts 1-1 of 1
  • Stefan Lieser
    Stefan Lieser    Group moderator
    The company name is only visible to registered members.
    Erfahrungen eines Clean Code Developers
    Das Buch „Design Patterns“ der „Gang of Four“ war mein Schlüsselerlebnis und der Einstieg in eine neue Art und Weise der Softwareentwicklung. Hatte ich vorher, trotz (oder vielleicht wegen) Informatikstudium, arg daran gezweifelt, dass die Softwareentwicklung jemals eine ingenieurmäßige Vorgehensweise an den Tag legen würde, so war ich durch die im Buch dargestellten Entwurfsmuster plötzlich sehr positiv gestimmt. Endlich musste ich nicht mehr für jedes Problem das Rad neu erfinden. Endlich konnte ich mir vorstellen, dass es möglich sein muss Code so zu schreiben, dass er nicht nach wenigen Wochen schon so verrottet ist dass nichts mehr geht.

    Nachdem ich die üblicherweise auftretende Patternkrankheit (eine Phase in der man aber auch jedes Pattern unbedingt in seinen Projekten unterbringen muss) überstanden hatte, begann ich mit der testgetriebenen Entwicklung. Auch das ein Schlüsselerlebnis! Endlich Sicherheit. Endlich Zuversicht, dass beim Ergänzen weiterer Features die vorhandenen weiterhin funktionieren.

    Zwei weitere Bücher die mir die Augen geöffnet haben: „Refactoring“ von Fowler und „Refactoring to Patterns“ von Kerievski. In Verbindung mit automatisierten Tests als Sicherheitsnetz hatte ich endlich einen Weg gefunden meinen Code zu verbessern. Endlich kann ich der Software Entropie Einhalt gebieten.

    Die Mischung aus Patterns, Tests und Refactoring waren erste Grundbausteine auf meinem Weg zum Clean Code Developer, ohne dass der Begriff bereits geprägt war. Natürlich musste ich meine eigenen sehr positiven Erfahrungen weiter geben. So habe ich begonnen Vorträge in .NET User Groups zu halten. Aber auch meine Kollegen kamen nicht zu kurz. Sie „durften“ sich manchen Ausbruch von Begeisterung anhören und ernteten oft Kopfschütteln über in meinen Augen völlig unzureichende Praktiken der Softwareentwicklung. Sicher war ich im Eifer des Gefechts manches mal zu ungeduldig und zu fordernd, aber im Laufe der Zeit stellte sich der gewünschte Erfolg durchaus ein.

    So wurden beispielsweise Schnittstellen zu Fremdsystemen in kurzer Zeit entwickelt und liefen sofort nach Auslieferung. Neue oder geänderte Anforderungen können wir nun sehr schnell umsetzen und haben durch die Testabdeckung die Sicherheit, dass alles so funktioniert wie es soll. Inzwischen können wir feststellen, dass der Supportaufwand bei den Altprodukten weiter konstant bleibt oder sogar ansteigt, während bei den nach CCD Manier entwickelten Produkten selten Support anfällt.

    Die Einführung der Prinzipien, Regeln und Praktiken des Clean Code Developers würde mir heute sicher leichter fallen. Als ich begann meine Kollegen damit zu „beglücken“ fehlte manchmal die Struktur. So versteht man den Wert eines Continuous Integration Prozesses wahrscheinlich erst wirklich, wenn man den Nutzen von automatisierten Tests persönlich erfahren hat. Die eigene Reflexion über die Art und Weise wie ich versucht habe meine Kollegen an die Problematik heranzuführen hat mit dazu beigetragen die Clean Code Developer Initiative ins Leben zu rufen. Heute steht mit dem CCD Wiki eine durchdachte Vorgehensweise zur Verfügung die ein einzelner Entwickler oder auch ein Team „lediglich“ anzuwenden braucht. Aus meiner Erfahrung kann ich nur sagen: Es lohnt sich!

    Herzliche Grüße
    Stefan Lieser
    --
    http://www.lieser-online.de/blog/?page_id=151
    • 18 Apr 2009, 12:16 pm