Probleme beim Einloggen
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.
Samuel Nitsche Practical Advice for Taking Your PL/SQL Testing to the Next Level - Dienstag 24.4. 18 Uhr
Automatisiertes Testing ist eine Grundvoraussetzung für sinnvolles Refactoring und praktische Umsetzung von CleanCode. Insbesondere in Bezug auf Datenbank-Entwicklung gibt es hier nach wie vor sehr viel Luft nach oben.
Mitglieder der utPLSQL Community geben nächsten Dienstag in diesem kostenlosen Online-Webinar praktische Einblicke und Tipps zur Einführung von automatisierten Tests in Datenbank-Projekte - insbesondere auch mit Fokus auf bestehende "legacy"-Projekte. Mit einfachen, realitätsnahen Beispielen wird auch gezeigt, wie sich Datenbank-Tests in eine Continuous-Integration (CI)-Pipeline integrieren lassen.
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.
Nur für XING Mitglieder sichtbar Einheitlicheres Design für die "Marke" CCD?
Dieser Inhalt ist nur für eingeloggte Mitglieder sichtbar.
Ralf Westphal
+4 weitere Kommentare
Letzter Kommentar:
Ralf Westphal
habs mal getwittert. (mist, leider mit einem schreibfehler drin :-) sorry. so kommt es, wenn man es besonders gut machen will und noch lange dran rumfeilt.)
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. ;-)

Moderatoren

Infos zu den Moderatoren

Über die Gruppe "Clean Code Developer"

  • Gegründet: 11.03.2009
  • Mitglieder: 5.022
  • Sichtbarkeit: offen
  • Beiträge: 491
  • Kommentare: 2.987