Einstieg für Programmierer - Erweiterung

In seinem Blogeintrag Dschungelwegweiser für Programmieranfänger gibt Rainer Hilmer einige Tipps für den Start ins Programmiererleben. Ich beschäftige mich nun ein knappes Jahr mit der .NET Plattform / Programmierung und bei mir ist diese Zeit daher noch nicht sonderlich lange her. Ich kann daher sehr gut einige Worte dazu verlieren:

Grundsätzlich sind die genannten Quellen sehr gut, setzen aber voraus, dass man schon sehr genau weiß, wo man am Ende landen möchte. Grade am Anfang sollte man sich meiner Meinung nach zunächst auf eine Sprache festlegen. Viele Einsteiger haben schon dort das Problem sich zu entscheiden. .NET bietet sowohl für Einsteiger, als auch für Profis sehr umfangreiche Möglichkeiten, die man je nach Kenntnisstand nutzen kann. Seien wir mal ehrlich, es gibt für einen Anfänger doch nichts schöneres als wenn er sehr schnell echte Erfolge erzielen kann.Und nach einer Stunde eine WindowsForms Anwendung mit Datenbankanbindung zusammen zu klicken halte ich für sehr motivierend. Ist zwar nicht unbedingt sehr sauber, kein wirklich genialer Code. Aber man hat Erfolg. Und Erfolg ist die Motivation, die die Leute bei der Sprache hält.

Apropos Sprache, welche Sprache innerhalb .NET eignet sich denn am Anfang? Visual C++ und F# scheiden in meinen Augen aus. VB.NET und C# scheinen mir eher eine gute Wahl für den Einstieg zu sein. Eine Entscheidungshilfe bietet z.B. auch der Blogeintrag von Golo Roden.

Anmerkung: Wenn jemand natürlich für die Linux Plattform entwickeln möchte würde ich stattdessen zu Java greifen. Aber sowohl Java als auch C# haben den Vorteil, dass man sich Syntaktisch in der Zukunft recht wenig um gewöhnen muss. Erst Recht wenn man zwischen diesen beiden Sprachen tauscht. Ich persönliche habe mich auch genau aus diesem Grund für C# entschieden. Mir liegt 1. die Syntax besser 2. fand ich die Syntax von VB grausam 3. der leichtere Wechsel zu anderen Sprachen.

Bleibt noch der richtige Einstieg: Ich denke, dass man gerade am Anfang nicht um das Lesen eines guten Buchs drum herum kommt, zumindest als Autodidakt. Empfehlen kann ich da beispielsweise C# von Kopf bis Fuß. Kostet leider Geld, ist aber ein super Einstieg, vor allem mit einem guten Lehransatz. Definitiv ein guter Einstieg sind auch die Bücher von Galileo Openbook, sehr umfangreich und kostenlos. Und das nicht nur zu C# und VB ;) Wenn man sich parallel dazu mit den von Rainer genannten Quellen auseinandersetzt hat man eine gute Basis.

Noch ein Satz zu CCD, TDD und anderen Paradigmen: Ich denke, je früher man mit CCD beginnt (wieso findet man bei der Google Suche nach CCD eigentlich nichts, da muss man mal was machen ;) ), desto besser, wohingegen ich mir Dinge wie TDD aufsparen würde, bis man das entsprechende Handwerkszeug parat hat und sich beim Entwickeln in seiner Sprache sicher fühlt.

Mein Forum der Wahl in Sachen C# ist übrigens mycsharp.de .. gute Leute, gute Artikel und gutes Forum ;)

Schönen Tag noch und ich hoffe die Ergänzungen waren hilfreich ;)

Strukturen der Softwareentwicklung - oder der Kampf gegen Windmühlen

Gegen Ende meiner Ausbildung habe ich mich immer stärker dafür interessiert selbst Software zu entwickeln. Wenn auch vielleicht nicht die natürliche Domäne eines FiSis, ist es doch zumindest kein völliges Neuland gewesen. Am Anfang begann es mit simplen kleinen Anwendungen, zu einer Zeit in dem CCD, TDD, refactoring und Codequalität noch mehr oder weniger Fremdwörter waren. Von standardisierten oder geplanten Testverfahren mal ganz abgesehen.
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.