Peter Bucher Ralf Westphal

Blog

Nutze den Augenblick
und teile der Welt mit, was Du zu sagen hast.

.NET Professionals im Profil: Ralf Westphal

Freitag, 15. Januar 2010, 09:37 Uhr
Permalink | Kommentare (0) | Kommentare als RSSRSS

Ralf Westphal ist freier Softwaretechnologievermittler, Mitgründer des Professional Developer College und Mitinitiator von Clean Code Developer. Er war von 1998 bis 2005 einer der unabhängigen Microsoft Regional Directors für Deutschland und wurde von Microsoft als MVP „Visual Developer Solution Architect“ ausgezeichnet. Sie erreichen ihn über seine Webseite.

Golo Roden: Ralf, wie bist Du zur Softwareentwicklung gekommen? Wie und wann hast Du angefangen?

Ralf Westphal: Wenn ich mich recht erinnere, habe ich 1980 mit dem Programmieren angefangen. Oder war es schon 1979? Jedenfalls stand am Anfang ein Büchlein mit einer Einführung in Pascal. Ganz ohne Computer habe ich das in einem Urlaub durchgearbeitet. Da ging es vor allem um Algorithmen: Sortieren, die Türme von Hanoi und solche Sachen. Danach dann die offizielle Pascal Sprachdefinition. Die hat mich mit der EBNF konfrontiert. Nach dem Urlaub begann der Informatikunterricht in der Schule. Für den hatte ich mich fit gemacht. Unterrichtssprache Pascal. Auf einer Dietz-Anlage mit Bernsteinterminals. Der Lehrer war durchaus bemüht und offen für unsere Ideen. War eine lustige Zeit.

Irgendwie in der Zeit habe ich mich dann auch um einen Computer zu Hause bemüht. Am Anfang war das ein Tandy TRS-80. Darauf habe ich Z-80-Assembler programmiert, zum Beispiel einen Texteditor. Danach kam ein Apple II mit CP/M-Betriebssystem, weil ich weiter Z-80-Assembler programmieren können wollte. Mit Apple Basic habe ich nur wenig gemacht – aber doch zumindest einen ersten Job realisiert. Und meinen ersten Artikel für die damalige Computer Persönlich-Zeitschrift von Markt + Technik habe ich auch über ein Programm in Apple Basic geschrieben. Da ging es irgendwie um die Komprimierung von Programmcode, weil der Hauptspeicher so begrenzt war. Der nächste Artikel hat sich auf der Basis von UCSD Pascal mit 3D-Grafiken beschäftigt.

Als ich 1983 zur Bundeswehr kam, habe ich den Apple mitgenommen und einige Verwaltungsaufgaben damit auf dem Geschäftszimmer erledigt. Ich wurde dort eingesetzt, weil ich durch die Computerarbeit flüssig mit einer Schreibmaschine beziehungsweise einer Tastatur umgehen konnte.

Und weiter? Hm ... in der Uni haben wir eher auf größeren Anlagen gearbeitet. Da erinnere ich mich an ein Seminar in Assembler. Ausbildungssprache Pascal. Gelernt habe ich dort nicht mehr viel. Privat ging es mit Turbo Pascal weiter. Das hatte ich seit meiner Schulzeit, fand es supercool und habe sogar ein Lehrbuch für die Schule dazu geschrieben. Leider ist das nie zum Einsatz gekommen.

Später bin ich auf C und Modula mit CP/M umgestiegen. Das war leading edge technology damals. Beides war von der Firma Lightspeed und konnte sogar zusammengelinkt werden.

„Auf der Arbeit“ bin ich eher mit Unix konfrontiert worden. Zum Beispiel habe ich für ein Forschungsinstitut einen Ganzseiteneditor gebastelt, mit dem man vernünftig – so wie damals mit WordPerfect – Prolog-Code schreiben konnte. VI war den Forschern und auch mir zu umständlich.

Weiter ging es mit 4GL-Sprachen und Smalltalk. Und schließlich ab 1990 C++ für ein bis zwei Jahre. Ab Visual Basic 1.0 dann Visual Basic bis zum Abwinken.

Golo Roden: Du hast Dich auf die .NET-Plattform spezialisiert. Warum gerade .NET und nicht beispielsweise JEE (Java Enterprise Edition)?

