Tag Archives: Clean-Code

CC – Singleton korrekt implementieren


Flattr this

Motivation

Seit ich Clean Code [martin2009cleancode] lese, wollte ich das Gelesene auch gleich in meinem Blog posten um mir jenes erworbene Wissen für die Zukunft zu sichern. Leider geht das nicht so einfach, da diverse Punkte durchaus kontrovers diskutiert werden und sich stets auch Alternativen finden, welche nicht unbedingt schlechter sind. Zur Bewertung der Lösungen müssen erst eigene Erfahrungen gesammelt werden. Es genügt nicht zu sagen, es hies immer das wäre eine schlechte Lösung darum habe ich diese nie verwendet. Man muss auch verstehen warum die Lösung schlecht ist. Dazu muss man entweder ein paar Argumente kennen oder Erfahrungen mit der Lösung gesammelt haben oder aber vollständig die Vor- und Nachteile sowie die eigentlichen Ziele im konkreten Fall erfasst haben.

Es gibt Leute die lesen solche Bücher in ein paar Tagen und berufen dann Meetings ein um den Rest der Welt mit dem zu missionieren was sie selbst von dem Buch erfasst haben. In der Regel haben sie einige Dinge falsch verstanden und argumentieren dann vehement gegen die Anderen.

Diesen Fehler wollte ich nicht machen. Deshalb möchte ich auch ausdrücklich darauf hinweisen, dass die Artikel nur gesammeltes Wissen und Erfahrung sind. Keine Garantie, dass die Aussagen stimmen. Letztlich muss jeder selbst darüber nachdenken. In meinen Artikeln kann ich nur Hilfen und Argumente zur Verfügung stellen. Ich kann auch Empfehlungen aussprechen aber entscheiden muss letzlich jeder für sich allein.

Aus diesem Grund halte ich es für das Beste, einzelne Teilprobleme heraus zu greifen und diese von allen Seiten zu beleuchten. Vor- und Nachteile zu diskutieren und dem Leser damit eine Entscheidungshilfe an die Hand zu geben. Entscheiden muss er letztlich immer selbst am realen Kode.

Damit startet die Serie zur Clean Code Programmierung. Für den Leser stets erkennbar am dem CC – vor dem eigentlichen Titel.

Ziel des Singleton Pattern

Manchmal ist es wünschenswert, dass nur exakt eine Instanz von einer Klasse global existiert. Damit kann sich der Programmierer dann darauf verlassen, dass immer wenn Logik dieser Klasse ausgeführt wird, geschieht dies in dieser Einen Instanz. Soweit der Wunsch. In Wirklichkeit greifen im Java Umfeld noch einige Nebenbedingungen auf die wie nebenbei zu sprechen kommen. Diese Aufgabenstellung besitzt eine Lösung, das Singleton Pattern. Beschrieben ist dieses unter anderem in [Gam1994].

Wann ist das Pattern anzuwenden?

In [Gam1994] werden dazu 2 Gründe aufgeführt. Wende das Pattern an wenn:

  1. Du eine Klasse hast von der nur exakt eine Instanz existieren darf und diese soll von Clients zugreifbar sein über einen gut bekannten Zugriffspunkt.
  2. Wenn die Einzige Instanz durch Subklassen erweitert werden soll und ein Client soll in der Lage sein Instanzen von Subklassen zu nutzen ohne ihren Kode zu modifizieren.

Damit beginnt die erste Diskussion! In Java EE Umgebungen wird die Erzeugung von Objekten (Instanzen) dem Container übertragen. Er allein darf darüber entscheiden ob eine, zwei, oder mehr Instanzen einer Klasse zeitgleich existieren sollen. Die Verwendung von Singleton greift damit in die Freiheit des Containers ein. In konkreten Fällen kann damit eine Änderung der Implementierung der Containerlogik behindert werden. Der Architektur wird damit Flexibilität genommen. Der Architekt hatte möglicherweise bereits geplant zunächst einen Pico Container einzusetzen und in der zweiten Phase einen Spring Container. Er rechnet in der Regel nicht mit Entwicklern die ihm hier Steine in den Weg legen indem sie unkontrolliert in die Containerlogik eingreifen.

Sei es drum – wir haben mit unserem Architekten gesprochen und er sieht ein, dass es sein muss. Natürlich mit der Auflage das Pattern so wenig wie möglich zu nutzen. Wann nutzen wir es dann? Wenn die 1. Bedingung erfüllt ist? Wenn die 2. Bedingung erfüllt ist oder nur wenn beide Bedingungen erfüllt sind?

Aus meiner Sicht gibt es keinen Grund in einer Java EE Umgebungen ein Singleton zu verwenden, es sei denn man schreibt ein Framework und keine Anwendung. Aber diese Aussage möchte ich nicht als Lösung stehen lassen, da mir nicht klar ist ob meine Auffasung hier richtig ist. Letztlich läuft es wohl auf Einzelfallentscheidungen heraus.

