Probleme beim Einloggen
Ralf Westphal Jenseits von OOP und FP
Robert C. Martin hat etwas zur Co-Existenz von OOP und FP geschrieben. Das fand ich gut - war aber am Ende doch enttäuscht. Es fehlte (wieder mal) das Wesentliche an der Objektorientierung.
Und am Ende blieb es natürlich bei den Etiketten OOP und FP, statt die Diskussion auf die prinzipielle Ebene zu heben. Auch wenn Aggregationen wie OOP und FP manchmal das Gespräch leichter machen, weil sie für Mengen an Werten und Prinzipien stehen, ist es für die Praxis untauglich, auf dieser abstrakten Ebene Lösungen zu suchen.
Mir war aber vor allem wichtig, das zentrale Problem zu benennen, das weder OOP noch FP angehen: funktionale Abhängigkeiten. Die machen Code schwer verständlich und schwer testbar. Da hilft auch SOLIDe Programmierung nur wenig.
Wer das ausführliche dargestellt sehen will, der lese hier:
Enjoy - and discuss! :-)
-Ralf
http://ralfw.de
http://ccd-school.de - Jetzt auch mit Personal Training
Denis Kuniss
+4 weitere Kommentare
Letzter Kommentar:
Ralf Westphal Abstraktion in der Softwareentwicklung - aber wie?
Über Abstraktionen wird in der Softwareentwicklung ja immer wieder geredet. Da soll von Details abstrahiert werden (Kapselung), es gibt abstrakte Klassen und man soll sich nicht von Konkretem, sondern von Abstraktem abhängig machen (DIP).
Klingt alles irgendwie sinnig - scheint mir jedoch am Ende doch nicht klar zu sein. Ich finde die Verwendung des Begriffs "Abstraktion" oft sehr pauschal und lückenhaft.
Mit zwei Artikeln versuche ich deshalb, das Dickicht zu lichten. Abstraktion ist nämlich nicht gleich Abstraktion.
* https://ralfw.de/2018/03/bequeme-abstraktion-ganz-konkret/ - eine Begriffsdifferenzierung
* https://ralfw.de/2018/04/all-together-now-schrittweise-abstrahieren/ - die schrittweise Nutzung von differenzierter Abstraktionen am Beispiel
Enjoy and discuss! :-)
-Ralf
http://ccd-school.de - Clean Code Development Training inhouse und online
Denis Kuniss Alexander Kriegisch Maximilian Raab
+27 weitere Kommentare
Letzter Kommentar:
Denis Kuniss