Ralf Westphal: Java hat mich 1995 interessiert. „Java in a Nutshell“ oder so hatte ich schon vor dessen Erscheinen bestellt. Ich fand die Sprache auch cool – sie bot damals wegen ihres Fokus auf die Webentwicklung nichts für die Desktop-Branchensoftwareentwicklung. Von 1987 bis 1998 habe ich ja mit einem Partner ein Branchensoftware-Schmiede gehabt – er macht das auch heute noch –, bei der wir MS-DOS- und später Windows-Anwendern etwas bieten mussten. Das Web war ja nur für mutige Early Adopters interessant. Nach einer 4GL-Lösung, die wir ab 1987 entwickelt hatten – und die auch heute noch bei einigen Anwendern im Einsatz ist! – hatten wir auf Visual Basic gesetzt. C++ war uns zu umständlich, Delphi noch nicht ausgereift genug. Also Visual Basic von 1.0 bis 6.0. Außerdem kam dann 1996 / 1997 oder so ASP um die Ecke, so dass wir im Web auch mit unseren Visual Basic-Kenntnissen arbeiten konnten. Java bot uns angesichts dessen zuwenig. Damit war die Weiche gestellt. Als ich 2000 .NET auf der PDC gesehen hatte, wusste ich, dass das der natürlich weitere Weg sein würde.

Golo Roden: Ein wesentliches Merkmal der IT ist, dass man beständig mit neuen Entwicklungen konfrontriert wird, und diesen folgen muss. Woher nimmst Du die Motivation, Dich quasi jeden Tag weiterzubilden und mit Neuem zu beschäftigen?

Ralf Westphal: Das ist mein Job. Dieselbe Antwort gibt dir ja auch ein Bäcker, wenn du ihn nach der Motivation fragst, die ihn jeden Tag Brötchen backen lässt. Im Vergleich zum Entwickler in einem Projekt empfinde ich also keine Spannung zwischen „Arbeit“ und „Fortbildung“. Meine Arbeit ist Fortbildung. Der Zweck: Anderen mit meinem Wissen zu helfen. Ich bin kein „Programmierer“, sondern eher „Softwaretechnologievermittler“. „Trainer“ wäre zu eng gefasst, „Lehrer“ zu institutionell, „Berater“ auch zu eng. Also „Technologievermittler“ und „One Man Think Tank“. Diese Bezeichnung habe ich nach einigem Grübeln gewählt für meine „Firma“ gewählt, weil sie ausdrückt, was und wie ich arbeite: In der Form bin ich Freiberufler, arbeite also allein. Zumindest habe ich solch einen Hut, den ich aufsetze. Inzwischen gibt es noch andere wie „Mitgründer des Professional Developer College“ oder „Mitinitiator von Clean Code Developer“. Wenn ich diese Hüte aufsetze, arbeite ich nicht allein, sondern mit Partnern. Ursprünglich war ich aber eben reiner „Einzelkämpfer“ seit 1998, also „One Man“ Show.

Der „Think Tank“ beschreibt eher den Inhalt meiner Arbeit. Mein Job ist das Nachdenken, das Tüfteln, Ausprobieren. Ich möchte es fast schon als Forschung bezeichnen. Meine Ergebnisse sind weniger Code, als vielmehr Konzepte, Ansätze. Damit erlaube ich mir etwas, das sich viele Unternehmen und Teams nicht erlauben. Während Kollegen eher „normale“ Beratung machen, bei der sie sich auf Technologien konzentrieren, deren Einsatz begleiten oder sie gar für ihre Kunden einsetzen, bewege ich mich oft eine Ebene darüber, das heißt im Konzeptionellen.

Natürlich programmiere ich auch. Jeden Tag. Ich habe also keine Angst, abzuheben. Doch wenn schon die Firmen ihren Kopf nicht aus dem Sand der Projekte heben können, dann will zumindest ich das tun. Das macht mir Spaß, das kann ich – so glaube ich – ganz gut. So sehe ich mich als Ergänzung zu Teams, die sie bei Bedarf „zuschalten können“. Die externe Forschungsabteilung, der Blick von außen, der Spiegel, der Fragensteller, der Impulsgeber.

Damit ich das alles sein kann, muss ich halt immer etwas Neues auf der Pfanne haben, lesen und nachdenken. Früher hatte ich da mal Angst, dass ich da an eine inhaltliche oder motivationale Grenze stoßen könnte. Bisher spüre ich davon nichts. Vor 18 Monaten hatte ich noch keine Ahnung, dass ich heute mit Clean Code Developer unterwegs sein würde. Was in 18 Monaten ist, weiß ich auch nicht. Ich bin aber gewiss, da wird mich etwas Neues, Spannendes beschäftigen, das ich dann in die Community tragen kann.

