Webdesign TYPO3 Duisburg Produktiv Killer Quelle Infoworld
„Ich bin Clean-Coder und seit 10 Jahren bekennender Agilist“ so die Vorstellung eines Teilnehmers beim Agilen Stammtisch in Düsseldorf. Ich bin mir sicher, daß diese Gattung Webdeveloper ein eigenes Kapitel in der Reihe Produktivkiller für Webdeveloper verdient hätte. Das Gegenteil davon ist wohl der Cowboy Developer. Er schießt IF-Statements locker aus der Hüfte und löst jedes Problem ganz einfach direkt. IF-Statements machen Applikationen kaputt. Code wird nicht mehr wartbar und testbar. Zudem kann eine Anpassung nur noch direkt im Quellcode vorgenommen werden. Häufig findet man diese Ansammlungen von Special Cases bei der Abhängigkeit der Domain, dem Tracking und sonst an Stellen, wo mal eben was anderes passieren musste. Neben den lockeren schießen aus der Hüfte mit IF-Statements haben Cowboy Developer aber darüber hinaus noch schlimmere Waffen. Code Redundanz in Form von ähnlichen Methoden oder auch, daß die gefürchteten IF-Cases über viele Stellen verteilt werden. Das alles lässt eine Applikation unagil werden. Es blickt am Ende keiner mehr durch. Die ganze Programmierung kann nur noch im Try-Error-Modus durchgeführt werden. Tests werden bei Cowboy Developern so oder so belächelt und nach 4 Jahren hat man ein extremes Problem. Und das wird richtig teuer und kann Firmen komplett zerstören. Zusätzlich ist ein extremer Frust bei den Programmierern. Es beginnt eine lange Phase der Code Refaktorisierung. Personalaufwände steigen, Release Zyklen werden größer und neue Features kommen zu spät auf den Markt. Dadurch geht der Wettbewerbsvorteil geht verloren und kann nicht mehr erreicht werden. Es gibt für die Entstehung des Cowboy Developers verschiedene Gründe. Einen großen Teil macht da sicherlich mangelnde Fachkenntnis aus. Das kann bei einem Non-Programmer-Manager natürlich auch gefördert werden. Es gibt verschiedene Möglichkeiten intern mit Cowboy-Developern umzugehen. Sehr wichtig sind hier Code Reviews. Pair Programming muß hier nicht unbedingt gut gehen. Hier muß man schauen was es an Potential zum Macho Developer gibt. Und natürlich kann man bei DEV-Meetings auch in einer Gruppe nach einer besseren Lösung suchen. Das bringt das ganze Team weiter und enger zusammen.
Fazit zum Thema Cowboy Developer
Als ich mich die Tage beim Bahnfahren in diesen Artikel reingedacht habe wollte ich ganz klar sagen, daß Cowboy Development schlecht ist, schadet und sehr teuer wird. Das habe ich auch getan. Und doch lässt mich der „Clean Coder“ nicht los. Angenommen man hat auf der rechten Seite einer Webseite Werbebanner, die über ein CMS System wie TYPO3, gepflegt werden. Der Chef macht Promotion in den USA und bekommt ein tolles Angebot. Wenn die rechte Seite komplett ein bestimmtes Banner hat bekommt er 10.000 neue Besucher pro Tag. Das Telefon klingelt. Es ist Freitag mittag. Die ganze Sache soll bei Parameter ?top=trafiic angezeigt werden. Der Cowboy Developer schießt sofort. if($_GET[‚top‘] == ‚traffic‘) echo $topbanner; else $typobanner; Upload direkt auf live. Rückmeldung an den Chef. Alles ist gut. Der Cleancoder macht das nicht. Der macht ja freitags eh nichts oder Refaktorisierung. „Das kann in dem Release Mittwoch mit online gehen“ ist seine Antwort an den Chef. Wen haben Sie lieber als Mitarbeiter? Ich kenne mehr Cowboy Developer als Clean Coder. Ich selber liege irgendwo dazwischen. Alles andere ist auch Quatsch. Man kann und muß mit IF-Statements Special Cases realisieren. Das darf auch nicht immer 3 Tage dauern. Ein großer Nachteil in der agilen Welt. Die mangelnde Flexibilität. Dafür kann eine Software insgesamt aber flexibler bleiben und schneller große und komplexe Anforderungen integrieren. Das eine ist also eine langfristige Strategie und das andere eine kurzfristige. Einen tollen Hinweis hat der Clean-Coder dann doch noch an dem Abend gegeben. Es bringt nichts, wenn alle in der Firma agil sind, aber der Programmierer dieses Werkzeug gar nicht beherrscht. Wenn jemand nicht agil programmieren kann, dann bekommt die Software auch keine gute Qualität. Daher sollten sich Programmierer viel austauschen und gegenseitig weiterbilden dürfen. Im Team arbeitet es sich immer noch am besten.
