Jeder, der sich mit der Konzeption und der Entwicklung von Software beschäftigt, kennt das Problem: Man ist so sehr in das Projekt oder den zu schreibenden Code vertieft, dass es nicht gelingt, die notwendige kritische Distanz zu bewahren, um Denkfehler frühzeitig aufdecken und Sackgassen vermeiden zu können.

Da Softwareentwicklung als Prozess selten nach außen kommuniziert wird, kommt Hilfe häufig spät oder gar zu spät – denn in der Regel wird erst dann um Hilfe gebeten, wenn das Kind schon in den Brunnen gefallen ist. Was fehlt, ist ein geeigneter, unabhängiger Sparringspartner, der eine zweite Sicht und einen anderen Standpunkt einbringen kann.

Deshalb biete ich am 25. Juni 2010 in München und am 28. Juni 2010 in Köln ebendies an: An beiden Tagen bin ich jeweils von 9 bis 17 Uhr in einem Café und setze mich mit Entwicklern, Architekten, Team- und Projektleitern zusammen, um deren Probleme zu besprechen und gemeinsam zu versuchen, nach bestem Wissen und Gewissen einen geeigneten Lösungsansatz zu finden – kostenlos, wobei ich gegen eine Einladung auf eine Cola nichts einzuwenden habe.

Thematisch wird es sich dabei um .NET, Codequalität und agile Methoden drehen: Ob es dabei um die Planung, die Architektur, die konkrete Entwicklung oder den Prozess geht, ob die Fragen eher genereller oder eher spezieller Natur sind, spielt keine Rolle – das entscheiden Sie, je nachdem, was Sie mitbringen!

Damit verschiedene Interessenten die Gelegenheit erhalten, sich mit mir zu besprechen, ist eine Sitzung auf 90 Minuten begrenzt – wobei sich in 90 Minuten häufig deutlich mehr besprechen lässt, als man zunächst vermuten würde: Wichtig ist nur, dass Sie das zu besprechende Thema in kompakter, aber vollständiger Form mitbringen, so dass mir genug Zeit bleibt, mich hineinzudenken.

Aus diesem Grund möchte ich auch darum bitten, dass sich Interessenten vorher bei mir per E-Mail anmelden – auch um auszuschließen, dass ich zu einem Thema nichts beitragen kann oder dass sich mehrere Interessenten zeitlich überschneiden, um die Diskretion zu wahren: Eine Sitzung ist also nicht öffentlich zugänglich für interessierte Zuhörer.

Wenn dieses Angebot Ihr Interesse geweckt hat, finden Sie abschließend noch die Termine und Lokationen im Überblick:

• München, 25. Juni 2010, 9 bis 17 Uhr, Forum Café
• Köln, 28. Juni 2010, 9 bis 17 Uhr, Café Feynsinn

Ich freue mich auf spannende Themen und interessante Diskussionen!

Foundations for Professionals – unter diesem Titel biete ich zukünftig Schulungen zu den Themen .NET, Codequalität und agile Methoden an. Das Konzept:

Fundiertes Wissen, akkurat und mit Liebe zum Detail aufbereitet, für alle Entwickler und Architekten, die Softwareentwicklung als ihre Berufung ansehen, der sie auf professionelle Art und mit Leidenschaft nachgehen.

Den Anfang macht vom 15. bis 17. September 2010 eine dreitägige Schulung zum Thema Extreme Programming (XP), in der so wohl theoretisch wie auch praktisch die Werte und Praktiken dieser agilen Methode vermittelt werden.

Veranstaltungsort ist das Vier-Sterne-Hotel Windenreuter Hof in Emmendingen, das in schönster Panoramalage mit Blick auf den Kaiserstuhl, den Breisgau und die Vogesen liegt und eine ruhige und konzentrierte Schulungsatmosphäre in modern ausgestatteten Tagungsräumen ermöglicht.

Die Agenda umfasst derzeit die folgenden Themen:

• Teambuilding und Setup
• XP aus 10.000 Meter Höhe
• Agile Anforderungen
• Planen, schätzen und messen
• Design und Code
• Entwickler vs Team
• Testen, testen, testen, …
• Review und Retrospektive
• XP im Rahmen von Scrum
• Die Scrum-Stunde
• … und wie weiter?