Golo Roden: Wenn sich ein Anfänger heute mit dem Thema Softwareentwicklung befassen will – welche Voraussetzungen sollte er Deiner Meinung nach dafür mitbringen, und was siehst Du als No-Go an?

Ralf Westphal: Welche Art Anfänger meinst du? Einen Schüler, der noch nicht so recht weiß, was er mal werden will? Oder jemanden, der schon in eine Informatikausbildung eingestiegen ist? Oder jemanden, der gerade damit fertig geworden ist?

So ganz allgemein und grundlegend würde ich mal sagen, dass jemand, der sich mit Softwareentwicklung beschäftigen will, Spaß am Nachdenken haben sollte. Das Denken, Nachdenken, Selbstdenken steht de facto leider nicht wirklich hoch im Kurs in unserer Gesellschaft. Zwar sollen Schüler das Denken lernen – dafür ist Schule ja da –, doch passiert das nicht verlässlich genug, meine ich. Solange noch Talentshows und Sport solchen Raum in den Medien einnehmen, wie sie es tun. Solange sich die Nation so unverhältnismäßig über etwas wie die Schweinegrippe echauffieren kann. Solange es gesellschaftsfähig ist, mit technischer, geschichtlicher, philosophischer Unbildung zu kokettieren, solange steht Nachdenken einfach nicht hoch im Kurs.

Das soll jetzt natürlich nicht bedeuten, dass die Welt mehr freiberufliche Nachdenker wie mich braucht. Ich meine nur, dass in der Softwareentwicklung, deren Materie das Virtuelle und Abstrakte ist, Nachdenken ganz wichtig und daher Spaß am Nachdenken Voraussetzung ist. Software entsteht zunächst im Kopf durch rigoroses, systematisches und kreatives Denken mit einer gehörigen Portion Reflexion und Skepsis.

Zum Spaß am Denken sollte dann noch Spaß am grundsätzlich Technischen kommen. Auch da steht es leider in der Grundausbildung schlecht. Technische Unbildung grassiert. Nicht nur ist den meisten schon der Dreisatz ein Buch mit sieben Siegeln, auch die mechanische oder elektronische Funktionsweise von Maschinen interessiert viele nicht. Was unsere moderne Welt zusammenhält – Technologie – wird nicht systematisch als interessant vermittelt. Fernseher und Computer und Handy benutzen alle gern – doch die nächsten Generationen selbst mitgestalten, dazu haben sie keine rechte Lust. Anders kann ich mir die sinkenden Studentenzahlen bei der Informatik nicht erklären.

Zum Spaß am Denken und an Technik im Allgemeinen – Grundfrage: Wie funktioniert das? – sollten noch Fertigkeiten der Visualisierung treten. Software entsteht im Kopf und muss dann kommuniziert werden. Nicht unbedingt in Form von Code, sondern zuerst einmal mit Bildern. Auch Nachdenken profitiert von Bildern. Wer ein gutes Vorstellungsvermögen hat – vor allem ein bildliches – und seine Vorstellungen dann auch noch anderen vermitteln kann, der hat einen Vorsprung. Das habe ich gerade gestern beim Unterricht in der School of .NET gesehen. Die Teilnehmer konnten sich eine Lösung für eine Übungsaufgabe so schwer vorstellen; ihnen fehlten Bilder für ein Modell. Deshalb gab es dann Probleme bei der Codierung.

Noch allgemeiner als Fertigkeiten zur Visualisierung sind solche zur Kommunikation schlechthin. Software ist kein Business für „lonesome rangers“. Der einsame Hacker ist out. In sind Entwickler, die fachliche und methodische Kompetenzen, die sie in einer Ausbildung erwerben, dank Softskills in ein Team einbringen können. Wissen und Ideen nicht nur visuell vermitteln können, sondern auch verbal, das ist wichtig. Zuhören können, emotionale Kompetenz, Selbstdisziplin, moderieren, ... das sind Fertigkeiten, die wir brauchen. Software entsteht im Team.

Die Motivation für eine Karriere in der Softwareentwicklung kommt also für mich aus dem Spaß am Denken, am Abstrakten und an Technik. Die Fähigkeit, sich dann auch erfolgreich einzubringen, machen Softskills aus. Fachkompetenz vermittelt – hoffentlich – eine Ausbildung.