Singleton – erster Versuch

package de.theserverside.designpatterns.singleton;

/**
* Klassische Implementierung des Singleton-Patterns
*/
public class ClassicSingleton {
private static ClassicSingleton instance = null;

/**
* Default-Konstruktor, der nicht außerhalb dieser Klasse
* aufgerufen werden kann
*/
private ClassicSingleton() {}

/**
* Statische Methode, liefert die einzige Instanz dieser
* Klasse zurück
*/
public static ClassicSingleton getInstance() {
if (instance == null) {
instance = new ClassicSingleton();
}
return instance;
}
}

Quelle: [Singleton]

Prinzipiell wird hier auf lange Sicht immer eine Instanz zurückgegben. Jedoch in der Anfangsphase kann es in Multithread Umgebungen zu Problemen kommen. Wenn der erste Thread in die getInstance() Methode eintritt und die if Anweisung mit dem Vergleich auf null noch passiert, dann jedoch vom System (Container, JVM, OS, …) schlafen gelegt wird. Während Thread 1 träumt, tritt ein zweiter Thread in die getInstance() Methode ein und passiert die if Abfrage welche immernoch true ergibt, erzeugt ein neues Objekt und bevor er dieses der Klassenvariablen zuweisen kann wird auch er ins Koma versetzt. Das Gleiche können jetzt noch hunderte von Threads genauso machen. Irgendwann wacht einer (evtl. der erste Thread) wieder auf und nimmt die Zuweisung auf die Klassenvariable vor. Ab da liefert die if Bedingung false. Jetzt wachen noch die anderen schlafenden Threads auf und nehmen ihrerseits die Zuweisung auf die Klassenvariablen vor. Je nachdem zu welchem Zeitpunkt dann die getInstance() Methode aufgerufen wird liefert sie ein anderes Objekt zurück. Erst ab dem Zeitpunkt ab dem sich kein Thread mehr innerhalb des Bodies der If Anweisung befindet, erst ab da wird stets die selbe Instanz zurückgegeben. Diese Implementierung führt also nicht zum Ziel.

 

Quellennachweis

[martin2009cleancode]
Martin, Robert C.: Clean code: a handbook of agile software craftsmanship. 1. Upper Saddle River, N.J. : Prentice Hall International, 2009. – ISBN 0-13-235088-2
[Gam1994]
Gamma, et al: Design Patterns: Elements of Reusable Object-Oriented Software : Addison Wesley Professional, 1994
[Singleton]
The Server Side Web Site Discussion
Advertisements

Entwickler sein, heißt besser werden!


Flattr this

Historie – was bleibt nennt sich Erfahrung

Wie am Blog vermutlich schon zu erkennen, bin ich Softwareentwickler 🙂 1999 schloss ich mein Studium in Richtung Informatik ab und stieg in die Entwicklung von Client-Server Anwendungen ein. Eingesetzte Technologien waren Oracle, Powerbuilder und Java. Der Softwareentwicklungsprozess in den Firmen orientierte stets am V-Modell. Dieses war in der Praxis deutlich umfangreicher als die wenigen Aspekte die wir im Studium betrachtet hatten.

In den Jahren nach 2000 waren dann Audits total angesagt. Jede Firma wollte ihre Zertifizierung nach ISO-9001. Die Firma brauchte plötzlich Geschäftsziele und jeder Mitarbeiter musste diese kennen. Hinzu kam eine nach bestimmten Kriterien angelegte Dokumentation und die Verwaltung von Quellkode in Versionskontrollsystemen. Letzteres war für mich nie ein Thema, da es im Open Source Bereich eine bewährte Praxis darstellt. Die normale Projektdokumentation die so anfiel empfand ich ebenfalls als sehr nützlich. Ich legte mir stets zu jedem Projekt eine Klemmmappe an. Da ich häufig auch zeitgleich an mehreren Projekten arbeitete, benötigte ich noch einen Plasteordner mit Register. Dieser enhielt stets die aktuellen Dokumente (in Arbeit befindlichen) je Projekt.

Gegen 2004 hatten es dann endlich die Beraterfirmen geschafft die kleinen und mittleren Unternehmen vollständig in Beschlag zu nehmen. Jede der mittelständischen Firmen die ich kannte, began damals mit Dingen wie den Folgenden.