Die Schulung richtet sich an Entwickler, Architekten wie auch Team- und Projektleiter, unabhängig von der zur Entwicklung verwendeten technischen Plattform.

Um dem Ziel, fundiertes Wissen akkurat und mit Liebe zum Detail zu vermitteln, gerecht zu werden, bedarf es einer persönlichen Atmosphäre, in der jeder Teilnehmer intensiv und individuell geschult werden kann. Daher ist die Teilnehmerzahl auf 10 begrenzt.

Da die Schulung einschließlich Übernachtung und Verpflegung als all-inclusive angeboten wird, wird den einzelnen Teilnehmern die Gelegenheit geboten, auch abseits der Schulung ihre Gedanken auszutauschen und miteinander zu diskutieren – und sich bei Bedarf auch zurückziehen und entspannen zu können.

Für die ersten fünf angemeldeten Teilnehmer gilt der ermäßigte Early-Bird-Preis pro Person von 1.799 Euro zuzüglich Umsatzsteuer, für alle weiteren Teilnehmer gilt der reguläre Preis pro Person von 1.999 Euro zuzüglich Umsatzsteuer.

Bernd Marquardt ist selbstständiger Consultant und programmiert seit 1975 in den unterschiedlichsten Programmiersprachen so wohl auf Großrechnern wie auch auf PCs. Er schreibt Artikel für Fachzeitschriften, hat das Buch "WPF Crashkurs" geschrieben und hält Vorträge auf Konferenzen wie den DevDays oder der ADC. Er war für zehn Jahre Microsoft Regional Director und weitere fünf Jahre MVP für C++. Seine Schwerpunkte liegen in den Bereichen der Programmierung mathematischer und grafischer Algorithmen, Parallelprogrammierung, Windows NT-Architektur, Entwicklung mehrschichtiger Applikationen, MFC und natürlich .NET. Sie erreichen ihn über seineWebseite.

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

Bernd Marquardt: Oh je, das ist schon sehr, sehr lange her. Mein erster Kontakt mit einem Computer fand im Jahr 1975 oder 1976 statt - ich kann mich nicht mehr genau erinnern. Aber ich hatte an der Uni eine Vorlesung zum Thema Röntgenspektroskopie belegt, und da musste man bei den Übungen viel rechnen. Das durften die Kursteilnehmer dann mit dem Großrechner der Universität Köln durchführen.

Das war damals eine Control Data CDC Cyber 76. Die Maschine hatte eine Wortlänge von 60 Bit, 64 Kiloworte schnellen und 200 Kiloworte langsamen Arbeitsspeicher. Natürlich waren auch ein paar "Waschmaschinen" angeschlossen, also Festplattenlaufwerke. Die Programmiersprache war Assembler oder Fortran 66. Ein kleines Beispiel:

    PROGRAM TEST
    READ(1,100) N
100 FORMAT(I8)
    X=0.0D0
    DO 200 I=1,N
    X=X+DSQRT(DBLE(I))
200 CONTINUE
    WRITE(6,300) X
300 FORMAT(3X,9HRESULT = ,F15.5,/)
    STOP
    END

Schön, nicht wahr? Keine Strukturierung, keine Objektorientierung und natürlich keine mehrschichtige Architektur! Aber Spaß hat das Programmieren trotzdem gemacht. Aber es war auch noch alles sehr mühsam. Alles wurde auf Lochkarten gehackt und musste dann in die Maschine eingelesen werden. Danach konnte es längere Zeit - eventuell auch mehrere Tage - dauern, bis man ein Ergebnis in Form eines Listings erhielt. Und dann bekam man vielleicht nur eine lapidare Fehlermeldung des Compilers zurück.

Damals waren Computer noch richtig groß, machten viel Krach, brauchten tiefe Temperaturen und viel Strom. Aber man konnte damit Dinge ausrechnen, die man auf einem Taschenrechner - ja, die gab es schon! - nicht ausrechnen konnte. Mein erster eigener Mikrocomputer war übrigens ein TRS-80 Level II von Radio Shack, mit Microsoft Basic, 16 KByte RAM, einem 80 KByte-Diskettenlaufwerk und einer Taktfrequenz von satten 900 KHz. Die Grafikkarte in diesem Rechner konnte nur schwarz/weiß-Grafik und hatte eine Auflösung von 128 x 48 Klötzern. Aber die Faszination war in mir geweckt - und sie hat mich bis heute noch nicht losgelassen. Ja, es ist tatsächlich wahr und es gilt auch heute noch für mich: Wenn ich mir einen neuen Rechner bestellt habe, dann kann ich spätestens in der Nacht vor der Lieferung nicht mehr richtig schlafen!

