Loading ...Viel zu häufig wird versucht ein Problem durch Workarounds und ausprobieren in den Griff zu bekommen. Insbesondere unter Zeitdruck neigen viele Softwareentwickler dazu schnell ein paar kleine Hacks einzubauen. Aber das rächt sich. Ist die erste Scheiben eingeschlagen, dauert es nicht lange bis Weitere folgen und der Code immer unübersichtlicher wird. Ändert sich eine Anforderung, dann wird es schwer sich an die Hacks und denn damit häufig einhergehenden Seiteneffekte zu erinnern und so sind weitere Probleme vorprogrammiert.
Time to go back to basics!
Nicht umsonst gehören die “Boy Scout Rule” und “Root Cause Analysis” zu den Basics der Softwareentwicklung. Häufig stolpert man selbst im eigenen Code über ungewöhnlich Variablennamen, Schleifenkonstrukte, “Managerklassen” oder Workarounds. Es genügen häufig kleine Änderungen und der Code wird übersichtlicher und erspart einige Kopfschmerzen beim Debuggen. Insbesondere Workarounds sind gefährlich. Sie erscheinen einem das Leben schnell zu erleichtern und das Problem aus der Welt zu schaffen. Besonders wenn wieder einmal der Chef im Nacken sitzt. Doch die hier gewonnene Zeit wird mit hohen Zinsen erkauft. Wer hat nicht schon einmal ein komplettes Modul neu schreiben müssen? Wird unter die Oberfläche des Problems gesehen und das Übel an der Wurzel gepackt, stellt man zudem oft fest, dass sich ein Problem nicht nur sauberer, sondern viel einfacher lösen läßt als gedacht. Die genannten Prinzipien lassen auch in vielen anderen Bereichen gut nutzen oder wie gut ist euer Schreibtisch aufgeräumt? Oder wiederspricht eurer Meinung nach gar alles dem “Keep It Simple, Stupid”-Prinzip und Prokratinationsstapel sind der beste Weg Ordnung zu halten?