Golo Roden: Gemeinsam mit Stefan Lieser hast Du die Initiative „Clean Code Developer“ ins Leben gerufen. Welche Bedeutung misst Du diesem Thema bereits für Anfänger bei?

Ralf Westphal: Die Bedeutung von Clean Code Developer für Anfänger ist nicht zu überschätzen! Hohe innere Qualität ist keine Sache für fortgeschrittene Entwickler. Sie muss vielmehr vom ersten Tag der Ausbildung an Thema sein. Das ist auch der Grund, warum mich so viele Lehrpläne von Berufsschulen und Universitäten traurig machen. Sie vermitteln einzelne technische Fertigkeiten – aber kein qualitätsorientiertes Bild von der Softwareentwicklung. Beispiel Berufsschule, Ausbildung zum Fachinformatiker Anwendungsentwicklung (FIAE): Nur ein Achtel des Unterrichts sind überhaupt der Softwareentwicklung gewidmet, der Rest beschäftigt sich mit Deutsch, Religion und anderen Themen. Von diesem Achtel beschäftigen sich in einem Semester vielleicht fünf Prozent mit dem Thema Testen. Das sind weniger als ein Prozent in einem Jahr und auf drei Jahre gerechnet vielleicht 0,5 Prozenz, wenn es hoch kommt. Was wollen wir denn da erwarten von ausgebildeten FIAE, wenn sie während oder nach der Ausbildung im Projekt sitzen? Fangen die dann plötzlich mit TDD an?

Für mich liegt die Ausbildung solange im Argen, wie das Thema Testen nicht von der ersten Stunde an konsequent während des ganzen Unterrichts präsent ist. Soviel zum Thema Korrektheit. Dasselbe gilt für die anderen CCD-Werte wie Evolvierbarkeit, Produktionseffizienz und Reflexion.

Vom ersten Tag an. Die ganze Ausbildung durch. Immer. Nur wer diese Werte konsequent bewusst hält, kann am Ende erwarten, sie auch unter Projektdruck nicht zu verraten.

Klar, man kann auch später noch dazu lernen. Aber dann ist es schwieriger. Dann sind eingefahrene Gewohnheiten zu entlernen. Das macht große Mühe – und die Codebasis ist schon ein Brownfield. Warum also nicht mit CCD bei den Anfängern beginnen?

Golo Roden: Bei der Vielzahl an Technologien, die es heute gibt: Womit sollte ein Anfänger heutzutage anzufangen?

Ralf Westphal: Keine Ahnung. Es gibt keinen richtigen Einstieg in Technologien – oder gar Produkte. Die unterliegen ja auch Moden. Selbst wer heute mit PHP beginnt, kann einen guten Job bekommen, glaube ich. Insofern ist die Frage, ob jemand dazu fähig ist, sich selbst und die Marktentwicklung zu reflektieren. Wer das kann, kann dann nämlich auch reagieren. Der fängt mit PHP an und sattelt später um auf Erlang oder so.

Was nutzbringend ist, hängt vom Umfeld ab. Für einen Studenten wäre es vielleicht nicht sehr nützlich, wenn er sich als einziger in seinem Umfeld mit Axum beschäftigt. Dann gehen ihm soziale Kontakte und dadurch Möglichkeiten zum Austausch verloren. Die sind nicht zu verachten.

Ich denke, jeder ist gut beraten, seine Neigungen zu erspüren. Mag man es lieber visuell oder lieber persistent? Mag man es lieber enterprisegroß oder branchensoftwareklein? Das lässt sich aber womöglich erst mit der Praxis erfahren. Als Anfänger muss man deshalb wahrscheinlich einfach mit irgendetwas anfangen.

Technologien sind auch nicht so wichtig. Wichtiger sind Paradigmen und Konzepte. Die Frage sollte also lauten, mit welchen der Paradigmen sollte sich ein Anfänger auseinandersetzen. Da liegt die Objektorientierung nahe. Aber ich füge gleich einmal die Komponentenorientierung hinzu. Da liegt Agilität nahe. Da liegt die asynchrone Programmierung nahe. Da liegen Algorithmen und Datenstrukturen nahe. Ja, auch und gerade die. Da liegen Kommunikationskonzepte wie Nachrichtenorientierung und ereignisgesteuerte Architekturen (EDA) nahe.