Also am Anfang habe ich dann naturwissenschaftliche Software geschrieben, in erster Linie Programme, mit denen man die Eigenschaften von chemischen Molekülen berechnen konnte. Da braucht man so richtig viel Rechenzeit, manchmal sogar mehrere Tage!

Nach der Universität habe ich mich dann selbstständig gemacht und Anwendungen für andere Firmen entwickelt. Einer der interessantesten Aufträge in dieser Zeit war die Entwicklung eines Programms, welches Fässer, Kartons, Paletten und so weiter automatisch in einen beliebigen Container stauen konnte.

Später stellte sich dann heraus, dass es mir auch sehr viel Spaß macht, das Wissen an andere Softwareentwickler weiter zu geben. Seitdem bin ich sehr oft auf Konferenzen präsent und halte viele Schulungen zu den Themen der Softwareentwicklung.

Golo Roden: Wenn Du einen Schritt zurücktrittst, Dir die aktuellen Entwicklungen in der IT anschaust - wie beispielsweise Cloud Computing oder die Fokussierung auf RIA-Technologien - und diese mit dem Hintergrund Deiner langjährigen Erfahrung beurteilst: Wie stehst Du zu diesen Entwicklungen?

Bernd Marquardt: Ja, eines ist eigentlich klar: Wir lösen mit unseren Computern heute natürlich ganz andere Probleme als vor 30 Jahren. Das bedeutet auch, dass wir eine andere Hardware und andere Softwarekomponenten benötigen. Das fängt beim Betriebssystem an, hört bei den Anwendungsprogrammen auf und schließt natürlich auch die eingesetzte Hardware mit ein. Trotzdem sind alle neuen Strömungen in der IT-Branche für mich sehr interessant.

Nehmen wir zum Beispiel die Parallelprogrammierung. Bis vor Kurzem war dieses Thema einfach uninteressant, weil unsere Prozessoren einfach immer schneller geworden sind. Das ist nun vorbei. Wir haben Prozessoren mit mehreren Kernen, und wenn wir diese voll ausnutzen wollen, müssen wir unsere Software entsprechend entwickeln. Die Parallelität bekommen wir leider nicht umsonst - im Moment jedenfalls.

Aber genau vor diesem Hintergrund ist es höchst interessant, was sich nun auf dem Parallelmarkt tut, das heißt, welche neuen Lösungsansätze es gibt, welche Bibliotheken entwickelt und welche Technologien angewendet werden, um die Parallelprogrammierung so zu vereinfachen, dass sie leicht und fehlerfrei anzuwenden ist. Ganz ähnlich ist das mit dem Cloud Computing. Hier bekommt man beliebige Rechenleistungen, alles hochskalierbar und so wie man es gerade braucht. Ich will damit nicht sagen, dass Cloud Computing die einzig richtige und für alle Szenarien nutzbare Vorgehensweise ist, aber für viele Anwendungen stellt es doch ein gute Lösung dar.

Die IT-Umgebungen werden wohl auch in Zukunft sehr vielfältig bleiben, um eben alle möglichen Anwendungsszenarien abzudecken. Aber das macht es gerade so interessant.

Golo Roden: Inzwischen existieren zahlreiche Frameworks, die auf .NET basieren, und dieses um neue Fähigkeiten erweitern. Dennoch beschäftigst Du Dich auch sehr viel mit den Grundlagen - wie beispielsweise Parallelprogrammierung. Warum?

Bernd Marquardt: Mit der Parallelprogrammierung beschäftige ich mich eigentlich schon von Anfang an. Früher ging es in erster Linie aber darum, die zum Teil sehr langen Rechenzeiten zu verkürzen. Heute in modernen Business-Anwendungen möchte man die Rechenergebnisse natürlich auch möglichst schnell haben, aber es kommt noch ein anderer Aspekt hinzu: Die Benutzerschnittstelle soll möglichst nicht blockiert werden. Das heißt, der Anwender kann einfach immer weiter tippen und klicken. Und das ist schon eine Herausforderung ersten Ranges.