Direktversicherungen – Die Firma schloss plötzlich Direktversicherungsverträge ab und machte diese Ihren Mitarbeitern schmackhaft. Die Nachteile waren klar: 5 Jahre Arbeitgeberbindung, da sonst die erworbenen Anrechte verloren gingen. Außerdem im Falle der Insolvenz gehört die Versicherung der Firma und geht in die Konkursmasse ein (jedenfalls im gesetzlichen Normalfall ohne abweichende Regelungen). Beim Arbeitgeberwechsel wird es schwierig, da der nächste Arbeitgeber vermutlich eine andere Direktversicherung besitzt und die des Arbeitnehmers nicht übernimmt. Ergo bis zur Rente zig verschiedene Versicherungen und in keiner lange genug eingezahlt um genügend heraus zu bekommen.

Risikomanagement – Als es in der Branche kränkelte und alle Firmen merkten, dass es kaum noch Geld für neue Projekte gab wurde Risikomanagement interessant. Wieder kamen Berater und wieder gab es Schulungen. In diesen wurden dann für teures Geld Binsenweisheiten vermittelt wie: „Der Vorstand darf nicht zusammen in den Urlaub fahren und wenn dann nicht mit dem gleichen Flug“, „Jedes Risiko ist auch immer eine Chance“, … Das ganze war gut ausgearbeitet, auf viele Module verteilt, ein schöne Geldmaschine für die Beraterfirmen. Welches Management achtet jetzt noch auf all diese dort gelernten Weisheiten?

Festpreisprojekte – Weil es kaum noch Geld gab aber die Unternehmen weiter Aufträge brauchten wurden nur noch Festpreisprojekte abgeschlossen. Gut für die Kunden – schlecht für die IT-Firmen? Nein, auch schlecht für den Kunden! Denn wie lief so ein Festpreisprojekt ab? Der Chef kam vom Kunden, im Gepäck viele lose Vorstellungen von dem was er dem Kunden demnächst gern anbieten möchte und mit einer Priorisierung wie es der Kunde gern hätte. Jetzt brauchte er noch ein bis zwei Tage um seine eigenen Prioritäten zu vergeben (Man hätte von einem priorisierten Backlog reden können – wenn das damals INN gewesen wäre). Im wöchentlichen Meeting wurde dann das Gesamtpaket den Entwicklern erklärt. Was will der Kunde haben, was braucht er dringend und wie können wir das leisten. In den Tagen danach wurden die einzelnen Projekte (aus dem Backlog) den jeweiligen Entwickler näher gebracht. Hierbei wurde der Leistungsumfang, die Zeitschiene und die grobe technologische Umsetzung besprochen. Kurz vor Beginn des Projektes vereinbarte der Entwickler einen Termin beim Kunden, sprach die Anforderungen durch, gab keine Zusicherung die der Chef nicht wollte und achtete auf die Umsetzbarkeit sowie auf den vom Chef abgesteckten Rahmen. Dann ging es zurück an den Schreibtisch und ans grobe Design. Wieviel Fenster werde ich brauchen? Wieviele DB Schemata sind betroffen? Arbeite ich auf Tabellen oder auf Views. Wie sollen die Masken im groben aussehen? Wie läuft das Deployment ab? Wo kann ich entwickeln – in der eigenen Firma oder beim Kunden? Wieviel Zeit werde ich brauchen? Wie stehen die anderen Projekte aktuell – gibt es Verzögerungen die ich noch ausgleichen muss? Das ganze dem Chef kurz vorgestellt, der Knackpunkt war immer der Zeitplan – hier war stets das Scotty-Prinzip gefragt. Chef ich kann das in 2 Monaten abliefern, vom Zeitplan her ist das für den Kunden auch ok. In den 2 Monaten kosten sie mir Gehaltsmäßig mehr als der Kunde für das Projekt ingesamt bezahlt. Ok, Chef ich versuch es in einem Monat zu schaffen.
Die Projekte wurden dann zum Termin (einen Monat) fertig oder umschreiben wir es lieber wie folgt. Es wurde so programmiert, dass man sich bei der Abnahme darauf zurückziehen konnte, dass alle geforderten Anforderungen soweit erfüllt sind. Hier und da sind halt noch ein paar Nacharbeiten zu tun. Diese Nacharbeiten und die unfertigen Teile welche erst bei tieferen Tests auffallen wurden dann noch in einem 2. Monat nachgearbeitet. Die Stimmung des Chefs war dann immer davon abhängig ob es bezahlte Nacharbeiten waren und falls nicht ob wenigstens ein Folgeprojekt dabei herausgesprungen ist. Die Krönung wäre ein echtes Projekt gewesen aber zu der Zeit gab es alles nur zum Festpreis 😉

Gegen 2006 war auch die Krise in der Branche langsam wieder überwunden und schon lag der Fokus auf ganz anderen Punkten. Viele Berater erkannten ihre Chance und gingen mal richtig ins Gericht mit den vergangenen Jahren. Was dabei herauskam nannte sich Kundenorientierung.