Aber ob man sich damit nun auf der Java- oder .NET- oder Ruby-Plattform beschäftigt, ist recht egal. Und ob es bei .NET nun NServiceBus oder MassTransit für EDA ist, ob O/R-Mapping mit OpenAccess oder NHibernate gelernt wird, ... das ist egal.

Die wesentliche Invariante ist: Alles ändert sich. Also nicht anhaften. Keine Paradigma, kein Konzept und schon gar kein Produkt auf einen Thron heben. Denn wo gestern ASP oder Java-Applets die Bringer waren, da ist heute Silverlight der Hit. Alles fließt – wusste schon Heraklit, der unsere Branche nicht kennen konnte-

Golo Roden: Welchen Rat würdest Du einem Anfänger abschließend mit auf den Weg geben?

Ralf Westphal: Widerstehe dem oft ignoranten Druck im Projekt. Da wird auf die Tube gedrückt, da wird keine Zeit für Fortbildung gegeben, da wird kein Wert auf Evolvierbarkeit gelegt. Vor 150 Jahren waren Arbeitsbedingungen in Fabriken mit 16 Stunden Arbeitszeit bei Dreck, Lärm und kärglicher Bezahlung unmenschlich. Heute ist es natürlich viel besser – und auf der anderen Seite immer noch schlimm. Anders schlimm, subtiler schlimm.

Heute stimmt zwar die Bezahlung und so ganz grundsätzlich meist auch die Arbeitszeit. Aber vieles andere stimmt immer noch nicht oder nicht mehr. Menschen wollen es bei der Arbeit nicht nur warm haben und Geld heimtragen, sondern auch Spaß haben und sich einbringen. Dazu sind viele Projekte nicht angetan. Leider.

So mancher Chef schaut – aus welchem Grund auch immer – nur darauf, dass möglichst schnell irgendwie der Kunde befriedigt wird. Das ist kurzfristiges Denken, bei dem Kreativität und Motivation und Qualität über kurz oder lang auf der Strecke bleiben.

Deshalb rate ich, hier sehr sensibel zu sein. Fortbildung ist nicht nur Sache des Mitarbeiters. Innere Softwarequalität ergibt sich nicht von selbst. Motivation ist nicht egal. Wo Projekte darauf keinen Wert legen, ist daher Gefahr im Verzug. Gefahr der baldigen Unzufriedenheit, weil die technische Schuldenlast den Spaß an der Arbeit vergällt. Wer im Brownfield-Morast steckt und auch noch unter Druck arbeitet, treibt auf den Burnout zu.

Aber nicht nur Unlust droht, sondern schlicht schlechtere Chancen auf dem Arbeitsmarkt. Wer keine Gelegenheit zur Fortbildung bekommen hat und nach zehn Stunden am Arbeitsplatz nicht mehr selbst die Energie aufbringen konnte, der fällt zurück. In fünf Jahren hat er den Anschluss verpasst. Heute zum Beispiel noch Visual Basic 6.0-Projekte zu warten, ohne aktiv an .NET-Projekten zu arbeiten, ist unverantwortlich, würde ich sagen. Da wird nicht nur die Visual Basic 6.0-Altlast fortgesetzt, sondern auch eine Entwickleraltlast produziert.

Letztlich ist das jedoch eine Entscheidung, die jeder Entwickler selbst treffen muss. Welche Arbeitsbedingungen will ich zu welchem Preis aushalten? Also: Augen offen halten. Was tut sich in der Softwarewelt? Wenn die Differenz zur eigenen Welt zu groß wird – das kann schnell geschehen –, dann handeln. Insofern sollten Softwareentwickler auch einiges an Veränderungsfreude mitbringen.

Review von Cloud Computing mit der Windows Azure Platform

Dienstag, 5. Januar 2010, 14:51 Uhr
Permalink | Kommentare (3) | Kommentare als RSSRSS

Nachdem ich vor knapp zwei Wochen einen Review über das Buch Pragmatic Unit Testing veröffentlicht habe, begann ich mit der Lektüre des nächsten Buchs: Cloud Computing mit der Windows Azure Platform von Holger Sirtl.

Der Untertitel verspricht Informationen zu der Entwicklung, der Integration und dem Betrieb cloud-basierter Anwendungen – was dann jedoch auf den ersten 75 Seiten mehr als ausreichend beschrieben wird, sind die allgemeinen Vor- und Nachteile von Clouds im Allgemeinen und von Windows Azure im Speziellen.