Eine wichtige Aufgabe in dieser Zeit ist es, Verfahren in der Parallelprogrammierung zu entwickeln, die so einfach anwendbar sind, dass wir sie sofort möglichst fehlerfrei für die zu lösenden Aufgabenstellungen nutzen können. Das ist nicht einfach. Und was so alles dabei herauskommt, ist in höchstem Maße spannend. In den letzten Jahren hat es viele neue Möglichkeiten in der Parallelprogrammierung gegeben: OpenMP, Unified Parallel C (UPC), Multithreading, Message Passing Interface (MPI). Und es kommen dauernd neue Ansätze hinzu: Cilk, Tasks Parallel Library (TPL), Parallel Pattern Library (PPL), AXUM, CUDA, OpenCL, ... Die Liste ist natürlich nicht vollständig, aber sie zeigt, welche Dynamik im Moment in diesem Bereich herrscht. Und das macht gerade diesen Bereich der Softwareentwicklung so interessant.

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?

Bernd Marquardt: Ich glaube, das habe ich im Blut! Wenn ich nicht ein Buch mit irgendwelchen neuen Themen neben mir liegen habe, dann werde ich unruhig. Das müssen nicht unbedingt Bücher aus der IT-Welt sein, das können auch Themen aus Physik, Chemie und Astronomie sein. Aber eins ist natürlich klar: Wenn man in der IT-Branche erfolgreich sein will, dann muss man gerne lernen und auch bereit sein, sich ständig mit neuen Themen zu beschäftigen. So ist das eben schon seit vielen Jahren: Man hat gerade C# 2.0 richtig gelernt und alles verstanden, dann kommt ganz schnell C# 3.0 auf einen zu und das Ganze geht wieder von vorne los! Ich habe mir vor kurzem ein Buch über Silverlight 3 gekauft - während ich das gelesen habe, kann mal eben Silverlight 4 raus. Ein langweiliges Leben hat man in der IT-Branche also auf keinen Fall. Und genau daher hole ich mir auch meine Motivation, denn Langeweile mag ich nun mal gar nicht!

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?

Bernd Marquardt: Also eins ist klar: Man muss sich unbedingt für neue Dinge interessieren. Jede neue Version einer Soft- oder Hardware muss eine spannende Angelegenheit sein. Das Ausprobieren eines neuen Verfahrens, einer neuen Technologie und einer neuen Bibliothek sollte auf jeden Fall Spaß machen und niemals als lästige Pflicht empfunden werden.

Außerdem sollte man unbedingt Freude am Tüfteln haben. Es ist nun mal so, dass eine Software nicht einfach eingetippt wird und dann funktioniert sie fehlerfrei, sondern es muss eine Menge Geduld aufgebracht werden, eine Software wirklich komplett zu entwanzen. So kommt es natürlich auch schon mal vor, dass man trotz Debugger und vieler anderer moderner Hilfsmittel längere Zeit nach einem Fehler suchen muss. Aufgeben ist hier nicht angesagt.

Als ein weiteres wichtiges Mitbringsel wurde ich sagen, dass ein Softwareentwickler Spaß an abstraktem Denken haben muss. Man muss sich in eine Maschine hineinversetzen und ein bestimmtes Problem durch Beschreibung mit einem Programmalgorithmus lösen. Ein bisschen Mathematik kann dabei übrigens oft helfen - auch wenn viele Programme heute vollständig ohne höhere Mathematik auskommen.

Na ja, die No-Gos sind dann eigentlich klar. Ich schreib es mal in C# hin:

if(!bNeueDingeInteressant || !bSpassAmTüfteln || (bAbstractDenken == false))
{
    goto exit;
}

Oh, oh, und dann noch mit einem goto-Befehl! Also ich mache aus den No-Gos einfach No-Gotos!

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

Bernd Marquardt: Die wichtigste Grundlage für einen Anfänger ist eigentlich eine gute Programmiersprache. Aber da geht der Streit dann auch schon los, denn was ist eigentlich eine gute Programmiersprache? Das kann ganz davon abhängen, in welchem Bereich man programmieren möchte. So können die Präferenzen im naturwissenschaftlichen Bereich durchaus andere sein, als die, die man in Business-orientierten Anwendungen vorfindet.