Kundenorientierung – Ja man redete uns ein, die Entwickler wären nicht Kundenorientiert genug und das müsse sich jetzt ändern. Dann kamen viele Schulungen mit vielen Powerpoints und schicken Bulletpoints. Bei den Entwicklern wurden zwar offene Türen eingerannt, denn sie wollten schon immer möglichst alles so umsetzen wie es der Kunde wollte. Leider gab es dabei einige Hemmnisse wie Zeit, Budget und Chefs die diese Spielereien jetzt gar nicht für sinnvoll hielten oder der Meinung waren, dass man dem Kunden nicht alles liefern darf sondern auch beratend/erzieherisch als Entwickler tätig sein muss. Letzterem stimme ich sogar zu, unter der Prämisse, dass die Benutzbarkeit der Anwendung nicht darunter leidet. Doch diese Hemmnisse erschienen nicht in den gelobten Powerpoints. Hier waren es immer die Entwickler die in an den Haaren herbeigezogenen Beispielen gegen die Kundenorientierung arbeiteten. Das ging eine Weile so – dann war wieder Ruhe. Kein Wort mehr von Kundenorientierung. Ja, genau! Es gab etwas Neues 🙂

Serviceorientierung – Jetzt war es endlich soweit. Das Management zog die Schlussfolgerung, dass die Bedürfnisse des Kunden wohl am besten durch einen besseren Service zu erfüllen seien. Nun wurde es unfreiwillig komisch. Offensichtlich war es das erste Mal passiert, dass die Beraterfirmen zugleich auf verschiedene Strategien gesetzt hatten (Sonst schienen sich die Berater weltweit immer einig gewesen zu sein :-). Serviceorientierung wurde einerseits hinsichtlich der Kundenorientierung gesehen und ging in Richtung Einführung von ITIL oder CMMI. Andererseits ging es um die Umgestaltung der Unternehmen hinsichtlich der angebotenen Services und deren Schnitt, also Richtung SOA. Das Thema war also kurze Zeit brandaktuell. Es gab richtig gute Schulungen dazu. Darin gab es richtig interessante Aussagen (aus dem Gedächnis rekonstruiert): „Ein ESB ist nebensächlich, Tools überhaupt sind nachrangig zu werten, SOA lässt sich auch ohne Tools durchführen“, „SOA ist nicht nur eine Technologie, SOA ist vielmehr eine Art und Weise ein Unternehmen zu organisieren“, „Wir wollen unsere Prozesse standardisieren um uns mit Konkurrenten vergleichen zu können“. Das Thema stand nur kurze Zeit im Fokus, verblieb aber im Hintergrund ehe es später als SOA wieder auftauchte.

Prozessorientierung – Endlich war dem Management klar, was diese Softwareentwicklung so teuer machte. Da war Kollege A mit seinem fachlichen und technischen Wissen sowie seiner spezifischen Erfahrung, welche er durch seinen spezifischen Lebensweg erworben hatte. Und da war Kollege B mit einem anderen fachlichen und technischen Wissen und einer anderen spezifischen Erfahrung. B war Vertretung von A und wenn A fehlte blieben dennoch Dinge unbearbeitet und wenn B fehlte war es genauso mit A. Woran lag das? Natürlich das Unternehmen brauchte Prozesse – Arbeitsprozesse! Was heisst die haben wir und die laufen auch, das kann ja gar nicht sein. Wo ist der Single Point of Service? Wo sind die allseits beliebten Workflow-Engines? Was heißt die gibt es nicht? Wieso haben wir eigentlich noch nicht auf ITIL oder CMMI umgestellt und unsere Prozesse standardisiert? Dann wären die Entwickler austauschbar und ein Kunde könnte von jedem zur vollsten Zufriedenheit bedient werden. Außerdem erfordern standardisierte Prozesse auch nicht den Einsatz hochqualifizierter Fachkräfte – zumindest nicht an jeder Stelle.
Das Ergebnis waren standardisierte Prozesse und die Aussage: „ITIL hat nicht versprochen die Prozesse zu beschleunigen sondern sie zu standardisieren. Das kann in speziellen Fällen auch bedeuten, dass es auch mal langsamer werden kann“. Nur gut, das dieses Vorgehen nicht mehr unter dem Begriff Kundenorientierung läuft. Aber gut, es waren ja ohnehin die Entwickler welche die Kundenorientierung nicht verstanden haben. Wenn ich als Entwickler früher einen Fehler gemeldet bekam, habe ich mich gleich daran gesetzt ihn zu analysieren um eine Aussage zu treffen woran es liegt, wie ein Workaround dazu aussieht und bis wann ich es beheben kann. Nach der ITIL Einführung schaue ich mir den Incident an, identifiziere die fehlenden Informationen, fordere diese durch Rückgabe des Tickets vom Ersteller ein und wende mich ohne schlechtes Gewissen der Bearbeitung des nächsten Tickets zu. Früher hätte sich mir dabei der Magen umgedreht. Doch wie heisst es so schön „Der Mensch ist ein Gewohnheitstier“ und „Der Mensch wird geprägt durch seine Umgebung“. Insofern ist ITIL schon etwas prägend. By the way – ITIL ist für den Betrieb erfunden wurden liebes Management – naja egal.

SOA – Endlich mal was für Entwickler. Die wollen doch ohnehin immer diese Spielereien, jetzt können sie mal Webservices bauen, das wird sie motivieren. Nachdem das Thema lange in den Hintergrund getreten war taucht es nun wieder auf. Jetzt werden die Services implementiert. Wie kam es dazu? Na zunächst sind offensichtlich umfangreiche Analysen gelaufen welchen ESB von welchem Anbieter man nehmen könne. Brauchen wir den? Wenn wir die Prozesse nach Belieben verschalten wollen ja. Wollen wir das? Nein! Achso.
Also SOA ist schon notwendig, auch aus meiner Sicht. Mit ihr bekommen wir die Chance festzulegen welche Kollegen/Abteilung/Projekte/Verfahren als Master für welche Daten fungieren. Dann ist endlich auch klar wer nur liest und wer nur schreibt genauso wie wer welche Daten zu halten hat und wer welche Daten weiter zu leiten hat. Doch die ersten Dinge haben wir uns schon verbaut. Wir haben uns auf den ESB Hersteller festgelegt und wir sprechen nur noch von Webservices obgleich eine SOA auch RMI als Service sieht. So gibt es bei den ersten Planungen Probleme mit der Performance (schon auf dem Papier). Um diese zu lösen schicken Imperator-Entscheidungen dann Workarounds ins Rennen auf die wir langfristig lieber verzichtet hätten.

Scrum – Dieser Punkt war die eigentliche Motivation für den vorliegenden Artikel und er wird jetzt nur noch kurz angerissen. Aber gut ich kann ja noch ein paar Artikel dazu schreiben 😉
Ja seit kurzem bin ich in einer Firma in der agile Arbeitsweisen vom Management eingeführt wurden. Die Entwickler sollen Spass bei der Arbeit haben, man wolle die Motivation steigern und man will effektiver und effizienter werden. In meinen Worten: Man möchte, dass sich die Entwickler mit den Arbeiten befassen die für die Erfüllung der Kundenwünsche notwendig sind und mit keinen anderen Dingen. Weiterhin will man, dass sie diese Arbeiten mit möglichst geringen Aufwänden und in hoher Qualität durchführen. Nachdem die agilen Arbeitsweisen bereits seit 10 Jahren ein Schattendasein fristeten und der Hype in Deutschland nun auch groß genug war, hat er also auch meinen Arbeitgeber erreicht. Nein ich stehe dem Ganzen nicht ablehnend gegenüber – im Gegenteil. Ich war und bin stets offen für neue Ideen. Allerdings übe ich mich anfangs immer in Zurückhaltung von Euphorie, da ich schon zu viele Allheilmittel nach einer Weile verpuffen sehen habe. Was für mich dabei besonders unbefriedigend ist, meist hinterlässt die Nachbetrachtung eines Beraters über ein am Boden liegendes Allheilmittel den Nachgeschmack – der Entwickler war Schuld, er hat’s versaut. Immer so auf der Art: „Das hätte super geklappt, wenn da nicht die Menschen wären …“. Zudem wie wir Scrum leben, welche Probleme und Nichtprobleme wir damit haben, will ich heute nichts sagen. In späteren Artikeln werde ich mich dazu gewiss äußern. Nur soviel: Ich bin dabei, ich bin am lernen und ja auch für mich gestaltet sich der Einstieg nicht einfach. Ähnliche Eindrücke scheinen andere Entwickler auch gemacht zu haben. Ich bin gespannt wohin mich die Reise führt.

 

Die Lehren, die ich zog

Nachdem ich nun im super Kurzdurchlauf meine berufliche Laufbahn auf die durchlebten Höhepunkte der Arbeitsmethoden oder Managementstrategien reduziert habe, möchte ich zusammenfassend sagen was ich daraus gelernt habe.

