Christian Raschka - Meine Welt

Kombinat Programmproduktion West

2011-01-04T22:01:00.002+01:00

Seit Oktober blogge ich auch für das Kombinat Programmproduktion West (KPPW). Dort geht es um gesteigerte Produktivität und Qualität in der Softwareentwicklung. Mit dabei sind auch ein paar interessante Blogger und Software-Architekten. Also einfach mal vorbeischauen: http://kppw.wordpress.com

Sollte ein Thema besser in dieses Blog passen werde ich hier weiterhin über persönliche Dinge schreiben.

Wir werden Weltmeister - oder warum Verantwortlichkeiten nicht nur bei CCD wichtig sind

2010-06-15T11:43:00.009+02:00

Naja zugegeben, so weit sind wir bisher noch nicht. Aber das erste Spiel der deutschen Mannschaft war schon beeindruckend. Kein anderes Team hat so überzeugend gespielt, den Ball so schnell und flüssig laufen gelassen und dabei schöne Torchancen erarbeitet. Wie kam es dazu? Dazu kann ich zugegebenermaßen gar nicht viel sagen aber ein wichtiger Punkt hierbei ist sicher die Trennung von Zuständigkeiten. Jeder Spieler, jedes Mitglied im Trainerstab und alle anderen Beteiligten haben klare Aufgaben und keiner kümmert sich um die Angelegenheiten, die sie nichts angehen.

Single Responsibilty Principle

Genau dies ist ein Prinzip der Clean-Code-Developer. Aber was ist dies genau und wie führt dies angewendet zu besserem Code? Dazu kommen wir zurück zum Fussball:

Ich finde es gut, dass Jogi Löw sich vor Beginn der Weltmeisterschaft mit dem Verband um den Vertrag gestritten hat und es keine Lösung gibt. So muss er nicht die ganze Zeit darüber nachdenken, wie seine Entscheidungen Auswirkungen auf den Verband haben. Jetzt kann er einfach so handeln wie er möchte. Er kann jetzt einfach nur Trainer sein.

Genauso kommt er ja auch nicht auf den Gedanken, dass er besser sein könnte als Miroslav Klose und sich selbst in den Sturm stellt. Nein er trainiert und die Spieler spielen. Das können sie nämlich auch am Besten. Auch der Vorstand redet nicht mehr in die Angelegenheiten des Trainers rein. Und der Teammananger Oliver Bierhoff hat die wichtige Aufgabe die vielen Pressenanfragen von der Mannschaft und den Spielern fern zu halten, diese sollen sich ja auf ihre Sache konzentrieren.

Auswirkungen auf die Software

Stellen Sie sich folgendes vor:

Sie entwickeln ein Programm, welches unter anderem eine Berechnung durchführt und danach das Ergebnis in einem Diagramm anzeigt:

Was passiert, wenn Sie diese beiden Aspekte in einem gemeinsamen Programmteil zusammen entwickeln?

Wenn Sie die Diagrammdarstellung lesen, ändern oder erweitern möchten, so können sie die Berechnung nicht ausblenden. Sie müssen sie lesen und verstehen, weil Sie sonst bei jeder Änderung Angst haben müssen, etwas an der Berechnung kaputt zu machen. Sie können sich nicht auf ihre eigentliche Aufgabe konzentrieren und verlieren so den Fokus, verlieren an Produktionseffizienz und machen mehr Fehler, als Sie machen würden, wenn Sie sich nur auf die Diagrammdarstellung konzentrieren müssten.

Was passiert nun, wenn Sie die Diagrammdarstellung durch eine nette Animation austauschen möchten? Oder wenn Sie die Berechnung verändern müssen? Wenn Sie diese beiden Aspekte gemeinsam entwickeln, müssen Sie in beiden Fällen ihren bereits geschriebenen Code anfassen, es gibt also mehr als einen Grund diesen zu ändern. Und genau dies beschreibt Robert C. Martin in seinem Buch Agile Software Development, Principles, Patterns, and Practices als Single Responsibilty Principle: „There should never be more than one reason for a class to change.“