Obwohl dies prinzipiell nicht verkehrt ist, weist es die Tendenz für den weiteren Verlauf des Buchs: Der Inhalt, der auf rund 350 Seiten vermittelt wird, würde problemlos auf 200 Seiten passen, würden die ständigen Wiederholungen entfallen. Ungewollt beschleicht einen immer wieder das Gefühl, bestimmte Formulierungen schon einmal gelesen zu haben.

Sobald das Buch zu seinem fachlichen Teil kommt, steigt die Qualität des Inhalts deutlich an: Alle wichtigen Konzepte von Windows Azure werden erläutert und mit Beispielen demonstriert:

  • Web Role und Worker Role
  • Blobs, Tables und Queues
  • Live Services
  • .NET Service Bus
  • .NET Access Control
  • Deployment

Allerdings lässt das Buch auch hierbei einen kompakten Schreibstil vermissen und besteht zum Großteil aus den immer gleichen Formulierungen.

Vermisst habe ich bei dieser Ausführlichkeit einige grundlegende Erklärungen, speziell das Kapitel zu den Live Services erläutert zahlreiche Begriffe nur äußerst knapp und verwendet diese danach wie selbstverständlich – für jemanden, der noch nie mit Windows Live entwickelt hat, gestaltet sich dieses Kapitel dadurch verhältnismäßig schwierig.

Abgerundet werden diese Themen durch einige Beispiele für den Software plus Services-Ansatz, vom Desktopclient über Web- bis hin zu mobilen Anwendungen ist alles dabei, was für einen Entwickler interessant sein könnte. Auch das Thema Interoperabilität mit Java, PHP und Ruby wird angesprochen.

Insgesamt erhält man einen guten Überblick zu Windows Azure, dem es allerdings auf der einen Seite teilweise an Tiefe fehlt, und der auf der anderen zu sehr in die Länge gezogen ist. Sofern man sich damit arrangieren kann, ist das Buch kein schlechter Einstieg in Windows Azure – wer ein rundum empfehlenswertes Buch erwartet, sollte Abstand nehmen.

this oder kein this

Freitag, 1. Januar 2010, 09:37 Uhr
Permalink | Kommentare (2) | Kommentare als RSSRSS

Am 13. Oktober 2008 haben Peter Bucher und ich unter dem Titel Noch Fragen, Bucher? Ja, Roden! angekündigt, jeweils zum ersten eines jeden Monats einen Kommentar zu einem vorab gemeinsam gewählten Thema verfassen zu wollen. Bisher sind in dieser Reihe folgende Kommentare erschienen:

Heute, am 1. Januar 2010, ist es nun wieder so weit, und unser Thema für diesen Monat lautet:

this oder kein this

So wohl Peter wie auch ich haben uns unabhängig voneinander im Vorfeld unsere Gedanken gemacht, wie wir diesem Thema gegenüberstehen. Peters Kommentar findet sich zeitgleich in seinem Blog, folgend nun mein Kommentar zu diesem Thema:

Zumeist sind Schlüsselwörter innerhalb einer Programmiersprache mit einer eindeutigen Semantik belegt; auch C# stellt keine Ausnahme dieser Regel dar. Jedoch gilt dies zumindest in C# wohlgemerkt nicht für alle Schlüsselwörter, denn einige haben – je nach Kontext – verschiedene Bedeutungen.

Ein bekanntes und weit verbreitetes Beispiel hierfür ist das Schlüsselwort using, das so wohl als Direktive wie auch als Anweisung verwendet werden kann:

  • Als Direktive dient es zunächst dazu, andere Namensräume bekannt zu machen, so dass die darin enthaltenen Typen ohne Angabe ihres vollqualifizierten Namens genutzt werden können.
  • Die Direktive dient zusätzlich jedoch auch der Bildung von Aliasnamen, wobei dies wiederum so wohl für Namensräume wie auch für einzelne Typen möglich ist.
  • Als Anweisung schließlich definiert using in Verbindung mit der IDisposable-Schnittstelle einen Gültigkeitsbereich, an dessen Ende automatisch die Dispose-Methode des gekapselten Objekts aufgerufen wird.

