School of .NET – Gedanken zum Curriculum
Name und Konzept stehen, erste Diskussionen über einen möglichen Preis beginnen, da sollten wir doch langsam mal über Inhalte nachdenken.
Wie Ralf schon geschrieben hat, fangen wir “ganz unten” an. Solide Grundlagen sind wichtig um darauf aufbauen zu können. Mit “ganz unten” meine ich aber nun nicht, dass wir in der School of .NET bei Null beginnen. Grundkenntnisse in der Programmierung und im Umgang mit Visual Studio setzen wir schon voraus. Und natürlich setzen wir voraus, dass die Teilnehmer C# beherrschen.
Die große Frage ist jedoch, ob die Beherrschung von C# gleichbedeutend ist mit der Beherrschung des objektorientierten Paradigmas. Ich glaube nein. Wer weiß, wie in C# Felder, Properties und Methoden verwendet werden, weiß damit noch lange nicht, wie die Sprachfeatures sinnvoll, im Sinne der OOP, verwendet werden. Aus eigener leidvoller Erfahrung weiß ich, dass das objektorientierte Paradigma viele Fallstricke zu bieten hat.
Die zweite Frage die sich aufdrängt ist, zu welchem Zeitpunkt man als Entwickler den Schritt vom synchronen zum asynchronen wagen sollte. Vielleicht drängt sich mir diese Frage auf, weil ich mich seit längerer Zeit mit asynchronen Modellen befasse und mir dadurch auffällt, wie schwer der Übergang ist. Fakt ist, Asynchronizität wird immer wichtiger. Folgt man dem aktuellen Hype, gehen unsere Anwendungen bereits in die Cloud, sind damit also asynchron und auf mehrere Maschinen verteilt. Bevor man sich auf dieses Spiel einlässt, sollte asynchron innerhalb eines Prozesses und auch asynchron auf einer Maschine verstanden sein. Doch halt: vor asynchron kommt synchron! Im Sinne der Bewusstseinsebenen steht die Beherrschung synchroner Vorgänge vor dem Thema asynchroner Programme.
Die Art und Weise, wie wir Software entwickeln, können wir ebenfalls unter dem Blickwinkel der Parallelität betrachten. Ein Entwickler ganz für sich alleine arbeitet synchron. Die Asynchronizität im Entwicklungsprozess tritt erst auf, wenn mehrere Entwickler zusammen im Team arbeiten. Erst dann ergibt sich Nebenläufigkeit. Die Herausforderungen steigen damit deutlich an. Denn es liegt in der Natur der Sache, dass nebenläufige Prozesse ab und zu synchronisiert werden müssen. Ein Team von Entwicklern kann nur parallel arbeiten, wenn es die Gesamtaufgabe zuvor partitioniert hat, Komponenten mit Kontrakten definiert hat. Nach einer gewissen Zeit der Parallelität müssen die Komponenten integriert werden. Dies sind Herausforderungen die einen einzelnen Entwickler nicht treffen.
Was heißt das alles nun für ein Curriculum der School of .NET? Ich sehe folgende thematische Abgrenzung als sinnvollen Einstieg:
- Objektorientierung
- Synchrone Entwicklung
- Synchron entwickeln
Dabei verstehe ich unter synchroner Entwicklung das Ausblenden von Nebenläufigkeit. Alle Methodenaufrufe laufen synchron ab. Kein Threading, kein Messaging, keine CCR (tut mir Leid, Ralf). Und mit “synchron entwickeln” meine ich, dass wir uns bewusst nur um den einzelnen Entwickler kümmern, die Herausforderungen einer Entwicklung im Team wie Continuous Integration etc. bewusst ausklammern. Bleibt da genug “Stoff” für 3 Monate? Was kommt danach?
December 22nd, 2009 at 8:44
[...] Zunächst wurde nämlich schon das erste Clean Code Developer Camp in Hamburg gebucht, bevor wir mit den CCD Inhalten im Wiki komplett fertig waren. Das Camp lief über insgesamt 10 Tage, aufgeteilt auf 2 Wochen, die von einer kurzen Pause unterbrochen waren. Ein voller Erfolg! Dennoch beschlich uns das Gefühl, dass es zur “Druckbetankung” möglicherweise eine Ergänzung geben sollte. So haben wir die Idee der School of .NET diskutiert, durchaus auch öffentlich (siehe z.B. hier und hier und hier). [...]