Dies kann aber meines Erachtens auf alle Abstraktionsebenen angewendet werden, nicht nur auf Klassen. So könnte Jogi Löw bei Unzufriedenheit mit der Leistung des Torhüters diesen auswechseln (wird bei Manuel Neuer sicher nicht passieren ;-)). Und wenn die Pressearbeit nicht so gut läuft evtl. Oli Bierhoff. Aber er muss nicht die ganze Mannschaft auswechseln, nur weil ein Teil ihm nicht gefällt. Er kann auch ganz gezielt mit den Stürmern Tore schießen üben und mit den Abwehrspielern Viererkette. Und so weiter ...

Also dann, auf dass wir Weltmeister werden oder zumindest heute drei Punkte gegen Serbien holen und ein schönes Spiel sehen werden.

Komponentenorientierung – CCD vs. UML

2010-06-10T21:24:00.002+02:00

Komponentenorientierte Architekturen sind ja nichts Neues. Die Ge-sellschaft für Informatik (GI e.V.) selbst schreibt in ihrem Informatik-lexikon über Software-Architektur:

Definition (Software-Architektur)

Die grundlegende Organisation eines Systems, dargestellt durch dessen Komponenten, deren Beziehungen zueinander und zur Umgebung sowie den Prinzipien, die den Entwurf und die Evolution des Systems bestimmen.

Komponenten gehören also in die Standardwerkzeugkiste eines guten Architekten und Designers. Wie aber diese Komponenten darstellen? Ich habe den recht pragmatischen An-satz von Ralf Westphal und Stefan Lieser aus dem Clean Code Developer Camp mit der UML 2 ver-glichen und an praktischen Beispielen ausprobiert.

EInfach vs. standardisiert

Eine Notation sollte vor allem klar verständlich und eindeutig sein. Und einfach zu zeichnen vor allem bei schnellen Architekturzeichnungen am Whiteboard oder auf dem Skizzenblatt. Und genau da liegt sicherlich der Vorteil eines einfachen Ansatzes. Hier kann man schnell grobe Designs entwerfen, weglöschen verschieben usw. Wichtig ist aber, dass die Strukturen klar definiert werden. Stefan und Ralf verwenden hierbei zum Beispiel Kreise für Funktionseinheiten und einfache Pfeile für Abhängigkeiten, sowie doppelte Pfeile für Datenflüsse. Wie aber würde dies in UML aussehen? Es gibt Komponentendiagramme. Diese sind aber sehr überfrachtet mit Informationen, die ich vor allem im ersten Ansatz nicht benötige. Der Überblick auf die wichtigen Dinge geht verloren. Was aber tun, wenn der Kunde nun mal UML versteht? Warum ihm dann eine neue Notation verkaufen?

Toolunterstützung

Bei dem einfachen Ansatz gibt es bisher keine oder nur rudimentäre Unterstützung beim Entwerfen. Hier muss man auf Werkzeuge wie zum Beispiel Visio oder das Online-Tool TODO verwenden. Diese Werkzeuge haben aber den Nachteil, dass man schlecht in die Designs “hineinzoomen” kann. Aber dies ist für den schnellen Ansatz auf dem Whiteboard ja auch gar nicht nötig. Es soll einfach, schnell und nicht überfrachtet sein. Für die späteren Architekturbilder kann man dann ja immer noch auf UML zurückgreifen und zum Beispiel mit dem Enterprise Architect die Designs entwerfen. Dann bekommt man alle Vorteile der Werkzeugunterstützung.

Fazit

Ich verwende bei meinen ersten Entwürfen auf dem Skizzenblock oder Whiteboard eine einfache aber klar definierte Notation und für weitergehende Architekturdokumentation, die auch für den Kunden gedacht ist die UML 2 und die passenden Werkzeuge. Was ist eure Meinung dazu? Wie findet Ihr eine einfache Notation im Vergleich zur UML oder anderen? Über Kommentare würde ich mich freuen.

How to use private svn repo with public (and actual git repository)

2009-12-03T14:54:00.003+01:00

If you want to use a svn repository for storing your changes, but the code base is on git this is my way of doing so:

1.: Get the git repo:

git clone git://path/to/git/repo.git/

2.: Add the svn remote information to git: (.git/config)

[svn-remote "repository"]
url = http://path/to/svn/repo/
fetch = :refs/remotes/repository

3.: Fetch the svn source:

git svn fetch repository

