Posts tagged ‘Architecture’

Artikel zu flexiblen Architekturen online

Früher oder später werden Softwaresysteme unwartbar. Änderungen werden so teuer, dass sie faktisch unbezahlbar werden. Irgendwann werden die Schmerzen so groß, dass ein neues System entwickelt wird. Und das Spiel beginnt von vorne. Dabei handelt es sich aber nicht um ein Naturgesetz. Wir können Software entwickeln, die sich langfristig zu moderaten Kosten weiterentwickeln lässt – und das, obwohl wir auch bei der initialen Entwicklung nur moderate Kosten verursachen

Der vollständige Artikel findet sich hier.

August 9, 2012 at 7:40 am Leave a comment

S.O.L.I.D. for dynamic and functional languages at SoCraTes 2011

At the SoCraTes 2011 conference I facilitated a session about applying the S.O.L.I.D. design principles to dynamic OO languages and to functional languages.

I prepared some Flipcharts with the SOLID principles (Slideshare), code examples for Java, Ruby, Scala and Clojure (GitHub) and a paper with a description of the SOLID design principles and some thesis about their application to dynamic OO and functional languages (PDF).

I am not sure if the session can be counted as a success. We had three groups. One was working on the application of SOLID to dynamic OO languages with the Ruby code examples. The second group was working on the application of SOLID to statically typed functional languages with the Scala code examples. The third group worked on the application of the SOLID principles to dynamic functional languages with the Clojure examples.

The results were ambiguous and we didn’t find final answers. What became clear is that the SOLID design principles can be applied to all these types of languages. What stayed fuzzy was the question if that application would be useful for the everyday work with these languages. While I tend to think that in fact not every principle is useful in every languages there were others having the opposite opinion.

One of the problems within the workshop was that today OO thinking is baked into out heads. And so the Scala and the Clojure group created designs in OO style. And if you do that with a functional language of course SOLID is applicable and at least to a certain degree useful 🙂

In the end of the session we had a discussion in a smaller group of people if it may be to misleading to apply SOLID to functional programming. Perhaps it drives our thinking in the wrong direction. Perhaps it would be better to go back to the underlying principles of cohesion and coupling and creating new design principles for functional languages on top of these. And perhaps such design principles already exist and I am just to blind to see them.

So: There is still a lot to learn and a lot of experiments to do. If you like to contribute I would really much appreciate it.

 

 

September 9, 2011 at 3:12 pm 2 comments

Interview zur Architektur in Scrum

Ich habe Anfang des Jahres an der Scrum-Online-Konferenz teilgenommen. Dazu wurde ich interviewt zur Architektur in Scrum. Die Themen des Interviews umfassten:

  • Upfront Architekturvision vs. inkrementeller Entwurf während der Sprints
  • die Rolle des Architekten in Scrum
  • Einsatz von Tools zur Architekturüberwachung in Scrum

