Interview mit Ralf Westphal und Stefan Lieser

Am 22.1. werde ich abends ein Online Interview mit den Clean Code Koryphäen Ralf Westphal und Stefan Lieser führen. Die Fragen werden thematisch weit gestreut sein. Ein kleiner Vorgeschmack gefällig?

Macht Clean Code Sinn, wenn die Kollegen nicht mitziehen?

oder

Community vs. Freizeit: Wie ist das vereinbar?

oder

Woher weiß ich, wann ich es mit Clean Code übertreibe?

Das Video veröffentliche ich dann auf meinem YouTube Channel. Ihr könnt die die Richtung des Gesprächs mitgestalten, indem ihr bis ca. 15 Uhr eure Fragen in die Kommentare postet.

Mit Tag(s) versehen: ,

9 thoughts on “Interview mit Ralf Westphal und Stefan Lieser

  1. Sebastian 21. Januar 2015 um 22:27 Reply

    Denk bitte daran: Ralph Westphal ist ein dominantes Alpha Tier. Lass dir dich nicht die Butter vom Brot nehmen und lass nicht zu das er das Thema bestimmt sondern du. (Seine Frau ist Psychologin, man also davon ausgehen das er jeden Trick kennt)

    Gefällt mir

  2. RalfW 22. Januar 2015 um 11:53 Reply

    Aha, Alpha Tier – Wow, ich muss an meinem Image arbeiten ;-) Meine Ex-Frau ist aber nicht Psychologin, sondern Bestatterin. Was bedeutet das für mein Kommunikationsverhalten? :-)

    Gefällt mir

  3. Thomas 22. Januar 2015 um 12:04 Reply

    Ich habe mich die letzten 5 Monate intensiv mit Flow Design beschäftigt und mich nach einem Q&A gestern mit Uncle Bob gefragt, ob FD nicht „einfach nur“ die konsequente Weiterführung von Clean Code ist.

    Gefällt mir

    • RalfW 22. Januar 2015 um 14:09 Reply

      Kurze Antwort hier: Ja. Flow Design könnte man auch als xSOLID=eXtreme SOLID bezeichnen. Ist ja auch aus der Beschäftigung mit dem ursprünglichen Clean Code entstanden.

      Gefällt mir

  4. leifbat 22. Januar 2015 um 13:38 Reply

    Flow Design funktioniert beeindruckend gut in kleinen Anwendungen und Katas. Laut Literatur (Bücher und Blog Artikel von R. Westphal und S. Lieser) skaliert Flow Design aber auch sehr gut.

    Wie sind da die praktischen Erfahrungen, bzw. wie groß war die größte Anwendung, die konsequent mit Flow Design umgesetzt wurde?

    Aus meiner Erfahrung kann das Boostrapping, also das Integrieren der Funktionseinheiten schnell unübersichtlich werden. Klar, es ist immer eine Sache der Gewöhnung, aber trotzdem könnte ich mir vorstellen, dass bei sehr großen Anwendungen die Wartbarkeit an dieser Stelle leidet. Das Argument, dass dies das kleiner Übel ist, sehe ich ein. Allerdings würden mich hier wieder praktische Erfahrungsberichte von großen Softwareprojekten mehr interessieren als theoretische Überlegungen.

    Bei Dependency Injection mit oder ohne DI Container ist es ja Bets Practice, die Komposition des Objekgraphen nahe das Einstiegpunkts zu erledigen. Warum ist das bei FD nicht so?

    Gefällt mir

    • RalfW 22. Januar 2015 um 14:13 Reply

      Kurze Antwort hier: Das größte Projekt mit Flow Design/Event-Based Components, von dem wir gehört haben, ist die SEPA Abrechnung einer großen Bank. Daran sind 12 Entwickler beteiligt.

      Wo Flow Design nicht zu skalieren scheint, ist oft eine unzureichende Modularisierung das Problem. Man muss schon das big picture im Blick behalten. Cargo Cult hilft weder bei Agilität noch bei Flow Design oder Clean Code.

      Flow Design hat nichts mit DI zu tun. DI ist eine Sache der technisch objektorientierten Praxis. Flow Design ist… Design. Wie man das umsetzt, kann jeder für sich überlegen.

      Aber: Wenn wir bei der Übersetzung eines Flow Design in Code einen DI Container benutzen, dann auch im Entry Point. Warum auch nicht?

      Gefällt 1 Person

      • leifbat 22. Januar 2015 um 17:12 Reply

        Bzgl. DI habe ich die Frage vielleicht nicht so optimal formuliert. Bei Flow Design kann ich natürlich DI verwenden, oder auch nicht, klar. Entscheidend ist doch aber das Bootstrapping der Anwendung. Dies ist bei OOP die Komposition des Objektgraphen und bei FD die Integration der Funktionseinheiten. Bei FD haben wir ja eher einen Graph von Operationen als einen Objektgraph. Integrationseinheiten müssen eben nicht unbedingt nahe dem Einstiegspunkt der Anwendung sein.

        In OOP ist die Composition Root natürlich nahe dem Einstiegspunkt, weil es hier keine Logik aber viele Abhängigkeiten gibt. Das ist an dieser Stelle vertretbar.

        Bei FD sind Integrationseinheiten ja auch nur da, wo in dem darüber liegenden Baum keine (bzw. wenig) Logik (also nur andere integrative Einheiten) enthalten ist. Insofern ist das schon konzeptionell integer. Allerdings gibt es ja noch einen anderen Vorteil. Das Bootstrapping also die Integration der Objekte ist bei OO Anwendungen an einem einzigen Punkt. Ist das nicht auch im Sinne des SRP? Bei FD ist die Integration über die Funktionseinheiten verteilt. Verstößt das nicht gegen das SRP?

        Gefällt mir

        • RalfW 22. Januar 2015 um 17:27 Reply

          Nun ist das Interview vorbei. Deshalb eine längere Antwort :-)

          Wir müssen unterscheiden zwischen Entwurf und Implementierung.

          Flow Design ist eine Entwurfsmethode. Insofern kennt sie keine Objektkonstruktion. Sie kennt nur Integration von Flow Funktionseinheiten. Die ist auf dem Papier trivial und immer gleich.

          Am Ende muss ein Entwurf nach Flow Design in eine Sprache übersetzt werden, z.B. C#. Das ist Implementation. Nun muss man sich Gedanken über Klassen machen; das war vorher nicht der Fall. Das wirft die Frage nach der Konstruktion auf. Das wirft auch die Frage nach der konkreten Weise der Integration auf.

          Wie und wo man Konstruktion betreibt, ist dem Implementierer überlassen. Ob der IoC anwendet oder nicht, das ist Flow Design als Entwurfsmethode egal. Wenn er IoC anwendet und Instanzen von Klassen, die Flow Funktionseinheiten als Funktionen implementieren, injizieren will, dann gern. Gern auch beim Start der Anwendung an einem Punkt.

          Wenn er sich gegen IoC entscheidet, auch ok. IoC ist keine Pflicht, kein Dogma, sondern ein Tool. Manchmal macht es Sinn, manchmal ist es überkandidelt.

          Die Integration im Code kann jedoch nicht vermieden werden. Hier gibt es zwei Orte, an denen sie stattfinden kann: im Konstruktor oder in einer Methode. Das hängt davon ab, wie man einen Flow Design Entwurf übersetzt.

          Findet sie im Ctor statt, dann wird die Integration zur Konstruktionszeit vorgenommen, z.B. bei Programmstart. Findet sie in einer Methode statt, dann eben „immer wieder“, wenn die durchlaufen wird.

          Bei Event-based Components gab es diesen Unterschied noch nicht. Aber beim heutigen Flow Design (also schon seit Jahren) ist er vorhanden. Man muss halt schauen, wie man jede einzelne Funktionseinheit eines Flows in Code übersetzt.

          Insofern: Konstruiere, wo du willst; integriere, wo es laut Übersetzung nötig ist.

          Gefällt mir

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: