Clean Code DeveloperClean Code Developer

5254 members | 562 posts | Public Group
Hosted by:Ralf Westphal

This post is only visible to logged-in members. Log in now
Hallo Sven, es gibt bspw. diese Aufzeichnung: https://refactoring-legacy-code.net/aufzeichnung-zum-webinar-softwareentwicklung-ohne-abhaengigkeiten-veroeffentlicht/ Viele Grüße Stefan
Ohje... wie alt sind denn die Kollegen? ;-) Leider ist mir derzeit kein IOSP Video bekannt. Das müsste ja für deine Kollegen auch sehr auf den Punkt sein, oder? Zum Beispiel "Das IOSP in 90 Sekunden", oder? :-D

Clean Code ist für mich nicht nur eine Sache des Codes. Wenn wir erst beim Codieren an Sauberkeit (Ordnung) denken, dann ist es eigentlich schon zu spät. Das, worauf Clean Code hinaus will, beginnt schon früher: beim Nachdenken über Code.

Nachdenken über Code ist Entwurf. Und beim Entwurf hin ich wiederum der Meinung, dass der mit Flow-Design besonders leicht gut gelingt. Flow-Design bietet eine leichtgewichtige visuelle Notation, die sich geradlinig in sauberen Code übersetzen lässt. Damit kann man schön am Whiteboard im Team entwerfen.

Immer mal wieder kommt in Trainings dazu die Frage auf, ob es dafür nicht auch ein Tool gäbe. Wäre es nicht schön, Datenflüsse zu entwerfen und dafür gleich Code generiert zu bekommen? Nach ein paar Anläufen vor vielen Jahren habe ich diese Frage für mich negativ beantwortet. Flow-Design am Whiteboard statt am Rechner hat seinen eigenen Wert - und einen Designer zu implementieren war mir immer zu aufwändig im Verhältnis zum Nutzen.

Doch nun hat mich Frank Rücker kontaktiert, um mir seinen Flow-Design Designer vorzustellen. Und der hat mich durchaus begeistert. Hier ist das Video, in dem er ihn ausführlich demonstriert: https://www.youtube.com/watch?v=3G1OBnH2jl4

Das Beispiel ist klein, doch es zeigt die wesentlichen Aspekte der Entwicklung mit dem Designer und anschließend in der IDE. Sehr spannend!

Mit dem Designer wird der Datenfluss definiert und anschließend der integrierende Code generiert. Bei der Codierung kann man sich ganz auf das "Ausfüllen" der Operationen konzentrieren. Das IOSP wird also automatisch eingehalten und Integration von Operation auch noch im Code deutlich getrennt.

Dass es sich hier um eine frühe bzw. spezielle Variante von Flow-Design handelt, die Event-Based Components (EBC), ist gar nicht so wichtig, finde ich. Eigentlich bin ich von denen schon lange abgekommen. Mit dem Designer ist mir aber nochmal klar geworden, dass sie ihren Platz im Entwurf haben.

Frank selbst hat mit dem Designer größere Projekte bei Boeing umgesetzt. Der Praxisnutzen ist also auch in dieser "DIY-Version" groß. Damit stellt sich die Frage, wie könnte der anderen interessierten Entwicklern zugänglich gemacht werden? Wer wäre interessiert? Wäre das ein lohnendes Open Source Projekt? Der Designer kann schon einiges - doch es gäbe auch noch eine Menge zu tun, damit er "aus der Box" breit einsetzbar ist, glaube ich.

In jedem Fall eine coole Initiative von Frank! Und ich freue mich natürlich, dass er solchen Nutzen aus Flow-Design gezogen hat.

Was meint ihr?

-Ralf

PS: Inzwischen habe ich es sogar geschafft, "das Buch zum Film" zu schreiben. Der aktuelle Stand meines Flow-Design Denkens findet sich hier: https://leanpub.com/softwareentwurf-mit-flow-design

Danke für den Hinweis auf das Video. Ich bin begeistert.
This post is only visible to logged-in members. Log in now

Warum eigentlich immer noch diese Fixierung auf das Tracking von Story Points und das Feiern von Velocity? Im agilen Manifest findet sich nichts davon - sondern dort wird von "wertvoller Software" gesprochen.

Wert jedoch spielt im agilen Vorgehen augenscheinlich nur eine geringe Rolle. Denn sonst würde zu allererst getrackt werden, wieviel Wert ein Team produziert. Ist das nicht merkwürdig?

Und ohne eine mit den Prinzipien der Agilität kongruente Metrik gibt es keinen Ansporn für Clean Code. Denn wo Komplexität belohnt wird durch ihre Messung, da besteht doch kein Anreiz, sie zu senken. Erst wenn man merkt, dass Komplexität der Wertentwicklung entgegensteht, investiert man verlässlich in ihre Reduktion.

Hier ein paar Gedanken dazu:

https://ralfw.de/wert-mehr-als-komplexitaet/

Hallo Ralph, in meiner Ausbildung zum Scrum Product Owner habe ich gelernt, dass die Velocity (Story Points pro Sprint) eine Konstante für ein Team darstellt und lediglich gemessen wird, um Unterforderung und Überlastung zu vermeiden (nach dem 'Mura' Prinzip (Unausgeglichenheit) aus der 'Lean Production'). Sie ist kein Indikator für einen Wert der Software. Welcher Wert produziert wird, hängt fast ausschließlich damit zusammen, welche Priorität die Aufgaben im Backlog bekommen (die wertvollsten zuerst).
Hallo, Stefan! Natürlich ist die Velocity (bzw SPs) kein Indikator für Wert. Das ist ja mein Punkt 😉 Dass Wert die Priorität beeinflusst, ist klar. Aber nicht nur. Das wäre ja auch zu schön 😁 Aber selbst wenn nur Wert die Priorität beeinflussen würde, dann wird Wert immer noch nicht getrackt. Warum nicht? Wo ist das Diagramm, auf dem gezeigt wird "So viel Wert wurde geschafft im Sprint!"? Man misst also keinen Wert, sondern etwas, das Last darstellt? Die Velocity zeigt an, ob ein Team sich überlastet hat oder nicht ausgelastet war? Last bezieht sich auf Kapazität, denke ich. Ich habe vllt die Kapazität, 60 Kartoffeln pro Stunde zu schälen. (Das hat natürlich Voraussetzungen, zb ein scharfes Messer oder Ungestörtheit oder unverletzte Hände.) Wenn ich 60 Kartoffeln schäle, bin ich ausgelastet. Schäle ich 80 Kartoffeln, bin ich überlastet. Bei nur 40 Kartoffeln nicht ausgelastet. Woher weiß ich, dass ich 60 Kartoffeln schälen kann, dass das meine Kapazität ist? Indem ich Erfahrung sammle. Ich schäle einfach mal einen Tag lang und zähle die Kartoffeln pro Stunde: [54,55,56,62,67,59,65,62] Der Durchschnitt ist 60. Warum variiert die Zahl der geschälten Kartoffeln? Weil ist am Anfang erstmal mit dem Setting vertraut werden musste und die Kartoffeln sowieso unterschiedlich groß sind. Es gibt nun zwar einen Trend, das ich scheinbar noch mehr Kapazität habe - aber darauf würde ich jetzt erstmal nicht wetten😉 Wer nun wissen möchte, wie lange ich brauche, um die Kartoffeln für eine Firmenfeier mit 250 Gästen zu schälen, der würde die Zahl der benötigten Kartoffeln nehmen (zb. 3 pro Gast im Schnitt, also 750 insgesamt) und durch meine Kapazität teilen. Dann kommen ca. 13 Stunden oder 1,5 Tage raus. Erstens gäbe es nun eine Prognose, wie lange vorher ich mit dem Schälen beginnen müsste. Das ist für die Organisation der Vorbereitung interessant. Zweitens wäre gewährleistet, dass ich mich nicht überlaste. Das ist für die dauerhafte Arbeitsfähigkeit wichtig. Aber warum das Streben nach "Ausgeglichenheit"? Warum "mura" vermeiden? Ich denke, aus demselben Grund, warum man die Geschwindigkeit der Autos auf der Autobahn in einem recht engen bereich haben will: um Staus zu vermeiden. Wenn mehrere (!) gekoppelte (!) Stationen etwas produzieren, dann ist große Variabilität im Output der Stationen keine gute Sache. Dadurch entsteht Verschwendung, wenn eine Station mehr produziert, als die nächste aufnehmen kann (das sieht man an Halden). Oder es entsteht Verschwendung, weil freie Kapazität nicht durch Output vorheriger Stationen genutzt wird (das sieht man an Stillstand). Wo ist das beim Kartoffelszenario aber ein Problem? Dazu müsste man ein bigger picture des Essenszubereitungsprozesses sehen, denke ich. Wo ist das bei der Softwareentwicklung ein Problem? Welcher nachgelagerte (!) Prozessschritt könnte überlastet werden mit viel Output, wenn die Velocity diesen Sprint mal doppelt so hoch ist wie beim vorherigen? Welcher nachgelagerte (!) Prozessschritt könnte unterfordert werden, wenn die Velocity in diesem Sprint nur halb so hoch wäre wie beim vorherigen? Wenn schon "mura" ein Gedanke ist, dann frage ich nach dem bigger picture, in dem der Produktionsschritt Softwareentwicklung ausgeglichen/rund laufen soll? Wo sind potenzielle Halden oder Leerläufe? Aber nicht nur das, die nächste Frage ist: Wen interessiert denn das, was die Software ausgeglichen produziert? Das ist "Komplexität"; die wird ja gemessen. Bei der Kartoffelanalogie wird die Kapazität in dem gemessen, was relevant ist für eine weitere Essenszubereitung. Story Points jedoch interessieren niemanden. Kein Kunde ist bereit, für Story Points Geld auszugeben. Komplexität von User Stories hat nur Relevanz für den PO; sie informiert seine Priorisierung, weil sie angenommenerweise mit Umsetzungsdauer positiv korreliert. Er setzt sie für die Priorisierung zum von ihm geschätzten Wert einer USer Story in Beziehung. Und dann? Dann ist Komplexität nicht mehr interessant. Dann dauert die Umsetzung einfach so lange, wie sie dauert. Nach einem 2 Wochen Sprint, hat man einfach 10 Tage gearbeitet. Keine Überraschung, würde ich sagen. Ob man dabei eine Komplexität von 46 oder 120 bewältigt hat... Was sagst das über die Kapazität aus? Ob man aber 10 User Stories oder nur 5 oder 13 geschafft hat... Das (!) könnte etwas aussagen für den Kunden. Aber auch User Stories werden nicht konsequent getrackt. Dabei wäre das doch das Allereinfachste. Man muss nur zählen. (Ich wäre da sogar noch genauer und würde auch angeben, an welchen Tagen welche Stories fertiggestellt wurden.) Wer mehr User Stories schaffen will - also die User Story Kapazität erhöhen will -, der kann sie ja kleiner schneiden. Warum nicht? Jede User Story stellt als Inkrement zumindest irgendeinen Wert dar. Das fände ich einen Schritt in Richtung Ehrlichkeit und Relevanz. Komplexität jedoch... die ist aus meiner Sicht kein Indikator für irgendetwas, allemal, da man sie sich jederzeit so hinschätzen kann, wie man mag. (Was natürlich niemand tut, wenn er an Velocity gemessen wird.)

Webinar am Donnerstag, 11. Februar, 18:00 - 19:00

In Softwareprojekten existieren Abhängigkeiten. Werden dabei Interfaces und Dependency Injection verwendet, kann das Konstrukt mithilfe von Attrappen (engl. Mocks) automatisiert getestet werden. Ferner können dann Dependency Injection Container zum Einsatz kommen, um die Abhängigkeiten zur Laufzeit aufzulösen.

In diesem Webinar geht es zunächst um die Frage, wie die Abhängigkeiten gestaltet sein müssen, um die Testbarkeit zu erreichen. Das Inversion of Control Prinzip (IOC) macht dazu einige Aussagen. Im Anschluss geht es um die Frage, mit welchen Teststrategien die Korrektheit solcher Konstrukte sichergestellt werden kann. An Beispielen wird der Einsatz von Mock Frameworks demonstriert. Zum Abschluss beantwortet Stefan Lieser in einer Q&A Runde die Fragen der Teilnehmer.

Link zur Anmeldung:

https://us02web.zoom.us/webinar/register/WN_xBv-P3eHRrmRpQZJ4QOb8A

Wenn Du zu dem Zeitpunkt keine Zeit hast, melde dich trotzdem an, Du erholst dann die Aufzeichnung.

Clean Code Development in der Diskussion

Die Gruppe lädt alle Softwareentwickler ein, darüber zu diskutieren, wie die Wandelbarkeit von Software und die Produktivität von Teams verbessert werden können. Sie schließt an das an, was die Initiative http://clean-code-developer.de an Bausteinen für sauberen Code zusammengetragen hat.

Aber natürlich soll die Diskussion dort nicht stehenbleiben. Wie kann die Softwareentwicklung über die bisherigen Ideen von Clean Code und Agilität hinausgehen? Lasst uns darüber nachdenken...

Wir sind gespannt auf eure Beiträge!

-Ralf Westphal & Stefan Lieser, Gruppenmoderatoren

PS: Laut Entscheidung der Gruppenmitglieder soll die Gruppe frei von Werbung sein. Offensichtlich kommerzielle & werbende Beiträge von Gruppenmitgliedern werden daher ohne Vorankündigung gelöscht und die, die sie einstellen blockiert. Dasselbe gilt für Stellenanzeigen.