Ich bin aber der Meinung, dass die erste Programmiersprache, die man lernt - wenn man interessiert ist, dann werden im Laufe der IT-Karriere noch einige Sprachen mehr dazu kommen - einige wichtige Eigenschaften haben sollte. Zunächst einmal sollte die erste Sprache relativ einfach sein. Außerdem sollte sie die heutigen wichtigen Programmierparadigmen unterstützen. Dazu gehören die strukturierte Programmierung ebenso wie die Objektorientierung. Natürlich sollte für die Programmiersprache eine gute, also möglichst vollständige Bibliothek zur Verfügung stehen, die es letztendlich erlaubt, interessante Anwendungen zu entwickeln.

Und natürlich sollte einem die Programmiersprache gefallen, die man nun lernen möchte. Genauso, wie einem eine Sprech-Sprache gut gefallen kann und man diese dann lernen möchte, geht es mit der Programmiersprache.

Ich würde also empfehlen, eine Sprache zu lernen, die auf das .NET-Framework aufsetzt. Alle Punkte, die ich oben aufgezählt habe, treffen eigentlich auf die .NET-Sprachen zu. Sie sind objektorientiert und strukturiert, und es existiert ein nahezu komplettes Framework für die Windows-Programmierung. C++ ist ziemlich kompliziert und ist als Erstsprache nicht so gut geeignet. Andere .NET-Sprachen wie beispielsweise F# oder AXUM sind eher spezielle Sprachen oder Forschungsprojekte. Ich würde als Anfänger den Blick auf eine Standardsprache wenden: Also entweder C# oder Visual Basic. Hier kommt es dann darauf an, welche Sprache besser gefällt.

Und dann kann es auch schon losgehen. Übrigens ein kleiner Tipp: Für die Standard-Programmiersprachen gibt es häufig kostenlose Webcasts im Internet, mit denen man sehr schön in die Welt des Programmierens einsteigen kann. Diese Webcasts helfen auch, wenn man sich noch nicht so im Klaren ist, welche Sprache es denn nun sein soll.

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

Bernd Marquardt: Wenn es mal nicht so klappt mit dem Programmieren, dann sollte man nicht so schnell aufgeben. Denn dazu ist der Beruf des Softwareentwicklers viel zu interessant und spannend.

Eines der grundlegenden Prinzipien in der Softwareentwicklung ist das KISS-Prinzip: In der Formulierung Keep it simple, stupid ist im roten Grad von Clean Code Developer (CCD) enthalten, Extreme Programming propragiert Einfachheit als Regel und auch im Agilen Manifest ist Einfachheit als essenzielles Prinzip enthalten.

Softwareentwicklung soll sich also an Einfachheit orientieren – doch was bedeutet das? Was gilt als einfach und was nicht?

Eine eindeutige und allgemein akzeptierte Definition erscheint schwierig, entsprechend verschieden fallen die jeweiligen Erklärung auch aus. Während es auf der CCD-Webseite zunächst

Wer mehr tut als das Einfachste, lässt den Kunden warten und macht die Lösung unnötig kompliziert.

heißt, was sich mit dem im blauen Grad enthaltenen YAGNI-Prinzip überschneidet, wird dann im weiteren Text jedoch erläutert, es sei

für die Evolvierbarkeit des Codes zwingende Voraussetzung, dass der Code verständlich sei.

Zwar ist verständlich ein ebenso subjektiver Begriff wie einfach, deutet aber schon eher in die gewünschte Richtung. Verständlichkeit war auch das Ziel, das ich in meinem Blogeintrag Anmut und Eleganz verfolgt habe – insofern ziehen CCD und ich hier an einem Strang.

Schön ist, dass CCD dabei auch auf Code zu sprechen kommt:

Wenn ein IEnumerable reicht, sollte kein ICollection oder sogar IList verwendet werden.

Auch das entspricht meiner Vorstellung und deckt sich mit dem, was ich als eine gelungene innere Form von Code bezeichne.

XP nennt ebenfalls Verständlichkeit, allerdings nur als einen von vier Aspekten, die gemeinsam Einfachheit definieren. Nach XP zählen hierzu noch die drei Aspekte Testbarkeit, Navigierbarkeit und Erklärbarkeit:

• Testbarkeit: Nur Code, der sich auf das Notwendige beschränkt, ist zugleich auch einfach zu testen – ansonsten müssen nämlich Spezial- und Sonderfälle wie auch die Auswirkungen von Seiteneffekten im Test berücksichtigt werden. Auch wenn weder CCD noch ich in Anmut und Eleganz die Testbarkeit explizit im Zusammenhang mit Einfachheit ansprechen – auch hier sind wir letztlich einer Meinung.
• Navigierbarkeit: Zur Einfachheit von Code zählt neben einer guten Verständlichkeit und einer guten Testbarkeit auch eine gute Navigierbarkeit: Das heißt, in einfachem Code findet man sich zurecht, und es fällt leicht, zwischen den beteiligten Klassen und Komponenten hin und her zu navigieren.
• Erklärbarkeit: Während die Testbarkeit in gewissem Sinne messbar ist, sind Einfachheit und Navigierbarkeit in höchstem Maße subjektiv: Negativ fällt dies vor allem dann auf, wenn ein Team eingespielt ist und bereits lange Zeit an einer Software arbeitet – in diesem Fall wird sich jeder Entwickler des Teams im Code zurechtfinden und ihn verstehen. Aus diesem Grund muss Code für Einfachheit zusätzlich auch einem Uneingeweihten einfach zu erklären sein.

Das Agile Manifest schließlich definiert Einfachheit als

the art of maximizing the amount of work not done.

Hier wird also letztlich nur der Effekt der Reduktion, des minimalen Codes betont – was jedoch für mein Empfinden nicht genügt. Sicherlich kann man argumentieren, dass in dieser Aussage implizit auch die Arbeit angesprochen wird, die zum späteren Verstehen von Code investiert werden muss – viele Entwickler werden diese Interpretation jedoch zunächst überlesen.

All zu oft wird Einfachheit ansonsten nämlich mit dem YAGNI-Prinzip gleichgesetzt – dabei handelt es sich jedoch um zwei verschiedene Konzepte: Das YAGNI-Prinzip empfiehlt, keine Funktionalität im guten Glauben auf die zukünftige Erforderlichkeit umzusetzen, ohne eine konkrete Anforderung dafür zu haben. Das ist dann auch genau das, was im Rahmen von CCD kritisiert wird:

Wer mehr tut als das Einfachste, lässt den Kunden warten und macht die Lösung unnötig kompliziert.

Einfachheit im Sinne des KISS-Prinzips läuft jedoch Gefahr, dass während der Entwicklung lediglich simple und naheliegende Sprachkonstrukte verwendet werden – obwohl ein fortgeschritteneres Konstrukt eventuell deutlich besser geeignet wäre. Ein typisches Beispiel hierfür ist das Schlüsselwort yield, das viel zu selten Verwendung findet.

Außerdem wird dabei häufig auf Design für zukünftige Erweiterbarkeit verzichtet, obwohl dies mit nur unwesentlich mehr Aufwand möglich wäre – so wird beispielsweise eher auf verschachtelte und zahlreiche if-Anweisungen statt auf besserpassende objektorientierte Konstrukte gesetzt.

Kurzum: Einfachheit bedeutet nicht zwingend, das Naheliegendste und mit möglichst wenig Aufwand umsetzbare zu implementieren, sondern erstens, keine Funktionalität zu entwickeln, für die keine Anforderung besteht, zweitens, der Verständlichkeit des Codes höheren Stellenwert einzuräumen als der Entwicklung, und drittens, die zukünftige Erweiterbarkeit nicht außer Acht zu lassen.

Schlussendlich kann man daher festhalten, dass der Begriff einfach nicht besonders glücklich gewählt ist: Häufig wird darunter nämlich die minimalistische Reduktion auf einfache Sprachkonstrukte und wenige Codezeilen verstanden – die Verständlichkeit und zukünftige Erweiterbarkeit bleiben hierbei außen vor.

Daher wäre es meines Erachtens sinnvoll, an Stelle von Einfachheit – oder zumindest zusätzlich – einen anderen, treffenderen Begriff zu propagieren, der Verständlichkeit und zukünftige Erweiterbarkeit einschließt. Am ehesten treffen dies meiner Meinung nach die Begriffe Anmut und Eleganz.

Vor vier Jahren fand die erste prio.conference statt – als monothematische Konferenz, deren Schwerpunkt in den darauffolgenden Jahren jeweils explizit auf ein anderes Thema gelegt wurde: Softwarequalität, Softwarearchitektur und UI.

Dabei wurden im Rahmen der Konferenz nicht nur Technologie und die dazugehörigen Werkzeuge vorgestellt und diskutiert – statt dessen fanden auch Ideen, Konzepte und Anwendungsfälle den ihnen gebührenden Rahmen.

Am 19. und 20. Oktober dieses Jahres findet nun die fünfte prio.conference statt, als Thema wurde

Verteilte Architektur

ausgewählt. Dazu gehören Konzepte wie beispielsweise REST und ereignisgetriebene Architektur, Technologien wie NServiceBus und WCF, und bewährte Vorgehensweisen wie CQRS und Json.

Erstmals findet die prio.conference in diesem Jahr in der Meistersingerhalle in Nürnberg statt – eine sicherlich stilvolle und daher angemessene Umgebung für diese Konferenz.

Neben Ralf Westphal, der wie bereits in den vergangenen Jahren wieder als Content Manager verantwortlich ist, sind zahlreiche weitere qualitativ hochwertige Referenten vertreten – unter anderem Udi Dahan, Bernd Marquardt und Stefan Lieser.

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:

• 1. April 2010: Funktional oder objektorientiert?
• 1. März 2010: Abstraktion
• 1. Februar 2010: Felder vs Eigenschaften
• 1. Januar 2010: this oder kein this?
• 1. Dezember 2009: Reflection – Fluch oder Segen?
• 1. November 2009: Wie viel Sinn machen Unittests?
• 1. Oktober 2009: Vererben oder aggregieren?
• 1. September 2009: Alles var – oder nicht?
• 1. August 2009: C# oder VB: Welche Sprache soll ich lernen?
• 1. Juli 2009: Primärschlüssel: GUID vs Identity
• 1. Juni 2009: Heißt die Zukunft RIA?
• 1. Mai 2009: Woran erkennt man einen guten Entwickler?
• 1. April 2009: Interfaces vs abstrakte Basisklassen
• 1. März 2009: Sinn und Zweck von AOP
• 1. Februar 2009: Die Forderung nach Softwarequalität
• 1. Januar 2009: SOA vs WOA
• 1. Dezember 2008: Dynamic Language Runtime: .NET, quo vadis?

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

Anmut und Eleganz

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:

Anmut und Eleganz – zwei Begriffe der Ästhetik und der Schönheit. Laut Wikipedia wird Anmut als

Form des Schönen, […] der unwillkürliche Ausdruck einer Harmonie

definiert, wohingegen Eleganz als

Ausdruck von besonderem Stil und Geschmack in Design, Architektur, […]

gilt und nicht nur ein ästhetisches Konzept, sondern gar ein entsprechendes Ideal darstellt.

Intuitiv werden diese Begriffe nicht zwingend mit Code assoziiert, doch spielen sie auch in der Entwicklung eine entscheidende Rolle: Je eher Code eine gewisse Anmut und Eleganz ausstrahlt, desto eher folgt seine innere Form wohlüberlegten Gedanken.

In anderen Worten: Code, an dessen innerer Form gefeilt wurde, ist nicht nur wart- und evolvierbarer als über die Zeit emergierter Code – er folgt zudem einer eigenen Ästhetik: Der des im mathematischen Sinne Eleganten.

Jeder Entwickler, der in seiner Ausbildung mit Mathematik in Berührung gekommen ist, kennt den Term einer schönen Beweisführung. Der Term schön bedeutet in diesem Kontext, dass der Beweis elegant geführt und kompakt ist wie auch auf überflüssige Haken und Wendungen verzichtet wird.

Dies klingt zunächst nach dem Konzept der minimalistischen Architektur: Ein Entwurf ist dann gelungen, wenn kein weiterer Bestandteil aus dem Gesamtbild entfernt werden kann, ohne dass die Qualität oder die Funktionalität des Entwurfs darunter leidet.