>Hier der komplette Text zur schrittweisen Verfeinerung: https://oberoncore.ru/_media/library/wirth_program_development_by_stepwise_refinement2.pdf
>Das ist eine Problemlösungsmethode - aber für mich ist es wichtig, dass das Ergebnis sich im Code widerspiegelt. Deshalb das IOSP.
Ich sehe Eurer IOSP Prinzip als als Essenz und als Weiterentwicklung dieser Methode. Mein Kommentar war auch eher als Hinweis gedacht, wie man konservative Kollegen für diesen neuen Ansatz interessieren kann. Manchmal ist es wichtig, eine solchen Anker zu bieten, um den Wiedererkennungseffekt auszunutzen und Unsicherheiten auszuräumen. Der kognitive Sprung von der wohl bekannten Wirth'schen Methode (und viele ältere Kollegen hatten Wirth und seine Methode im Studium, aber OOP haben sie sich im Selbststudium beigebracht) zum IOSP ist dann kürzer und einfacher, weil man sich auf etwas stützen kann, was man schon kennt. Das schafft Vertrauen. Das neue an IOSP zu entdecken und zu verstehen ist dann einfacher, denke ich.
Also eher ein didaktischer Hinweis, etwas, das ich in meine Artikeln dazu auch schon verwendet habe.
Danke für den Link.
Ralf Westphal Die Agilität eine Saunabank nach oben setzen
Die Agilität ist nun schon recht betagt und nicht alles ist rosig im agilen Land. Deshalb habe ich mir mal das Agile Manifest genauer angesehen. (Auch aus dem Impuls heraus, den mir XDSD gegeben hat (s. separater Thread hier).)
Die bottom line: Ich glaube, dass die Lunte des wahren Sprengstoffs, der in der Agilität steckt, noch nicht angezündet wurde. Das Agile Manifest ist durch alte Brillen interpretiert worden - was ja auch verständlich ist. Dadurch wurde jedoch noch nicht voll realisiert, was möglich und notwendig ist.
Bisher sitzen die Implementierer der Agilität also eher in der Sauna noch unten ;-) Damit es weiter vorangeht, steht nun an, mal eine höhere Bank in der Saune zu besetzen. Auch wenn das erstmal nicht so angenehm sein mag.
Eduard Ruffert Denis Kuniss Alexander Kriegisch
+5 weitere Kommentare
Letzter Kommentar:
Ralf Westphal
Ich unterscheide zwischen einer "Agilität, wie sie gemeint war" (oder gemeint gewesen sein könnte; ich war ja nicht bei der Unterzeichnung dabei) und einer "real existierenden Agilität".
Letztere verdient eine höhere Saunabank :-)
Im Agilen Manifest steckt viel mehr, als getan wird. Und - ja, dabei bleibe ich - das Agile Manifest ist eben auch nur ein Kind seiner Zeit. Auch darin ist nicht alles gesagt und gelöst.
Dass irgend "nix neu" in dem ist, was ich geschrieben habe... Nun, das mag sein. Ist ja aber eine Aussage über Texte jeder Art, die seit 1000 Jahren so gilt. Nicht immer geht es darum, etwas Neues zu sagen. Manchmal (oder meistens?) ist es schlicht hilfreich, Altes nochmal irgendwie anders zu sagen. Das ist dann ein Akt der Reflexion und macht das Alte (hoffentlich) einem noch weiteren Interessentenkreis zugänglich.
Anschlussfähigkeit ist nicht sofort gegeben, nur weil einer überhaupt etwas sagt. Sogar eher weniger, wenn jmd etwas Neues sagt. Insofern braucht es Übersetzungen und Anpassungen und Umformulierungen.
Ralf Westphal Results only software development?
Neulich bin ich über XDSD gestolpert: http://www.xdsd.org Das bedeutet: eXtremely Distributed Software Development.
Oder ich würde sagen, man kann es auch noch anders nennen: eXtremely Different Software Development :-) Weil es schon sehr anders als üblich abläuft. Da werden einige sehr liebgewonnene Muster auf den Kopf gestellt. I like :-) Schon wegen der Provokation des status quo.
Die grundsätzliche Verteilung der Entwickler ei XDSD finde ich allerdings gar nicht so entscheidend. Sie ergibt sich als Möglichkeit schlicht durch den ganz anderen Fokus. Deshalb würde ich die Bezeichnung anders wählen und sagen, es handelt sich um ROSD: Results Only Software Development. Es wird nämlich nur für Resultate bezahlt.
Ich versuche mal, den absoluten Kern des Ansatzes zu beschreiben. Dabei gehen natürlich Nuancen verloren, so dass bei euch mehr Stirnrunzeln als nötig entsteht. Aber es hilft nichts. Wer sich für die Nuancen interessiert, der kann von der Website ausgehend eine ganze Menge Lesestoff und Videos finden. Der Erfinder Yegor Bugayenko ist ein Enthusiast und hat viel veröffentlicht.
Also:
Bei XDSD geht es nur um den Code. Oder besser: um das Repository. Alles dreht sich um Veränderungen an Artefakten, die ein Projekt auf Kurs halten und dem Ziel näher bringen. Vorzugsweise geht es natürlich bei den Artefakten um Code-Dateien, aber Dokumentation in Form von Markdown-Files wird nicht ausgeschlossen.
Das Repo ist the single source of truth. Endlich ;-)
Da ist XDSD total rigoros. Denn es wird jede andere Kommunikation außerhalb des Repo untersagt. Klingt extrem, ist aber so. Also keine Meetings, kein Team-Chat, keine Hangouts, keine Skype, keine Email. Nichts außer hinterlassen von Spuren in Artefakten - und Kommunikation über Repo-Issues.
Aber das ist nicht das einzige Extrem. XDSD ist auch extrem beim Kleinschneiden von Anforderungen. Issues im Repo sind so konzipiert, dass sie immer [1] mit einem Aufwand von 30min zu erledigen sind.
Damit nicht genug. Wer ein Issue erledigt, wird bei XDSD nicht vom Entwickler bestimmt, sondern "vom System". Und zwar per Zufall. Niemand weiß also, welches Issue er/sie als nächstes zu bearbeiten hat.
Natürlich ist es unmöglich vorherzusehen, ob ein Issue wirklich in 30min komplett erledigt werden kann. Aber das ist auch nicht nötig. Denn wieder ist XDSD extrem. Es geht nämlich nicht um Erledigung aus Sicht des Kunden. Wenn ein Issue lautet "Schreibe eine Funktion, die die nicht-Kommentar-Zeilen in einer Code-Datei zählt.", dann glaubt XDSD nicht daran, dass das jmd wirklich funktional und auch noch sauber in 30min hinbekommt.
Ziel jedes Issue ist es vielmehr, 30min thematisch fokussiert auf die Herstellung eines Resultats zu verwenden. Die Entwicklerin, die das Issue zugewiesen bekommt, kann als Lösung also z.B. einen Funktionsrumpf plus einen grünen Test einreichen.
Einreichungen geschehen immer per Pull-Request. Der PR wird dann reviewt und wenn er formal passt und der Reviewer den Eindruck hat, dass der Inhalt nicht trivial ist, dann wird der PR akzeptiert und gemerget und das Issue geschlossen und die Entwicklerin für 30min bezahlt.
XDSD betont, dass jeder, der ein Issue bearbeitet, faul sein soll :-) So wenig Aufwand treiben wie möglich, um das Issue zu befriedigen, also etwas zu liefern, das akzeptiert wird.
Das bedeutet auch, dass man gar nicht erst anfängt mit dem Issue, solange noch etwas unklar ist. Erstes Mittel bei Unklarheit: eine Frage stellen an den Issue-Autor im Repo.
Zweites Mittel: selbst ein Issue aufmachen mit der Forderung nach mehr Information. Wenn man merkt, dass Grundlegendes fehlt, dann hilft nicht der Austausch mit dem Autor, sondern dann muss ein Artefakt ergänzt/erstellt werden. Vielleicht muss auch refaktorisiert werden. Aber das macht man eben nicht selbst, wenn man ein Issue an der Backe hat, sondern schreibt dafür eine Aufforderung "an das System" - und lehnt sich zurück, bis das erledigt ist.
Für solche Issues kann man sogar bezahlt werden. Man bekommt dafür durchaus Zeit gutgeschrieben. Dito für Bug Reports: 15min.
XDSD legt also viel wert auf innere Qualität, auf Sauberkeit!
Wenn man dann aber ein Issue wirklich erledigen will, dann bedeutet das nicht - wie gesagt -, dass man die Lösung komplett liefert. Stattdessen macht man einen Beitrag, der die Lösung näher rücken lässt - und schreibt weitere Issues zu dem, was man bewusst nicht getan hat.
In Bezug auf das Beispiel oben könnte das so aussehen:
* Die Entwicklerin reicht einen Test ein, der grün ist, weil der Funktionsrumpf hart verdrahtet das korrekte Resultat liefert.
* Außerdem schreibt die Entwicklerin 3 Issues (XDSD nennt das "puzzles", http://www.yegor256.com/2010/03/04/pdd.html):
1. Es ist ein weiterer Test für den Fall soundso nötig.
2. Es ist eine Funktion nötig, die Quelltext in Tokens der der Art A,B,C zerlegt.
3. Es ist eine Funktion nötig, die aus der Reihenfolge der Tokens erkennt, wann Zeilen ausschließlich in einem Kommentar liegen.
Diese "Rätsel" würde die Entwicklerin sogar im Code hinterlassen als Kommentare. Ein XDSD Tool sammelt sie und macht autom. daraus Issues.
Damit hat die Entwicklerin ihre Schuldigkeit getan und wird entlohnt. Vielleicht hat sie 25min dafür gebraucht, vielleicht 35min, Geld gibt es aber nur für die festgelegten 30min.
Wie viel ein Entwickler für die Behandlung eines Issue bekommt, ist also klar. Wie viel Zeit er hineinsteckt, ist ihm überlassen.
Wie viel die Entwicklung eines Feature kostet, das mit einem "root issue" beginnt, ist hingegen nicht klar. Aus dem einen Issue, das sich aus dem Gespräch mit dem Kunden ergeben hat, wächst unter Umständen ja ein Baum von Issues; es können Dutzende oder Hunderte entstehen.
XDSD gibt keine Schätzungen ab. Es wird höchstens aufgrund von historischen Daten vorhergesagt (vgl. https://ralfw.de/2018/02/featureforecast-sagst-du-schon-vorher-oder-schatzt-du-noch/).
Der Kunde bekommt also keinen Fixpreis. Der Kunde bezahlt aber auch nicht einfach Zeit. Er bezahlt - und das ist XDSD ganz wichtig - Resultate. Auf der Rechnung stehen all die vielen Issues, die im Verlauf einer Periode erledigt wurden (http://www.yegor256.com/2014/10/21/incremental-billing.html).
Jedes geschlossene Issue ist ein Resultat, ein Fortschritt. Eine kleine Verbesserung wurde eingebaut, ein Bug gefixt usw. usf. Das versteht der Kunde vllt nicht alles - aber jedenfalls sieht er ganz konkret, was alles getan wurde. Er bezahlt nicht irgendwie für Zeit, in der Entwickler etwas Unbestimmtes (womögl. in Meetings sitzen), sondern für Effekte auf der Codebasis.
Ich finde XDSD sehr spannend. Einerseits, weil es Entwickler befreit von der Co-Location. Das ist vorteilhaft für Entwickler, weil sie damit freier in Zeit und Raum sind. Das ist vorteilhaft für Unternehmen, weil die damit beim Recruiting mehr Wahl bekommen.
Andererseits und vor allem gefällt mir, dass hier jeder Silobildung entgegen gewirkt wird. Wissen in Köpfen ist verpönt. Darauf wird ganz bewusst nicht gesetzt. Deshalb werden Entwickler zufällig den Issues zugewiesen. Deshalb wird man belohnt, wenn man Issues eröffnet, die der Dokumentationsverbesserung oder Strukturverbesserung dienen, um schneller mehr Klarheit zu bekommen.
Ich sehe auch Lücken und offene Fragen bei XDSD; es ist nicht alles rosig. Doch das ist wirklich mal ein Ansatz, der über das Bisherige hinausgeht.
Agil ist "nur" waterfall on steroids ;-) Das grundsätzliche Paradigma des Vorgehens wird nicht wirklich hinterfragt, wenn man die Kommunikation aufdreht und inkrementell in 1-2 Wochen Iterationen arbeitet.
Bei XDSD hingegen wird der agile Grundgedanke negiert: dass es um Menschen geht bei der Softwareentwicklung. Dass es um spezielle Menschen geht.
Bisher kontrollieren Menschen Code, ob im Wasserfall oder agil, ob mehr oder weniger lean.
Bei XDSD gibt es diese Kontrolle nicht mehr. Das ist mein Verständnis, auch wenn Yegor das so nicht sagt. Bei XDSD ist der Gedanke, Überblick behalten zu wollen, nämlich illusorisch und überflüssig. Niemand muss oder soll wissen, was wo gerade getan wird. Der Fortschritt ist automatisch, denn Issues, die vom zugewiesenen Entwickler nicht erledigt werden, werden ihm nach einigen Tagen entzogen und jmd anderem zugewiesen. Dafür bekommt der ursprüngliche Entwickler eine Strafzeit. Das ist total unemotional. Schlicht eine Regel, die motivieren soll, vorwärts zu gehen. Irgendwie. Hauptsache PR einreichen und akzeptiert bekommen.
Bei XDSD gibt es keine Kontrolle mehr, sondern Evolution. Die Software (oder das Repo) evolviert aus sich heraus. Die Regeln sorgen dafür, dass das Ganze sich positiv entwickelt, auch wenn jeder nur lokal für sich optimiert handelt.
Von außen kommen immer wieder Anregungen/Impulse in Form von neuen root issues - und die führen dann zu Veränderungen in der Codebasis. Issue für Issue. Ohne, dass das vorhergesehen oder kontrolliert würde.
Das (!) ist für mich ein Paradigmenwechsel.
Soweit mal meine Vorstellung von XDSD. Würde mich freuen, wenn sie zu Diskussionen hier Anlass gäbe.
[1] Ok, nicht immer. Aber so oft, dass es nicht lohnt, hier zu nuancieren.
Philipp Stiefel Maximilian Raab
+19 weitere Kommentare
Letzter Kommentar:
Benjamin Wolf
Ich finde den Ansatz recht interessant. Bisher arbeitete ich immer in Teams, die zum Großteil im gleichen Büro arbeiteten. Das erleichtert einerseits ungemein, auf Grund der direkten Kommunikation. Andererseits geht doch einiges verloren, das nicht in Issues geschrieben wird. Ich hatte versucht, meine Kolleginnen und Kollegen mehr Richtung Issues zu schieben, jedoch erfordert das in dieser Konstellation sehr viel Selbstdisziplin der einzelnen Leute.
Aktuell arbeite ich in einem Projekt, wo wir größtenteils verteilt sitzen, so dass die Kommunikation für die Entwicklung dort zumeist über Issues läuft (>90%). Gerade für Architekturentscheidungen bzw. die vorhergehenden -Diskussionen finde ich persönlich jedoch die direkte Kommunikation wichtig, sei es vor Ort am Whiteboard oder über Telefonie (slack, Skype, etc.). Aber möglicherweise sind das die Punkte, die als „Fundament“ gesehen werden, das zuerst existieren muss, bevor man mit XDSD loslegt.
Ich werde aber einiges davon mal in den Alltag hineinwerfen und schauen, wie es funktioniert.
Noch kurz etwas zur Kritikphase der agilen Entwicklung, Ralf:
Aus eigener Erfahrung kann ich sagen, dass im Enterprise-Umfeld Agile erst so langsam als tatsächliche Möglichkeit der Entwicklung in Betracht gezogen wird. ;-)
Nur für XING Mitglieder sichtbar Law of Demeter + SLA
Dieser Inhalt ist nur für eingeloggte Mitglieder sichtbar.
Ralf Westphal
+2 weitere Kommentare
Letzter Kommentar:
Ralf Westphal
Ja, das kann gut sein, dass tieferliegende Ungereimtheiten aufgedeckt werden. Deshalb sollte auch die Richtung offen sein, in die die Konversation wandert. Denn sonst hängt man sich an lokale Lösungen, die nur kurzfristig helfen.
Was bedeutet "Datenstrukturen immer nur über Schnittstelle verfügbar"? Irgendwoher kommt eine Datenstruktur natürlich, irgendwer baut sie. Das könnte im Rahmen der Beschaffung aus einer Datenbank geschehen.
Die wesentliche Frage ist für mich aber nicht, woher sie kommen, sondern was ihr Zweck ist.
Das ist für mich ganz klar: der Zweck von Datenstrukturen ist, Datenstruktur sein. Sie bringen Daten in eine gewisse Form, z.B. fassen sie Rechnungspositionen in einer Rechnung zusammen und hängen an die Rechnung auch noch einen Summenblock inkl. MwSt-Beträgen dran.
Eine solche Objekthierarchie:
Rechnung
Position*
MwStPosition*
*ist* Daten. Die Tiefe der Schachtelung ist dabei völlig beliebig, zb:
Verzeichnis
Datei*
Verzeichnis*
Als rekursive Datenstruktur ist kein Ende abzusehen :-)
Und was will man dann machen, wenn man darauf zugreift? Man greift über einen Pfad auf Daten zu:
rechnung.Positionen[0].Menge
rechnung.MwStPositionen[0].Betrag
verzeichnis.Verzeichnisse[0].Verzeichnisse[1].Verzeichnisse[2].Dateien[3].Name
Das ist die natürliche Form von Daten. Es ist ihr Auftrag, diese Form zu haben und zu publizieren. Da gibt es nichts zu kapseln oder zu verbergen.
Aber was hängen an Datenstrukturen für Funktionen? Was ist "Datenstruktur-Logik" Da scheiden sich die Geister.
Meine Meinung: So wenig wie möglich. Und dann auch konzentriert auf den Zweck, d.h. auf "das Strukturige".
Wenn der Auftrag lautet "Struktur einer bestimmten Form sein", dann kann es nur zwei Arten von Methoden auf Datenstrukturobjekten geben:
1. Methoden, die die Struktur aufbauen und ihre Konsistenz sicherstellen.
2. Methoden, die es erlauben, die Struktur zu traversieren.
Bei einer Rechnung könnte zur Konsistenz gehören, dass sie mit Logik sicherstellt, dass alle minimal notwendigen Daten vorhanden sind. Das könnte bedeuten, dass MwSt-Positionen virtuell sind und von der Datenstruktur berechnet werden. Wenn das sehr, sehr einfach möglich ist, ok. Wenn das jedoch ausartet... dann gehört es nicht in die Datenstruktur, sondern in eine Factory oder dergleichen.
"Ausarten" ist für mich immer der Fall, wenn Datenstrukturen über sich hinaus greifen müssen auf andere Objekte oder Frameworks. Anders formuliert: Logik in Datenstrukturen soll nur mit Objekten innerhalb der Datenstruktur arbeiten.
Bei einem Verzeichnisbaum könnte zur Traversierung gehören, dass ein Iterator angeboten wird, bei dem man wählen kann, ob die Knoten im Baum depth-first oder breadth-first vorgelegt werden.
foreach(var v in verzeichnis.Verzeichnisse_in_der_Tiefe)
...
Bei einem Stack als Datenstruktur gehört zum Thema Konsistenz, dass Push/Pop angeboten werden. Ein abstract data type (ADT), der zur Abstraktion über das hinaus, was die darin gekapselte "rohe" Datenstruktur bietet (z.B. eine Liste).
Ob eine Datenstruktur mit Feldern oder Properties (Getter/Setter) ausgestattet ist, finde ich unerheblich. Sie muss halt ihren Auftrag innerhalb eines Vertrauensmilieus erfüllen. Wenn das Vertrauen gering ist, dann eher Daten hinter Properties verbergen, damit niemand die Datenstruktur kaputtmachen kann. In vielen Fällen ist das aber nicht nötig.

Moderatoren

Infos zu den Moderatoren

Über die Gruppe "Clean Code Developer"

  • Gegründet: 11.03.2009
  • Mitglieder: 4.958
  • Sichtbarkeit: offen
  • Beiträge: 477
  • Kommentare: 2.973