Doch nicht nur using ist mit verschiedenen Bedeutungen belegt – ein weiterer Kandidat mit zahlreichen Varianten ist das this-Schlüsselwort:

  • In Verbindung mit Konstruktoren dient das this-Schlüsselwort dazu, den Aufruf an einen überladenen Konstruktor der gleichen Klasse weiterzuleiten.
  • Mit this ist es zudem möglich, Indexer zu definieren – also Eigenschaften, die über keinen eigenen Namen verfügen, allerdings parametrisiert mit einem Index aufgerufen werden können.
  • Seit C# 3.0 dient this als Kennzeichner für Erweiterungsmethoden, indem mit Hilfe dieses Schlüsselworts festgelegt wird, welches Argument dem aufrufenden Objekt entspricht.
  • Schließlich dient this – wie bereits in C++ und Java – auch als Referenz auf das eigene Objekt. Auf diese Art kann auf Elemente der Klasse zugegriffen werden, deren Namen durch gleichnamige Parameter ansonsten ausgeblendet und damit nicht zugreifbar wären.

Im Gegensatz zu using, dessen Angabe immer erforderlich ist, kann this gegebenenfalls entfallen: Während seine Verwendung bei der Verkettung von Konstruktoren, Indexern und Erweiterungsmethoden obligatorisch ist, kann die Eigenreferenz entfallen – sofern der Name des betroffenen Elements nicht ausgeblendet wird.

Die Frage lautet allerdings, ob es sinnvoll ist, this in den optionalen Fällen zu streichen. Zunächst scheint es so, schließlich erspart man sich einige Zeichen zu tippen, zu lesen und vermeidet unnötige Redundanz. Auch ReSharper empfiehlt bei Verwendung der Standardeinstellungen, redundante this-Schlüsselwörter zu entfernen.

Neben diesen Vorteilen birgt das Entfernen von this jedoch auch einen essenziellen Nachteil: Es ist nicht mehr auf einen Blick ersichtlich, ob ein Zugriff auf ein Element des aktuellen Objekts stattfindet. So ist bei der Zeile

_foo = new Foo();

nicht klar, ob es sich um eine statisches Feld oder ein Instanzfeld handelt. Wird das Schlüsselwort this jedoch konsequent verwendet, ist auf den ersten Blick eindeutig, dass es sich um ein statisches Feld handelt, ansonsten müsste die Zeile nämlich

this._foo = new Foo();

lauten. Während diese Mehrdeutigkeit bei Feldern noch zu vertreten sein mag, wird es bei Eigenschaften bedeutend schwieriger: So bestehen für die Zeile

Foo.Bar();

bereits drei Möglichkeiten, welcher Aufruf sich dahinter verbirgt: Zum einen könnte Foo eine Eigenschaft sein, an der eine Methode namens Bar aufgerufen wird. Es ist jedoch nicht eindeutig, ob es sich bei der Eigenschaft um eine statische oder eine instanzbehaftete Eigenschaft handelt.

Neben diesen zwei Möglichkeiten könnte es zudem sein, dass Foo gar keine Eigenschaft, sondern eine statische Klasse bezeichnet, die ihrerseits wiederum eine Methode Bar() enthält.

Der Unterschied zwischen einer statischen Eigenschaft und einer statischen Klasse lässt sich ohne weiteres nicht auflösen – zumindest der erste Fall kann aber durch Verwendung von this explizit gemacht werden. Bei der Zeile

this.Foo.Bar();

ist nämlich auf den ersten Blick ersichtlich, dass eine Methode an einer Eigenschaft aufgerufen wird, die instanzbehaftet ist.

Diese Beispiele zeigen, dass die konsequente Verwendung von this durchaus ihren Teil zu einer besseren Verständlichkeit des Quellcodes beitragen kann.

Da Code in der Regel derart geschrieben wird, dass er für die Zukunft wie auch für andere Entwickler gut lesbar ist, kann es durchaus eine vernünftige Entscheidung sein, this generell zu verwenden – insbesondere auch in den redundanten Fällen, um die Semantik des Codes explizit zu machen.

Für welche Variante auch immer ein Entwickler beziehungsweise ein Team sich entscheidet, wichtig ist – wie so oft, wenn es um das Thema Coderichtlinien geht – dass die einmal getroffene Entscheidung konsequent eingehalten wird. Alles andere führt über kurz oder lang zu Missverständnissen.

LightCore

Freitag, 1. Januar 2010, 00:00 Uhr
Permalink | Kommentare (1) | Kommentare als RSSRSS

Vor ungefähr neun Monaten habe ich in meinem Blogeintrag Microkernel im Eigenbau beschrieben, wie mit wenigen Zeilen ein eigener Microkernel unter .NET realisiert werden kann. Auch wenn diese Variante durchaus für einfache Szenarien genügt, bestehen in der Praxis häufig weitere Anforderungen.

Da in der Regel kein eigener Microkernel entwickelt werden soll, bleibt die Wahl der Qual, welcher Microkernel zum einen die eigenen Anforderungen erfüllt und zum anderen aber zugleich dem persönlichen Gusto am ehesten entspricht. Erschwert wird die Wahl dabei durch die Vielzahl der verfügbaren Systeme.

Wie viele andere Entwickler konnte auch ich mich in der Vergangenheit nicht eindeutig für ein einziges System entscheiden:

  • So hat mir autofac zwar mit seinem an C# 3.0 angelehnten Programmiermodell mit umfangreicher Nutzung von Lambdaausdrücken zugesagt, nicht jedoch von der Performance.
  • Unity hingegen gefällt mir ebenfalls von dem verwendeten Programmiermodell, jedoch habe ich mit den Microsoft Application Blocks in der Vergangenheit keine all zu guten Erfahrungen gemacht, weshalb ich bei Unity sehr skeptisch bin.
  • Spring.NET ist als Framework empfehlenswert, wenn nicht nur ein Microkernel, sondern auch Logging, O/R-Mapping, aspektorientierte Funktionen und ähnliches gewünscht werden – für alles andere ist es jedoch zu umfangreich und komplex.

Diese Liste könnte ich noch problemlos fortsetzen und um einige weitere Microkernel ergänzen.

Mit LightCore hat Peter Bucher nun einen weiteren Microkernel entwickelt, der zudem als Dependency Injection-Container dient. LightCore ist vollständig in C# geschrieben, folgt dabei den Richtlinien der Clean Code Developer-Initiative und ist weitestgehend mit Unittests abgedeckt.

Für sich genommen wecken diese Aspekte durchaus Interesse an dem zu Grunde liegenden Code – doch wirklich interessant wird LightCore durch seine Eigenschaften beziehungsweise Fähigkeiten, die LightCore von anderen Microkerneln abheben:

  • LightCore ist leichtgewichtig und besteht im Wesentlichen aus einer 27 KByte großen Assembly. Je nach Anforderungen kommen noch einige Assemblies hinzu, doch über 50 KByte wächst der Platzbedarf in keinem Fall.
  • LightCore ist verdammt schnell: Im Vergleich zu nativem .NET-Code ist die Erzeugung von 100.000 Objektinstanzen in LightCore lediglich um 7% langsamer – autofac bedarf dafür hingegen ein Vielfaches der Zeit.
  • LightCore ist einfach und flexibel zu konfigurieren: Zum einen kann die Konfiguration vollständig im Code erfolgen, zum anderen wird XAML als Konfigurationssprache unterstützt, wobei nahezu beliebige Datenquellen genutzt werden können.
  • LightCore unterstützt die Instanziierung von Objekten nicht nur per Reflection, sondern auch per Lambdaausdruck, wodurch die Performance im Vergleich zu der Reflection-basierten Variante deutlich zunimmt.
  • LightCore kann mit verschiedenen Lebenszyklen von Objekten umgehen: Transiente Objekte können dadurch ebenso erzeugt werden die Singletons, threadaffine Singletons und HttpRequest-bezogene Objekte.
  • LightCore ermöglicht die Registrierung von Typen an Hand eines Kontrakts, eines Namens oder einer Klasse. Zusätzlich können Argumente spezifziert werden, die während der Instanziierung an den jeweiligen Konstruktor übergeben werden.
  • LightCore unterstützt die Gruppierung von Registrierungen, so dass auf einfache Art zwischen verschiedenen Konfigurationen von Registrierungen gewechselt werden kann.
  • LightCore integriert sich in klassisches ASP.NET und ASP.NET MVC, so dass Dependency Injection auch in diesen Technologien ohne zusätzlichen Aufwand genutzt werden kann.
  • LightCore unterstützt das CommonServiceLocator-Projekt, das seinerseits eine Abstraktion über verschiedene Microkernel ermöglicht.

Dieser umfangreichen und bemerkenswerten Featureliste zum Trotz verfügt LightCore über ein ausgesprochen schlichtes API, so dass zur tatsächlichen Verwendung nur einige wenige Zeilen Code erforderlich sind.

Alles in allem ist LightCore also eine kompakte, performante, flexible und ausgereifte Komponente, die für meine Projekte zukünftig die Antwort auf die Frage nach einem geeigneten Microkernel darstellt.

Für die Zukunft wünsche ich LightCore daher alles Gute.