Insofern liegt die Vermutung nahe, dass anmutiger und eleganter Code gleichzusetzen sei mit minimalistischem Code: Dass Code so lange reduziert, Ausdrücke vereinfacht und zusammengefasst, und aufwändige Konstrukte durch kompakte ersetzt werden sollten, bis eine minimalistische Form erreicht ist, die ohne Qualitäts- oder funktionale Einbußen nicht weiter reduziert werden kann.

Gilt also die Gleichung anmutiger und eleganter Code gleich minimaler, kompakter und reduzierter Code?

Während dieses Ziel in der Mathematik durchaus in dieser Form gelten könnte, lässt es einen wesentlichen Aspekt von Code aus: Im Gegensatz zu einem mathematischen Beweis, der – einmal erfolgt – nur noch zu Referenzzwecken nachvollzogen wird, wird Code immer und immer wieder gelesen.

Die gängige Wendung

It was hard to write, so it should be hard to read.

ironisiert diesen Aspekt. Fakt ist, dass Code im Idealfall nur ein Mal geschrieben, aber potenziell unzählige Male gelesen wird – nicht nur von anderen Entwicklern, auch vom ursprünglichen Autor: In der Regel gilt dies spätestens dann, wenn Code auf Grund neuer oder geänderter Anforderungen entweder erweitert oder zumindest angepasst werden muss.

Code sollte also für den Leser leicht verständlich sein. Hierzu trägt zunächst die äußere, optische Form von Code einen essenziellen Teil bei. Entsprechende Fragen lauten beispielsweise:

• Tragen Bezeichner verständliche und beschreibende Namen, die semantisch zum Inhalt passen?
• Erläutern Kommentare, aus welchen Gründen der kommentierte Code auf diese Art und nicht anders entwickelt wurde?
• Hielt der Entwickler formale Kriterien wie Verwendung von Elementen wie Einrückung und Leerzeilen ein?
• Folgen so wohl Code wie auch Kommentare und Dokumentation der gültigen Rechtschreibung und Grammatik?

Doch neben dieser äußeren Form spielt auch die innere Form für die Verständlichkeit eine bedeutende Rolle. Die entscheidende Frage hierzu lautet, ob dem jeweiligen Zweck angemessene Sprachkonstrukte angewandt wurden. Ausgewählte Beispiele dafür bieten folgende Aspekte:

• Werden LINQ-Abfragen an Stelle von aufwändigen Schleifen mit zahlreichen, unter Umständen verschachtelten if-Anweisungen genutzt?
• Wie werden Schnittstellen, abstrakte Basisklasse und konkrete Klassen miteinander kombiniert?
• Werden Konstrukte wie beispielsweise das yield-Schlüsselwort dort eingesetzt, wo sie sinnvoll sind und Arbeit ersparen können?

Um diese Sprachkonstrukte angemessen einsetzen zu können, ist es erforderlich, sein Werkzeug zu beherrschen – sprich, die dargebotenen Mittel der persönlich gewählten Programmiersprache nicht nur zu kennen, sondern sie zu beherrschen.

Zur Verbesserung der inneren Form gibt es zahlreiche Regeln – bereits Werkzeuge zur statischen Codeanalyse wie FxCop oder die in Visual Studio integrierte Codeanalyse können hierbei eine wesentliche Hilfestellung leisten.

Je länger man sich jedoch als Entwickler mit diesen Themen beschäftigt und versucht, während der Entwicklung bewusst so wohl auf die innere wie auch auf die äußere Form von Code zu achten, desto eher stellt sich – auf Basis der nach und nach verinnerlichten Regeln – ein Gespür für ebenjene Anmut und Eleganz ein, die wart- und evolvierbaren Code auszeichnet.

Da dieses Gespür für ästhetisch gelungenen Code von handfesten Regeln getragen wird, besteht keine Gefahr, Initiativen wie beispielsweise Clean Code Developer zuwider zu handeln: Im Gegenteil – da dem Gespür für Ästhetik und Eleganz die Internisierung der Regeln zu Grunde liegt, erleichtert es letztlich den Umgang mit ebendiesen.

Eine Anmerkung in eigener Sache: Dieser Beitrag ist der – inzwischen achtzehnte – Kommentar im Rahmen von Noch Fragen, Bucher? Ja, Roden!. Unsere Reihe geht nun vorerst in eine Kreativpause, in der wir am Konzept und neuen Themen feilen werden. Auf absehbare Zeit werden wir diese Reihe fortsetzen.