4.: Checkout that svn branch into a local branch:

git checkout -b local-svn repository

5.:

git-svn rebase

6.: Get merges from master branch:

git merge master

7.: Commit changes:

git-svn dcommit

Mein persönliches Resümee vom NET Open Space 2009 in Leipzig

2009-10-19T20:53:00.002+02:00

Der Net Open Space 2009 ist vorbei.

Leider. Denn es hat vor allem viel Spaß gemacht! Ein großes Dankeschön auch an die Organisatoren. Und danke an alle, die zu den vielen interessanten Disskusionen beigetragen haben. Auf ein paar der Themen möchte ich im Folgenden näher eingehen.

Alt.Net ist nicht tot!

Der Open Space hat gezeigt, dass es immer (noch) wichtige Themen zu besprechen gilt. Die Community bekommt meines Anscheins nach immer neue Mitglieder, die Fragen aber auch neue Anregungen mitbringen. Sehr erfrischend! Aber es zeigte sich auch, dass ein wichtiges Ziel der Community sein sollte, zu lehren, sich selbst und Andere(s) kritisch zu hinterfragen. Viel zu oft kommt es vor, dass vermeintliche Lösungen verwendet werden, die auf das eigene Problem gar nicht passen. Und das nur weil Person X dies als gute Lösung empfohlen hatte!

Verwende technologie-agnostische Architektur

Das Gleiche gilt auch für Technologien: Auch hier gilt es zu evaluieren, welches Paradigma tatsächlich auf meine Problemstellung passt! Nur weil eine Technologie X häufig verwendet wird, muss sie nicht automatisch verwendet werden! Stellt sich noch die Frage, wie das richtige Paradigma gefunden wird. Nehme die funktionalen Anforderungen und überlege dafür die beste Lösung und nehme in Kauf, das Menschen Fehler machen! Weitere Kriterien:
Wie weitreichend ist die Entscheidung für meine Anwendung. Muss ich beispielsweise Hibernate Sessions durch die gesamte Anwendung reichen, sollte ich mir genau überlegen dies zu verwenden! Kann ich dies aber in einer Schicht abstrahieren wäre es wohl besser. Natürlich spielt auch das vorhandene Wissen eine große Rolle. Hier reicht es nicht, so Ralf Westphal, nur spezielle Technologien zu schulen. Vielmehr sollten sich Entwickler "blind" weiterbilden. Also immer wieder über den Tellerrand hinausschauen - kritisch natürlich!

Buildmanagement steckt noch in den Kinderschuhen!