Das Interview gibt es in einer Kurzfassung (siehe http://vimeo.com/19394558, 42 Minuten) und vollständig (siehe http://vimeo.com/19389234, 53 Minuten).

March 20, 2011 at 9:28 am Leave a comment

Vortrag auf dem Objekt-Forum-Nord: “Auf der Suche nach dem Qualitäter”

Am 14.09.2010 haben Roman Pichler und ich auf dem Objekt-Forum Nord in Hamburg über Qualität vorgetragen. Roman hatte sich die Product-Owner-Sicher vorgenommen und ich die Entwicklersicht unter dem Titel: “Auf der Suche nach dem Qualitäter”.

Die PDFs der Folien finden sich hier zum Download.

Ich hatte meinem Vortrag begonnen mit einem Beispiel für wirklich schlecht strukturierten Code (siehe Folien) und habe ein paar Fragen ans Publikum gestellt. Die Antworten finde ich ganz interessant (die Zahlen stimmen im Detail wohl nicht, weil ich sie aus der Erinnerung rekonstruiert habe – die Größenordung passt aber).

  • Wer ist sich sicher, dass es so schlecht strukturierten Code bei ihm im Projekt/Unternehmen gibt? Meldungen: 40
  • Wer ist sich sicher, dass es solchen Code bei ihm nicht gibt? Meldungen: 1
  • Wer ist sich unsicher? Meldungen: 5
  • Wer kennt TDD? Meldungen: 30
  • Wer nutzt TDD? Meldungen: 20
  • Wer kennt SOLID? Meldungen: 20
  • Wer nutzt SOLID? Meldungen: 10

Das Ergebnis passte auf jeden Fall gut zur Argumentationslinie meines Vortrags. Obwohl zumindest ein Teil der Teilnehmer TDD und SOLID kennen und nutzen, scheint es nur geringe Auswirkungen auf die Code-Qualität zu haben. Nach meiner These nützt das beste Handwerkszeug nichts, wenn man es unter Druck nicht anwendet.

Daher mein Argument, wir müssten Berufsehre für unsere Branche etablieren: Wir sind stolz auf unseren Code und schreiben nichts, was unter diesem (subjektiven) Qualitätsstandard liegt. Nichts. Niemals. Und wenn wir dort angekommen sind, werden uns Vorgehensweisen wie TDD und Entwurfsprinzipien wie SOLID wirklich wichtige Dienste leisten.

Warum man das Manifesto for Software Craftsmanship unterzeichnen und sich ein Clean-Code-Armband besorgen sollte, steht in den Folien.

September 21, 2010 at 11:43 am 1 comment

Buchtipp “Clean Code”

Das Buch “Clean Code” von Robert Martin stand schon eine Weile in meinem Bücherregal. Ich habe es solange aufgeschobene, weil ich für mich wenig Neues erwartete. Jetzt bin ich dann endlich dazu gekommen, das Buch zu lesen. Ich hatte vor, es zu überfliegen, weil der Inhalt für mich mit 10 Jahren agiler Programmiererfahrung nicht wirklich neu sein kann.

Wirklich neu war der Inhalt auch nicht, aber aus dem Überfliegen ist auch nichts geworden. Zum einen ist das Buch so kurzweilig geschrieben, dass das Lesen Spaß macht. Zum anderen waren doch einige Abschnitte drin, die mich überrascht und zum Nachdenken angeregt haben.

Die grundsätzliche Argumentation des Buches ist, dass man sich auch um die Kleinigkeiten kümmern muss. Das ist erstmal konträr zu dem, was ich im Studium gelernt habe. Dort war eine Hauptmotivation für Module, dass man in denen das Chaos einsperren kann. Demnach müsste man die Makrostruktur sauber halten und muss sich um die Interna der Module nicht so sehr kümmern. Klang logisch. Aber sowas habe ich in 18 jahren kommerzieller Softwareentwicklung nicht erlebt. Entweder war das System auf jeder Ebene gut strukturiert oder auf jeder Ebene vergurkt. Ich denke, das hängt mit der Einstellung der Entwickler zusammen. Entweder sie interessieren sich für Qualität. Dann tun sie das auf jeder Ebene. Oder sie interessieren sich nicht für Qualität. Dann kümmern sie sich auch nicht um eine vernünftige Makro-Struktur. Robert Martin hat also Recht: Wir müssen uns um sauberen Code auch auf Mikro-Ebene kümmern.

Nur ein Beispiel für die Überraschungen, die das Buch für mich bereit hielt Robert Martin vertritt die Ansicht, dass eine Methode mit einem Parameter schon komplex ist und wenn möglich vermieden werden sollte. Mit 2 oder 3 Parametern wird es demnach noch viel schlimmer. Zuerst habe ich gedacht “naja…”. Aber seine Argumente sind gut und er hat Recht. Viele Parameter sind in sich komplex und deuten häufig darauf hin, dass wir zusätzliche Klassen benötigen oder Methoden in andere Klassen verschoben werden sollten.

Fazit: Aus meiner Sicht ist “Clean Code” ein Must-Have für jeden professionellen Softwareentwickler – egal ob agil oder nicht. Auch alte Hasen werden Nutzen daraus ziehen können.

January 26, 2010 at 8:43 am 2 comments

Vortrag zum inkrementellen Entwurf auf XP-Days und Scrum-Gathering

Die Präsentation zum inkrementellen Entwurf, die ich auf den XP-Days Germany in Karlsruhe gehalte habe, findet sich hier als Prezi-Flash-Präsentation.

Einen fast identischen Vortrag habe ich auch auf dem Scrum-Gathering in München gehalten. Hier ist die Prezi-Präsentation dazu.

Die Präsentationen habe ich mit Prezi erstellt. Die Vorteile von Prezi aus meiner Sicht, habe ich bereits in einem anderen Blogeintrag beschrieben.

December 2, 2009 at 11:54 am Leave a comment

Buchtipp: “SOA in der Praxis” von Nicolai Josuttis

Ich weiß, dass ich etwas spät dran bin, wenn ich jetzt noch SOA-Bücher lese. Das dpunkt-Buch “SOA in der Praxis” von Nicolai Josuttis aus dem Jahr 2008 hatte ich bereits kurz nach dem Erscheinen in meinem Bücherregal. Aber ich bin jetzt erst zum Lesen gekommen – wer bösartig ist, könnte das Buch heute auch als eine Art Nachruf auf SOA verstehen. Der SOA-Hype ist sicher inzwischen vorbei. Jetzt kann man sich trefflich darüber streiten, ob jetzt einfach der unspektakuläre SOA-Einsatz stattfindet oder ob schon Verwesungsgeruch in der Luft liegt.

Aber zum Inhalt: Der Autor beschreibt SOA vor dem Hintergrund seiner umfangreichen Praxiserfahrungen. (Für alle, die noch lahmer sind als ich: SOA steht für “Service Oriented Architecture”.) Und gerade diese Praxiserfahrungen mach einen erheblichen Unterschied zu vielen anderen SOA-Veröffentlichungen. Bei Josutti werden die ganzen unangenehmen Probleme beschrieben, die beim Einsatz von SOA zwangsläufig auftreten: Transaktionen, Versionierung, Migration, Verfügbarkeit etc. Diese und andere Probleme treten beim SOA-Einsatz auf. Sie können gelöst werden, aber nicht einfach. Josuttis schließt mit:

“Aus diesem Grund sollte SOA nie ein Selbstzweck sein. Wenn man Verteilung vermeiden kann, sollte man das tun.”

Ich empfehle das Buch jedem, der SOA einführen muss oder will. Diejenigen, die SOA einführen müssen, finden hier die zu erwartenden Probleme inkl. möglicher Lösungsstrategien. Diejenigen, die SOA einführen wollen, bekommen vor Augen geführt, wie komplex die ganze Angelegenheit ist und können sich dann nochmal ernsthaft überlegen, ob sie SOA wirklich wollen.

Ich bin nach dem Lesen des Buches jedenfalls froh, dass ich bisher nichts mit SOA zu tun hatte und hoffe, dass das auch so bleibt.

Trotzdem war die Lektüre keine Zeitverschwendung. Viele der Konzepte lassen sich in großen Systemen auch dann anwenden, wenn es nicht um SOA im eigentlichen Sinne geht. So ist das Thema Idempotenz beispielsweise relevant, wenn man seine Internetanwendung mit einer REST-Schnittstelle versieht. Die Diskussionen zu Entkopplung sind ebenfalls auch ohne SOA relevant. Etc.

October 14, 2009 at 5:10 pm Leave a comment

Older Posts