Probleme beim Einloggen
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.
John Boyd-Rainey Clean Code für (CC-)Newbies - aber wie?
Wahrscheinlich sind alle Mitglieder dieser Gruppe eingefleischte Clean-Coders, kennen seit Jahren ihre SoC, SRP, SLOP, GLoOP & FLoNK usw. und schreiben Methoden mit allerhöchstens einer Zeile wie jeder Profi.
Aber was ist mit euren Kollegen?
Wie geht ihr mit deren schlechtem Code um?
Meine Erfahrung als Trainer für CCD, Java, C++, Design Patterns, Refactoring usw. zeigt, dass solche Schulungen sehr sinnvoll sind. [Ach! ;-)] Aber danach brauchen die Programmierer wiederholtes Erinnern an das Gelernte, ansonsten kehren sie sehr schnell zu ihren alten, schlechten Gewohnheiten zurück. D.h. mehr Reviews, Coaching und Vertiefung des Gelernten sind notwendig. In ein paar Projektgruppen wird nicht nur die Funktionalität, sondern auch die Sauberkeit des Codes geprüft – und zwar VOR dem Einchecken. Löblich!
Habt ihr hierzu andere Erfahrungen?
Wie geht ihr mit diesen Kollegen um?
Alexandra Klein Sergio Sanchez
+7 weitere Kommentare
Letzter Kommentar:
Ralf Westphal
Ich erschrecke immer wieder über diese Formulierungen:
* Der Produktowner sagt "Wenn ich User Stories ins Team gebe..."
* Entwickler sagen "Der Product Owner gibt uns keine Zeit..."
Erschreckend finde ich das, weil es zeigt, wie groß die Illusion ist, es würde agil gearbeitet. Dabei ist Cargo Cult am Werk. Going thru the motions. Mehr nicht.
"Ins Team" kann man nur etwas geben, wenn man außerhalb des Teams ist. Die Formulierung des POs verrät also, dass er sich außerhalb denkt. Der Trick von cross-functional Teams ist aber, dass der PO eben nicht außerhalb sitzt, sondern Teil des Teams ist wie Entwickler oder Tester. Er nur einer unter Gleichen. Er bekleidet eine Rolle wie andere auch. Alle Rollen sind komplementär, sie bedürfen einander. Jeder hat eine Kompetenz, die zum Ganzen beiträgt.
Deshalb hat der PO auch keine Weisungsbefugnis, was die Verwendung von Zeit der Entwickler angeht. Solange ein PO noch Zeit geben kann, ist er kein PO und besteht kein agiles Team. Der PO ist kein Projektleiter und kein Kunde. Er ist Teammitglied auf Augenhöhe mit den anderen Teammitgliedern.
Wo man auf Augenhöhe ist, da gibt es kein Ansagen und andere spuren. Da gibt es nur Einladungen, Wünsche, Verhandlungen, Kompromisse. Ein PO, der ansagt, wäre dumm. Entwickler, die ansagen, wären dumm. Es geht um Professionalität der Einzelnen in ihren Rollen und Verständnis für die anderen Rollen.
In solcher selbstverantwortlicher Organisation (Autonomie) ist eine Balance zu finden zwischen den Anforderungen die da lauten Funktionalität, Effizienz, Nachhaltigkeit. Und wenn dann die Entwicklung aufgrund ihrer Professionalität weiß, dass die Balance gekippt ist, dann tut sie das Nötige, um sie wieder herzustellen. Der PO hat dafür Verständnis, weil er der Entwicklung in seinem Team vertraut.
Umgekehrt vertraut die Entwicklung und hat Verständnis für den PO. Denn alle ziehen an einem Strang.
Product Owner müssen keine Zeit frei schaufeln. Das ist nicht ihr Job. Sie vertreten lediglich eine Position in einem Kräftespiel, das gut daran tut, nicht aus dem Gleichgewicht zu geraten.
Ralf Westphal Software aus Abstraktionen bauen
Die Schichtenarchitektur ist vielleicht das beliebteste Architekturmuster überhaupt. Sie ist ja so simpel und naheliegend. Leider macht sie aber auch viele Probleme, denen man mit weiteren Maßnahmen gegensteuern muss.
Dabei gibt es schon seit Jahrzehnten eine alternative Vorstellung davon, wie Software grundstrukturiert sein sollte. Leider hat es die nur irgendwie nicht in den Mainstream geschafft. Merkwürdig.
In diesem Artikel stelle ich diese Alternative im Kontrast zur Schichtung vor. Enjoy!
Maximilian Raab
Ein weiterer Kommentar
Letzter Kommentar:
Johan Samyn
Another very succinct blogpost, Ralf. And the preparing of food real world example helps make the ideas more tangible. The pictures also provide great clarity. Such blogposts help build a crisp clear understanding.
Ralf Westphal Der Rhythmus bei dem jeder mit muss
Da reise ich durch die Gegend und gebe Clean Code Trainings, in denen ich die allerbesten Tipps und Tricks und Prinzipien und Praktiken vermittle, um endlich sauberen Code zu schreiben... und nun merke ich, dass ich etwas fundamental falsch gemacht habe all die Jahre.
Ich habe mich zu sehr auf den Code konzentriert. Warum auch nicht, es heißt ja Clean *Code* Development ;-)
Worauf ich mich viel, viel mehr hätte konzentrieren müssen, das ist der Prozess, das Vorgehen, der Takt.
Wie viel SRP oder DI oder PoLA oder TDD oder lesbare Namen usw. usf. ist zweitrangig, solange das Eine nicht stimmt: der Rhythmus.
Die allerwichtigste Praktik des Clean Code Development ist nämlich das Feedback. Feedback geben, verlässlich und bald, ist der Rahmen, den alle anderen Tipps und Tricks und Prinzipien und Praktiken brauchen.
In einem Artikel habe ich mein Umdenken näher erklärt: http://ralfw.de/2017/04/die-geburt-von-clean-code-aus-der-produktivitat/
Es geht dabei schlicht und einfach um Geld.
Und wenn dann der Feedback-Rhythmus unverbrüchlich steht, ergeben sich viele Anlässe, um über eine Methode zu sprechen die hilft, das Feedback flüssig und positiv zu machen.
Olaf Vogel Ralf Westphal Kai Uwe Hempel
+8 weitere Kommentare
Letzter Kommentar:
Ralf Westphal