Bei der Sitzung über kontinuirliche Integration stellte sich heraus, dass viele zwar schon CI verwenden, aber meist noch in Verbindung mit Buildskripten. Auch hat es den Anschein, als hätten sich Prinzipien wie DRY (don't repeat yourself) nicht bis in diesen Bereich verirrt. Der gewohnte Komfort wie mit Maven im Javaumfeld ist auch gar nicht (groß) bekannt. Hier gilt es Werbung zu machen für die Maven Prinzipien wie Coding by Convention und deklarative Konfiguration um nur zwei zu nennen. NPanday, welches Plugins für .NET zur Verfügung stellt, ist auch nicht bekannt, vermutlich auch weil es noch sehr jung ist. Sollte hier Interesse bestehen, bin ich gern bereit, Maven und NPanday in Vorträgen oder Demonstrationen vorzustellen.

Soft Skills sind wichtig!

Das spiegelte sich vor allem in der Anzahl der Sitzungen zu diesem Thema wieder: Null. Also doch nicht so wichtig? Ich denke schon. Wahrscheinlich machen sich Entwickler nicht so viele Gedanken darum. Und trotzdem schwebte dieses Thema irgendwie immer im Raum! Schließlich ist ein Prinzip von CCD die tägliche Reflexion. Und auch zum Beispiel bei Scrum ist dies wichtiger Bestandteil. Leider sind noch zu viele zu unkritisch mit sich selbst. Für viele scheint es noch ein Problem, so die Meinung einiger Teilnehmer, wenn jemand den eigenen Code kritisiert oder gar verändert, an statt sich über die (hoffentlich) konstruktive Kritik zu freuen! Der hier gemachte Vorschlag klingt so einfach und lohnt trotzdem einer Evaluation: "nicht immer nur würgen, einfach mal umarmen!"

Danke Leipzig, danke an die Organisation und natürlich danke an all die interessanten Gespräche! Ich hoffe, wir sehen uns nicht erst in einem Jahr wieder!

Bildquellen:

http://www.flickr.com/photos/ajy/3889801150/

http://www.flickr.com/photos/orcmid/508703146/

http://www.flickr.com/photos/silipo/2944073307/

http://www.flickr.com/photos/17258892@N05/2588347668/

Das Problem der eigentumsorientierten Softwareentwicklung

2009-06-19T18:38:00.007+02:00

Sind Softwareentwickler abgesonderte Individualisten?

Viele würden jetzt wohl spontan ja sagen. Jedenfalls haben Informatiker gemeinhin den Ruf Individualisten zu sein. Zum Beispiel schreibt Klischeestudent in seinem Blog über Informatiker folgendes:

Ihn in der freien Natur anzutreffen ist weitaus schwieriger, als einen BWLer zu sichten. Informatiker halten sich lieber in geschlossenen Räumen auf. Bevorzugter Lebensraum ist der Keller mit der selbsterbauten und technisch hoch entwickelten Computerecke. Weibliche Vertreter dieser Gattung sind nur schwer zu finden, die Männchen bleiben lieber unter sich und reagieren daher auch meist schockiert, wenn sich weibliche Wesen in ihrer Umgebung befinden. Der Informatiker setzt auf vornehme Blässe und Karohemden, um möglichst unauffällig zu sein. Denn im Gegensatz zum BWLer ist der Informatiker eindeutig ein Einzelgänger! Lebensmittelpunkt: Technik!

Auch Gerald M. Weinberg schreibt in seinem Buch die Psychologie des Programmierers, dass er die meisten dieser Zunft in die Kategorie abgesonderte Individualisten einordnen würde. Ich denke, dass sich die Anforderungen an Softwareentwickler stark geändert haben. Dies hat zur Folge, dass auch die Entwickler andere sind und dieses Vorurteil nicht mehr zutrifft. Kommunikation ist für dieses Berufsbild von immenser Bedeutung.

Trotzdem identifizieren sich viele Softwareentwickler und Programmierer gern und oft mit ihrem Programm. Anders ist es nicht zu erklären, warum einige Programme nach ihren Entwicklern benannt sind.

Auch kenne ich ein Projekt, welches nicht nach Fachlichkeiten, sondern den Namen der Entwickler organisiert wurde. Darüber zu diskutieren ist wohl nicht notwendig.

Aber was ist daran überhaupt das Problem? Es gibt keines, wenn man ein Programm hauptsächlich lesen würde. Aber das geschieht viel zu wenig. Ein Programm muss in erster Linie funktionieren und seine Aufgabe erfüllen. Dies lässt sich leicht überprüfen. Aber was passiert mit einem Softwareentwickler, dessen Programm nicht läuft, wenn es Fehler gibt? Er wäre ja automatisch ein schlechter Programmier.

Dieses Urteil geben sich eigentumsorientierte Entwickler selten. Ist ja auch verständlich. Dies führt zu einer kognitiven Dissonanz. Wikipedia erklärt den Begriff so:

Als Kognitive Dissonanz versteht man in der Sozialpsychologie einen als negativ empfundenen Gefühlszustand, der durch nicht miteinander vereinbare Kognitionen – Wahrnehmungen, Gedanken, Meinungen, Einstellungen, Wünsche oder Absichten – entsteht.

Und dieses Gefühl muss aufgelöst werden oder sollte gar nicht erst entstehen. Der Mensch strebt nach Konsonanz. Deshalb werden viele Dissonanzen schon erahnt und dies führt zu einer selektiven Wahrnehmung. Zum Beispiel wird ein Käufer nach einem Kauf eines bestimmten Produktes selten in Prospekte eines anderen Produktes schauen. Er könnte dann feststellen, dass sein Produkt das schlechtere ist.

In der Softwareentwicklung führt dies zu einer selektiven Wahrnehmung bei der Fehlersuche. Der Programmierer wird in seinem eigenen Code weniger Fehler finden als in fremden Code.

Deshalb ist es wichtig, den Code nicht als “sein” Werk anzusehen. Vielmehr sollte man sich freuen, wenn andere Fehler finden und gemeinsam an dem Code arbeiten. Dies führt bei konsequenter Anwendung zu besserem Code. Pair-Programming zum Beispiel ist eine sehr gute Möglichkeit dies zu erreichen. Jeder ist für jeden Teil des Programms verantwortlich, niemandem gehört der Code! Dies sollte sich jeder Entwickler beherzigen.

Ach ja: könnte bitte jemand diesen Text nach Fehlern durchsuchen, ich finde gerade keine mehr. ;-)