Persönliche Arbeitsweise – Diese vielen verschiedenen Kursänderungen im Management haben zu vielen Weiterbildungen teils in Form von Schulungen, teils in Form von Mitarbeitergesprächen geführt. Mit jedem Kurswechsel musste ich mich beschäftigen ob ich wollte oder nicht. Aus jeder gerade aktuellen Strategie habe ich versucht meine Vorteile zu ziehen. Meist gab es irgendwelche Arbeitsweisen die vorgestellt wurden oder Beispiele zu Arbeitsweisen aus denen man etwas für sich herausziehen konnte. Häufig wurden auch bekannte Arbeitsweisen zum x.ten Mal erläutert. Letzteres ist aber auch nicht schlecht. Schließlich dringt es so schneller ins Langzeitgedächtnis ein und außerdem sieht man, dass die Meinung immer noch aktuell ist – man ist also auf der sicheren Seite wenn man die Arbeitsweise beherzigt. So habe ich letztlich meine persönliche Arbeitsweise stets verbessern können. Zusätzlich zu den betrieblichen Denkansätzen kamen dann noch die Methoden „Simplify your life“ und „Getting things done“ aus denen ich viele Methoden in meine persönliche Arbeitsweise übernehmen konnte. Man muss aber auch sagen, dass erfahrungsgemäß keine Methode vollständig anwendbar ist. Meist mussten Teile weggelassen oder an das bestehende Umfeld angepasst werden. Auch für zukünftige Methoden wäre meine Erwartungshaltung nicht, dass ich diese ohne Tailoring übernehmen kann – das wäre Illusion. Gerade die agilen Methoden bringen eine große Menge an neuen Ansätzen mit. Hier kann ein großer Fundus für das private Leben abgeschöpft werden, egal ob die Projekte zum Schluß laufen oder nicht. Was allen Methoden bislang gemeinsam ist. Das Thema Ablage wird oft als Randthema gestriffen aber nicht wirklich herzhaft erfasst. Ablagesysteme spielen aber bei der Selbstorganisation aus meiner Sicht eine zentrale Rolle. Meist werden vorhandene Krücken aus dem Betrieb genutzt (in der Regel unlogisch gegliederte Dateisysteme mit magischer Berechtigungsverteilung). Das beste Ablagesystem welches ich bislang kennengelernt habe, ist dies aus „Simplify your life“ – eine Karteikartenablage im Rollcontainer. Bislang das praktischte System für mich. Leider ist meine Arbeitsumgebung inzwischen soweit standardisiert, dass auch die Rollcontainer standardisiert sind. Ein Fach mit Karteikarten gehört leider nicht zur Ausstattung und lässt sich auch nicht bestellen. Auch selber kaufen stellt keine Lösung dar, da es damit wieder andere Probleme gibt.

Die Kuh die durchs Dorf getrieben wird – Ja inzwischen bin ich der Meinung, dass Softwareentwicklung teilweise mit Mode vergleichbar ist. Manche Klamotte ist nach 10 Jahren durchaus wieder modern, obgleich dann natürlich unter einem anderen Namen. So ist es auch in der Softwareentwicklung, wobei hier die Periode von 10 auf etwa 1 Jahr zu reduzieren ist. Seit der Softwarekrise sind die grundlegenden Probleme der Softwareentwicklung bekannt (Beweisbarkeit der Terminiertheit und Korrektheit von Programmen sowie die Zusicherung von deterministischem Verhalten). Grundlegende Lösungsansätze sind auch klar. Beweisen lässt sich alles, es ist nur eine Frage des Aufwandes. Wenn ich also zu jeder Zeile Quellkode noch 3 Zeilen logischer Ausdrücke hinzupacke und bestimmte Rahmenbedingungen herstelle würde sich evtl. sogar die Terminiertheit beweisen lassen (Endlosschleife oder dauert es nur länger). Die Kunst besteht also darin bestimmte Effekte mit möglichst geringen Aufwand zu erzielen. Dazu gibt es klassische Methoden. Dann gibt es Varianten dieser klassischen Methoden. Dann gibt es Kombinationen der Vorgenannten. Zu guter Letzt entsteht jedes Jahr eine Neue, mit neuem Namen mit neuen Hoffnungen, mit neuen Versprechungen und am Ende meist mit der gleichen Enttäuschung wie bei der Letzten. Nein das ist keine pessimistische Einstellung sondern ein Naturgesetz. Entweder ich habe komplexe Programme oder ich habe komplexe Spezifikationen oder ich habe beides. Wenn ich die Korrektheit ein komplexes Programmes sicherstellen will, benötige ich komplexe Beschreibungen des Programmverhaltens. Wenn ich die Korrektheit beweisen will würde die Spezifikation der Neuprogrammierung einer Anwendung auf anderem abstrakten Niveau und mit anderen Mitteln gleichkommen. Der Aufwand muss aber der Gleiche sein, da es um das gleiche Verhalten geht. Von daher könnten diversifizierende Testverfahren tatsächlich eine preisgünstigste Methode in der Softwareentwicklung darstellen. Lass einfach 2 agile Teams unabhängig und räumlich getrennt von einander das gleiche Programm bauen und vergleiche die Ausgaben beider Programme. Unterschiedliche Ausgaben deuten auf unklare Anforderungen und fehlerhafte Umsetzung.
Was ich sagen will ist, ich habe mich daran gewöhnt das wir in unserer Branche den neuen Technologien, neuen Produktversionen und neuen Trends nur so nach hecheln. Ich kann damit leben und teilweise damit umgehen. Was ich daran nicht mag ist, dass die Evangelisten der neuen Technologie immer so tun als seien alle Anderen die ewig Gestrigen, die Dummen, die die keine Ahnung haben und sich sperren oder das ganze neue Projekt unterwandern und boykottieren wollen.

