Mit der Zeit kommt dann der Wunsch nach mehr Qualität und Professionalität. Das nötige Interesse vorausgesetzt verschlingt man alles an Material was man in die Finger bekommt, nutzt jede Chance zum Informationsaustausch. Man eignet sich Standards an, lernt Pattern; versucht das zu bekommen, was allgemein als guter Stil bezeichnet wird. Grade die Blogs der diversen deutschen MVP haben mich in Sachen .NET / C#
ein großes Stück vorangebracht. Ein großer Schritt war für mich auch nochmal das Dojo am vergangenen Donnerstag mit Albert Weinert und Ilker Cetinkaya, in dem mir einige Dinge in der vorgehensweise beim TDD nochmal näher gekommen sind. Tja schön und gut. Soweit die Theorie. Wie sieht denn die wirklich eines Softwareentwicklers aus?
Passenderweise fand am Freitag morgen ein Meeting meiner Projektgruppe statt. Mit Blick auf einen verbesserten Entwicklungsprozess habe ich versuchsweise die Kollegen befragt, wie es denn mit dem Kenntnissstand CCD bzw. TDD und agile Methoden aussieht (also die Themen die "in Mode" sind). 2 Hatten es mal gehört die anderen konnten mit den Begriffen nichts anfangen. Mager...ziemlich mager sogar. Tja, bin ich zu ambitioniert? Die anderen desinteressiert? Kann man es sich an der Front nicht leisten Rücksicht auf guten Code zu nehmen? Zählen letztendlich nur Ergebnisse?
Vielen Entscheidungsträgern sind die Vorteile "moderner" Methoden noch nicht klar. Das beginnt schon bei der Beschaffung von Lizenzen. Bis heute gibt es kein resharper Add-in, ein hoch auf meine private Lizenz. Den Zeit Gewinn und damit das Einsparungspotential hingegen möchte wohl niemand sehen. Dort steht erst einmal nur die Investition. Analog sieht es da mit Schulungen und Qualifikationen aus. Zuviel muss hier noch selbst initiiert werden. Keine Initiative der Führungskräfte.
So helfen einem auch die besten Methoden und Werkzeuge nichts, wenn sie bei der Masse an Entwicklern nicht ankommen. Denn Hand aufs Herz, so wie hier beschrieben ist es leider noch viel zu oft.
Nur ein relativ geringer Anteil an Entwickler hat entweder die Chance oder die Muße sich auf dem aktuellen Stand zu halten. Sei es nun aus mangelndem Interesse oder mangelnder Möglichkeit.
Dabei ist doch gerade die Weiterentwicklung und Anpassung alter Strukturen an neue Gegebenheiten unser Kapital als Entwickler.
Ein Beispiel gefällig? Der ein oder andere wird sicher die "null" Diskussion verfolgt haben. In der Vorstellung eines vergleichsweise simplen Codefragments kam die Frage auf, ob null ein aktzeptabler Rückgabewert sei ( Blog von Thomas Bandt). Einige bekannte Köpfe der .NET Szene haben daraufhin ihre Meinung dazu dargestellt. Diese haben jedoch einen nicht zu verachtenden Vorteil: aufgrund ihrer Tätigkeiten haben sie wesentlich größeren Einfluss auf den Verlauf eines Projekt. Für den "normalen" Entwickler liegt hier wahrscheinlich nichtmal ein Problem vor. Wie denn auch wenn er keine Zeit hat darüber nachzudenken?
Natürlich kamen bei der Diskussion einige sehr interessante Ergebnisse heraus. Doch wie Praxisrelevant können dort formulierte Regeln sein? Die zweifellos gut gemeinten Ideen sind sehr wertvoll, kommen jedoch nicht bei dem breiten Entwicklerstamm an.
Tja und ich als Einzelkämpfer? Lohnt es sich den Kampf aufzunehmen und trotz mißtrauischen Blicken im Hinblick auf TDD und dem Versuch, die Werte des CCD zu verinnerlichen dieses Konsequent anzuwenden, auch wenn der Rest des Teams anders arbeitet?
Ich denke ja. Die einzige Chance ist es mit gutem Beispiel voranzugehen und zu zeigen, welche Vorteile in den Möglichkeiten moderner Softwareentwicklung stecken. Wenn zumindest mein Code durch TDD Fehlerfrei läuft und dank den Werten des CCD besser les- und wartbar ist, ist das doch irgendwie auch schon ein Erfolg, oder?
Und wer weiß, vielleicht fängt dann auch jemand anderes an, über den Tellerrand zu schauen.
Nabend,
AntwortenLöschenich finde die Ansichten des obigen Artikels durchaus interessant, und bis vor knapp einem Jahr hätte ich dir in sämtlichen Punkten zugestimmt.
Es gibt absolut nichts ärgerlicheres, als ein Stück Code vor sich zu haben, das man warten soll, das aber a) absolut unlesbar und b) absolut nicht kommentiert ist. Und c) wahrscheinlich auch höchstens halbherzig und mit Werten, von denen man von Anfang an weiß das es funktioniert, getestet wurde.
Was ich allerdings vor knapp einem Jahr im Verlauf meines Studiums gelernt habe, ist folgendes: Programmierer, und hier meine ich wirklich Programmierer, das was man im allgemeinen als "Codesklaven" bezeichnen würde, Leute also, die zwar mit Codezeilen zaubern können, von Algorithmik, effizientem Design und Modellierung und Verifikation nur sehr begrenzt Ahnung haben, sehr bald ebenso veraltet sein werden wie heutzutage die Fähigkeit, Platinen löten zu können, und zwar aus dem gleichen Grund: Die Automatisierung hat sie überholt. Die Modellbasierte Softwareentwicklung sowie die Modellbasierte Verifikation sind bereits sehr weit entwickelt, hier hilft ein Blick weg vom Minimarkt der Windowsanwendungen zum großen Markt der Eingebetteten Systeme. Und die Codegenerierung wird in 10-15 Jahren den Programmierer in punkto Effizienz des Codes sowie dessen Entwicklung überholt haben. Ein schönes Beispiel dafür ist der Compilerbau: Egal welch ein toller Hengst man in der Assemblerprogrammierung ist, niemand kann den heutigen Compilern das Wasser reichen...ausser natürlich man spielt derren Algorithmen von Hand durch. ;-)
Was ich damit sagen will: Möglicherweise wäre es klüger, sich mit Modellbasierten Konzepten auseinander zu setzen, anstatt mit dem Code. Den wird nämlich ein Computer in vielleicht 10 Jahren genauso gut und besser und vor allem fehlerfrei generieren können.
Wie bereits gesagt, wo die Entwicklung hier hingehen wird sieht man am besten im Bereich der eingebetteten Systeme, und hier vor allem bei den sicherheitskritischen Systemen.
Hallo Michael,
AntwortenLöschendanke für deinen Kommentar, durchaus ein interessanter Ansatz den du hier beleuchtest. Und grade weil mit den modernen Werkzeugen vieles vereinfacht wird, übe ich die oben beschriebene Kritik.
Was uns die Werkzeuge nicht abnehmen können ist die Logik, das denken hinter der Anwendung. Ich halte es auch wichtig wegzukommen von dem Codesklaven. Hin zu mehr eigenständigem Denken und Verantwortung. Doch das kann nur passieren, wenn die Entwickler über ihren Tellerrand schauen können und dürfen. In einigen Bereichen ist der Codesklave ja durchaus gewünscht. Der denkt nicht und tut seine Arbeit. Kostet also auch weniger. Das dabei die Qualität der Anwendung leidet, merken viele nicht. Widerspricht also deinen Gedanken keinesfalls!