Psychologie in der Informatik

2009-06-08T23:09:00.007+02:00

Auf dem 1. Architecture.NET Open Space in Düsseldorf gab mir ein Track besonders zu denken: Psychologie in der Softwareentwicklung.

Welche Auswirkungen hat die Psychologie für die Architektur? Welche Rolle spielen Hierarchie und Erfahrung? Wieviel Kreativität steckt in Softwareentwicklern oder wieviel sollte in Ihnen stecken? Ist der Beruf eines Softwareentwicklers eher ein praktischer oder eher ein kreativer?

All diese Fragen sind nicht einfach zu beantworten und waren Teil der Diskussion beim Open Space. Das wohl meistzitierte Buch in diesem Bereich ist sicher "Die Psychologie des Programmierers" von Gerald M. Weinberg welches ich gerade lese. Ich werde demnächst sicher dazu noch etwas bloggen.

Aber als erstes Thema möchte ich hier die Frage diskutieren, wieviel besteht der Beruf des Softwareentwicklers aus Handwerk und wieviel ist Kunst?

Dazu muss man zuerst erörtern, wieviel Handwerk man benötigt um künstlerisch tätig zu sein. Ich denke, dass man ziemlich viel erlernen kann und durch Übung festigen muss. Ich stelle mir gerade einen Maler vor. Sicher gibt es hier viele Genies. Aber auch die mussten die Grundlagen erst erlernen und immer wieder proben. Es gibt sehr viele verschiedene Pinseltechniken und die zu erlernen ist harte Arbeit. Ähnlich sehe ich es auch mit Informatikern.

Viel ist harte Arbeit. Es müssen ersteinmal die Grundlagen erlernt und immer wieder geübt werden. Aber an einem gewissen Punkt gehört auch in der Softwareentwicklung Kreativität zum täglichen Werkzeug. An vielen Stellen liest man immer wieder von weichen Faktoren, die sich nicht mit Metriken ausdrücken lassen. Zum Beispiel wenn Martin Fowler in seinem Buch
Improving the Design of Existing Code
von Smells redet. Einige von diesen Gerüchen sind sicher messbar, wie zum Beispiel wenn die Anzahl der Zeilen einer Methode eine bestimmte Anzahl überschreitet. Andere Smells lassen sich nur mittels Gefühl und/oder Erfahrung erkennen. Man hat das Gefühl, dass hier irgendetwas nicht so gut ist ... oder eben nicht. Hier kommt eben die Kreativität ins Spiel. Und die kann man nur bedingt erlernen.

Also liebe Softwareentwickler: Setzt euch hin und arbeitet. Arbeitet hart. Arbeitet an Euch und erlernt euer Handwerk und zwar gut. Dafür gibt es genügend Hinweise, wie dies zu erreichen ist. Zum Beispiel als Clean Code Developer. Aber unterdrückt niemals eure Kreativität. Sie wird gebraucht!

Neues Blog

2009-06-08T16:25:00.001+02:00

Auch ich habe mich nun entschlossen meine Gedanken über meine Welt in einem Blog festzuhalten. Anreiz hierzu war der Besuch des Architecture.NET Open Space in Düsseldorf. Hier kamen am 5. und 6. Juni sehr interessante Persönlichkeiten zusammen um über das Thema Architektur zu diskutieren.

Viele neue Ansätze und Denkweisen habe ich hier aufgegriffen und einige der dort besprochenen Themen werde ich hier in der nächsten Zeit auch diskutieren. Dies betrifft wahrscheinlich folgende Themen:

Architektur im Allgemeinen
Clean Code
Psychologie
Patterns
Persistenz
...