Die Erfahrung die ich hieraus gezogen habe ist ganz einfach: Spring auf jedes neue Thema auf wenn man es von Dir erwartet. Knie Dich rein, interessier Dich dafür. Eigne Dir an was sinnvoll ist und über nimm es in Deinen persönlichen Arbeitsstil. Überdenke Deine bisherige Arbeitsweisen kritisch, hinterfrage das Neue Thema kritisch aber stoppe keine Deiner langfristigen Aktivitäten um dem Neuen Thema Priorität einzuräumen.

Gute Arbeit leisten – Auf dem letzten Treffen der Nürnberger Agilisten hat es mich wirklich entsetzt wieviele Menschen der Meinung sind, dass viele Entwickler nur Ihren Job machen wollen, kein Interesse an einer persönlichen Weiterentwicklung haben und Änderungen in der Firma eher unflexibel gegenüber stehen. Vielleicht war das auch die unterbewusste Motivation den Artikel zu schreiben. Jedenfalls bin ich anderer Meinung. Ich glaube das alle Entwickler gute Arbeit leisten wollen. Ich glaube aber auch, dass jeder Mensch andere Fähigkeiten und Bedürfnisse hat und so auch jeder Entwickler. Diese müssen im Arbeitsumfeld Berücksichtigung finden, sonst ist die Zusammenarbeit nicht fruchtbar. Viele Menschen sind sich ihrer Fähigkeiten und Bedürfnisse auch gar nicht sicher. Diese müssen dann zunächst identifiziert werden. Auch die Vorstellungen und Ansichten über Gut und Schlecht sind stark unterschiedlich. Meist hängen sie von der persönlichen Entwicklung, den persönlichen Erfahrungen und dem Umfeld oder anderen Dingen ab.

Beispielsweise die Vorstellung über guten Kode. Was ist guter Kode? Wie sieht ein guter Kommentar aus? Da gibt es Entwickler die 10 Finger blind schreiben können und für die beliebig lange Bezeichner und Texte kein Problem darstellen. Auf der anderen Seite die – ich nenne sie gern C Programmierer – welche alles möglichst auf einen Buchstaben reduzieren. Dann gibt es die Verfechter des Fluent-Interface. Doch was ist nun wirklich guter Kode? Der mit einem super ausführlichen JavaDoc Kommentar, möglichst noch mit HTML Tags um dem Leser gleich die Möglichkeit des Verzweigens zu geben oder der ohne JavaDoc bei dem sich aus der Verkettung der Aufrufe das Verhalten erschließt? Sowie sie hierzu zwei Antworten erhalten sollten sie davon ausgehen, dass auch die Antwort die nicht Ihrer Ansicht entspricht wohl durchaus begründet ist. An dieser Stelle würde ich mir viel mehr Erfahrungsaustausch unter den Entwicklern wünschen. Doch diesem muss vom Arbeitgeber auch Zeitbudget eingeräumt werden. Stammtische oder OpenSpace Veranstaltungen empfinde ich hierbei als äußerst geeignet. Doch wie läuft es in der Praxis? Zur Community of Praxis sprechen vor dem Team immer nur diese selbst ernannten Gurus und stellen sich hin und sagen wie was gemacht werden soll. Die Anderen, denen das Präsentieren nicht so liegt, werden sich hüten hier aktiv zu werden. Warum nicht einfach mal ein Kodestück aus der Versionskontrolle festlegen (z.B. Person.java Zeile 130 – 140 aus r205) und beim nächsten Treffen durchsprechen. Bis dahin kann sich jeder mit dem Kode befassen und Argumente dafür und dagegen sammeln. Das bringt aus meiner Sicht viel mehr als die monotonen Wiederholungen von „Mache dies so und mach das so“. Auch Katas halte ich für einen guten Weg seine Fertigkeiten zu festigen. In der Arbeitswelt aber nicht im Team als Dojo. Da kommt zu viel Konkurrenz ins Spiel. Dojos per Internet sind kein Problem im Gegenteil, diese können auch sehr fruchtbar sein.

Ein ähnliches Thema habe ich bereits in meinem Artikel Industrielle Softwareproduktion behandelt, dieser könnte sie auch interessieren 🙂

 

 


 

Da es vermutlich nicht schwer fällt, meinen aktuellen Arbeitgeber zu ermitteln, möchte ich vorsichtshalber folgendes Statement anbringen:

Die hier im Blog und speziell in diesem Artikel vorgenommenen Behauptungen, Argumentationen, Meinungen und ähnliches sind rein meine persönlichen. Sie sind weder mit meinem Arbeitgeber abgesprochen, noch von ihm bewertet noch stellen sie dessen Meinung, Behauptungen, etc. dar.

Die Entwicklerfähigkeiten festigen


Flattr this

Motivation

Wenn sich Menschen in bestimmten Bereichen verbessern möchten, werden sie anfangen zu trainieren. Entwickler die sich verbessern möchten, trainieren mittels sogenannter Kata’s oder auch Code Kata’s. Hintergründe und wie alles begann lassen sich im Blog von Dave Thomas nachlesen ([DaveThomasBlog]). Ein paar einleitende Worte auf deutsch finden sich unter [CodeDojos].

Solche Übungen lassen sich allein durchführen. Allerdings so richtig Spaß macht die Sache erst wenn man die Lösungen mit anderen vergleichen kann. Eine schöne Art eines Vergleiches ist auch die Durchführung von Code Dojos. Eine Umgebung zur Aufzeichnung, Analyse und Kommentierung von Code Kata’s findet sich unter [CodersDojosBlog].

Eine generelle Anleitung zur Arbeit mit den Katas und dem Aufsetzen der Umgebung gibt folgender Screencast:
http://content.codersdojo.org/documentation/command-client-screencast/

Im vorliegenden Artikel werde ich kurz beschreiben wie das System unter Windows mit Eclipse zum Laufen gebracht wird.

Los geht’s

  1. Download des Ruby Installers in Version Ruby 1.9.3-p0 von http://rubyinstaller.org/downloads/ und Setup als Admin ausführen mit:
    • „Tcl/Tk support“ anwählen
    • „add to path“ anwählen
    • „check file assosiation“ anwählen
  2. Das Programm unter c:\Program Files\ruby193 installieren
  3. Consolen Fenster als Administrator öffnen (Admin Console) und in das Verzeichnis c:\Program Files\ruby193\bin wechseln
  4. Dort folgenden Befehl ausführen: gem install codersdojo
  5. Nun starten wir mit dem Befehl: codersdojo und prüfen ob der Hilfetext erscheint (das Programm sollte alleine ohne Fehler enden)
  6. Jetzt erstellen wir mit Eclipse ein Java Projekt, beispielsweise prime welches wir wie folgt konfigurieren:
    • SourceFolder: < Projektfolder>
    • OutputFolder: bin
  7. Nun wechseln wir in die Console (keine Admin Shell) und führen in unserem Projektverzeichnis folgenden Befehl aus:
    codersdojo setup java.junit Prime.java
  8. Ein Refresh in Eclipse zeigt uns welche Dateien alles hinzugekommen sind.
  9. In das lib Verzeichnis unseres Projektordners kopieren wur nun ein junit-4.x.x.jar (wichtig ist nur Version > 4 für Annotationen) und benennen es in junit.jar um!
  10. In Eclipse binden wir dieses junit.jar nun in den Projekt Classpath ein.
  11. In der Console können wir die Bearbeitung des Katas starten über Eingabe des Befehls: run-endless.cmd
  12. Wir bearbeiten nun das Kata solange in Eclipse bis es gelöst ist.
  13. Haben wir das Kata beendet und wollen die Aufzeichnung ebenfalls beenden, dann wechseln wir in die Console und geben Control-C ein.
  14. Anschließend bitte u eingeben um das Kata auf das Portal zu laden.
  15. Den auf der Console ausgegebenen URL bitte im Browser eingeben und die Meta Daten zum Kata ergänzen. Hierbei kann auch ausgewählt werden, ob das Kata öffentlich sichtbar ist oder nicht.

Das war schon alles. Jetzt noch ein paar nützliche Links.

Die Liste der öffentlich zugänglichen Katas auf CodersDojo:
http://codersdojo.org/katas/list

So lassen sich Katas auch alternativ aufzeichnen aber leider nicht kommentieren und vergleichen:
http://www.veengle.com/v/vGnl

Abschließend noch ein Katalog diverser Katas:
http://codingdojo.org/cgi-bin/wiki.pl?KataCatalogue

Leider kommen die Skripte von codersdojo nicht mit Unterverzeichnissen klar. Somit wird ein Maven typisches Layout nicht unterstützt. Wer das ändern will kann sich an den Sourcen probieren. Diese sind hier zu finden: http://t.co/xRL2tsY

Ansonsten viel Spass beim Üben 🙂

Quellennachweis

[DaveThomasBlog]
Hintergründe und Details vom Erfinder des Begriffes Code Kata (Autor des Pragmatic Programmer)
[CodeDojos ]
http://www.it-agile.de/code-kata-dojo.html
[DojosDEBlog]
http://codedojos.wordpress.com/
[CodersDojosBlog ]
http://codersdojo.org/