>Als Beispiel hierfür kann man sich die Entwicklung eines Schachprogramms vorstellen, von der tollen Oberfläche bis hin zum leistungsfähigen Schach-Engine im "Untergrund". Hier könnte der PO/Kunde ein vorzüglicher Schachversteher sein, der entsprechend funktionale Vorgaben für den Schach-Engine machen kann, aber letztlich beim Thema KI-Ansätze und -Algorithmen aussteigt.
Der PO muss einem Schachprogramm keine Ahnung von KI haben. Für den ich es ein Turing-Test, wenn er als Schachexperte die Abnahme macht ;-)
Allerdings: Sein Job ist es, dem Entwicklungsteam Schachprobleme zu geben. Und zwar sehr differenziert. Womöglich noch differenzierter, als er es sich in seinem Expertenkopf sonst vorstellt. Und genau das muss die Entwicklung von ihm fordern.
Beispiel Word Wrap: Der PO ist Experte für Textumbrüche. Er stellt Aufgaben, ist aber schon unbewusst kompetent. Die Entwicklung muss ihn in die bewusste Kompetenz zurückholen und klar machen "Das Detail Worterkennung ist für uns wichtig. Das müssen wir separat betrachten!" Das wäre dem PO nicht selbst in den Sinn gekommen. Ebensolche Details gibt es in jeder Domäne. Da dürfen ja auch keine Naivlinge der Entwicklung einem Domänenexperten gegenübersitzen. Also: 1. Prämisse ist Augenhöhe.
2. Prämisse ist - das muss ich wohl immer wieder betonen -: Jeder Takt (ob meine 16 Stunden oder die 2 Wochen einen Scrum-Sprints) verlangt, dass es keine große Forschungsaufgaben gibt. Wo noch ein KI-Problem zu lösen ist, da kann man einem Kunden gegenüber weder in dem einen noch dem anderen Zeitraum ein Ergebnisversprechen geben.
Leider überschätzen sich Entwickler immer wieder. Sie glauben, sie müssten nicht mehr forschen und seien schon Handwerker. Und dann rauschen sie in eine Technologie, die sich nicht beherrschen. Das passiert auch schon bei einfachen Katas.
Es ist also ebenfalls zu üben, die Selbsteinschätzung in Relation zum Problem richtig hinzukriegen.
Ich versuche mal eine kleine ASCII-Grafik hier:
...++.++.....++....++...+++.......++...+.........++................+.+.+......++.....++
Punkte (...) bedeuten "Nachdenken" und Diskussion. Die Dauer lässt sich vorher nicht bestimmen. In dieser Zeit wird ein Problem analysiert und über Lösungen nachgedacht.
Pluszeichen (++) bedeuten Feedbackzyklus. Es wird vorher festgelegt, wie lange das dauern soll, wann das nächste Feedback kommt. Und das ist wichtig!
Ralf Westphal Kriterien für die Zukunftsfähigkeit
Die Zukunftsfähigkeit einer Codebasis wird beim regelmäßigen Review überprüft. Was aber sind die Kriterien, die dabei angelegt werden sollten?
Ich habe mir in vier Artikel dazu Gedanken gemacht. Zukunftsfähigkeit hat mehrere Aspekte:
Und zum Abschluss noch eine Checkliste für den Review: http://ccd-school.de/2017/05/zukunftsfahigkeit-checkliste-fur-den-review/
Ein weiterer Kommentar
Letzter Kommentar:
Olaf Vogel
Vielen Dank für die - wie von Ihnen gewohnt - detaillierte und in sich schlüssige Erläuterung der Aspekte! Werde Ihre Gedanken in unser Entwickler-Team tragen.

Moderatoren

Infos zu den Moderatoren

Über die Gruppe "Clean Code Developer"

  • Gegründet: 11.03.2009
  • Mitglieder: 4.903
  • Sichtbarkeit: offen
  • Beiträge: 469
  • Kommentare: 2.909