Probleme beim Einloggen
Ralf Westphal Produktiv - aber ausdrücklich
Wir kommen hier ja zusammen, weil wir finden, dass mehr Clean Code geschrieben werden sollte. Aber warum ist das? Warum gibt es davon noch nicht genug? Ich glaube, das liegt daran, dass das, was Clean Code bewirken soll, nicht gemessen wird. Deshalb merkt man nicht, dass da irgendwas verrutscht und steuert nicht gegen.
Clean Code soll gewährleisten, dass die Teamproduktivität dauerhaft hoch ist. Es geht um mittel- bis langfristige Produktivität. Dafür muss Code in geeigneter Weise strukturiert sein. Für anfängliche und kurzfristige Produktivität ist das nicht nötig.
Wenn es an Clean Code mangelt, dann ist sein Effekt unterhalb des üblichen Radars. Die Produktivität wird schlicht nicht gemessen und dem Kunden nicht fühlbar gemacht. Wäre das so, würde er dazu eine Meinung entwickeln und (An)Forderungen stellen, wenn sich etwas aus seiner Sicht ungünstig entwickelt.
Doch der Kunde sieht von alldem nichts. Er bekommt nur mit, was vor seiner Nase wieder und wieder geschieht. Ein big picture fehlt ihm.
Und wie könnte das anders aussehen? Dazu einige Gedanken: https://ralfw.de/2018/09/making-productivity-tangible/
Enjoy!
Ein weiterer Kommentar
Letzter Kommentar:
Ralf Westphal
Hi, Mike!
Nur für XING Mitglieder sichtbar

>* wie würdest du die issue sizes mit verrechnen? Oder würde sich das (ähnlich wie bei #noEstimates) irgendwann statistisch ausgleichen?
Die Einordnung eines Inkrements in eine Komplexitätskategorie S,M,L findet natürlich vor Beginn der Arbeit statt. Daraus wird aber erstmal nichts speziell abgeleitet.
Anschließend kann du die "historischen Daten" auswählen wir du magst für Berechnungen. Du kannst alle selektieren oder nur die mit Komplexität S oder nur die mit M usw.
Mit der Auswahl kannst du Histogramme malen oder Vorhersagen berechnen.
Inwiefern die Zuordnungen zu den Komplexitätskategorien überhaupt einen Unterschied macht, kannst du auch feststellen. Dann würden sich die Histogramme unterscheiden. Oder du könntest einen Scatterplot machen, bei dem du zb Cycle Time (X) gegen Komplexitätskategorie (Y) aufträgst. Da sollte sich ein Muster zeigen, wenn die Einschätzung einen Wert hat.
"Ausgleichen" tut sich da aber nichts, würde ich sagen. Im Gegenteil! Es soll sich nichts ausgleichen, sondern eben die Zuordnung von S,M,L einen Unterschied machen.
Beantwortet das deine Frage?
Nur für XING Mitglieder sichtbar

>* was ist mit Infrastrukturthemen? Das interessiert den Kunden ja nicht wirklich, ob man z.B. eine Woche für eine tolle CI/CD pipeline aufgewendet hat. Aber es ist ja trotzdem hilfreich bis notwendig ...
"Infrastrukturthemen"... Ich würde immer versuchen, ein "Infrastrukturthema" als Inkrement zu formulieren. Es sollte einen Unterschied für den Kunden machen, ob die Infrastruktur so oder anders ist. Wenn er das nicht spüren kann (Laufzeiteigenschaft), warum sollte dann an der Infrastruktur geschraubt werden? Warum sollte er Geld bezahlen, wenn du etwas tust, wovon er keinen Effekt sieht?
Wenn sich gegen diese Sicht Widerstand erhebt/das nicht machbar erscheint, dann - so glaube ich - würde ich "Infrastrukturthemen" entweder gar nicht tracken oder gesondert kennzeichnen. Dann gibt es Feature, Bug Fix - und Infrastructure als Inkrementtypen.
Wenn du nicht trackst oder für Vorhersagen zb einer Liste anstehender Features nur nicht-Infrastruktur Inkremente auswählst, dann gibt es eben Lücken in der Timeline, dann gibt es Zeiten mit sehr wenig Throughput in Bezug auf Features - und das schlägt sich in der Vorhersage nieder. Das ist ja nur gerecht.
Eine CI-Pipeline würde ich allerdings vor Start der Inkrementproduktion aufsetzen und eher gar nicht mitzählen. Du hast eben "Rüstzeit" für ein Projekt, die etwas anderes ist als die Produktionszeit.
Nur für XING Mitglieder sichtbar

>viele Grüße
>Mike
Ralf Westphal Probleme so oder so lösen
Immer wieder sehe ich es in Clean Code Developer Trainings, dass es den Teilnehmer schwer fällt, den Einstieg in Problemlösungen zu finden. Ich denke, das ist im Tagesgeschäft dann nicht so viel anders, wenn die Probleme größer sind.
Deshalb habe ich mal zwei Problemlösungsansätze beschrieben, die ich hilfreich finde:
Entweder versuche ich, ein Problem zu verkleinern, indem ich es partitioniere - oder ich versuche, es zu vereinfachen. Es entstehen komplementäre partielle Probleme oder auf einander aufbauende Unterprobleme.
Enjoy!
Ralf Westphal TDD - Jetzt aber richtig!
TDD könnte einfach sein, ist es aber für viele nicht. Irgendwie merkwürdig, oder? Neulich habe ich ein Video zum Thema gesehen, in dem Ian Cooper recht schön dargelegt hat, woran es liegt, dass TDD nicht die positiven Ergebnisse zeitigt, die von Kent Beck et al. versprochen wurden.
Allerdings hat mir an dem Vortrag doch noch einiges gefehlt. Er hat zwar eine Checkliste geliefert, was (besser) zu tun ist - doch die allein reicht aus meiner Sicht nicht. Und so habe ich mal zu seiner Checkliste noch ein paar Gedanken zusammengetragen, die es hoffentlich einfacher machen, mit TDD mehr Vorteile zu ernten: https://ralfw.de/2018/08/tdd-how_it_can_be_done_right/
Enjoy!
Philipp Stiefel
Du meinst vermutlich den Vortrag von Ian auf der DevTernity 2017? Das Video habe ich zufällig an diesem Wochenende ebenfalls angeschaut. Absolut sehens-/hörenswert!
Für Interessierte hier der Link: https://www.youtube.com/watch?v=EZ05e7EMOLM
Christian Rehn LSP
Nächste Frage zu einem Prinzip. Es geht immer noch um die Design Cards. Diesmal wäre meine Frage wer LSP einsetzt und wie häufig.
LSP ist mir durchaus bekannt, ich kenne das Kreis-Ellipse-Problem, die verschiedenen Lösungen desselben, ich weiß, dass quasi jedes Problem, das mit Vererbung zusammenhängt, eine Spielart dieses Problems ist und dass man da also überall LSP bedenken kann. Und trotzdem: Ich selbst bedenke bzw. nutze LSP recht selten.
Meine These ist, dass LSP besonders wichtig für Entwickler von Frameworks und Libraries ist und ansonsten nur, wenn man ein komplexes Domänenmodell hat.
Also Hand aufs Herz: Wie sieht es mit praktischen Erfahrungen zu LSP aus?
Stefan Lieser
+2 weitere Kommentare
Letzter Kommentar:
Christian Rehn
Danke für die Antworten. Das deckt sich mit meiner Beobachtung. Streamklassen zählen für mich eher unter Library als unter Anwendungscode und FCoI ist wirklich viel wichtiger. Danke.
Ralf Westphal Abhängigkeiten zwischen Abstraktionen
Angesichts des hartnäckigen Glaubens, dass DIP/IoC im Rahmen von SOLID den Code schon säubern werden, erlaube ich mir eine andere Meinung vorzulegen: https://ralfw.de/2018/07/dependencies-flow-down-abstractions/
Beim DIP soll man sich statt von Konkretem lieber von Abstraktem abhängig machen.
Beim DFA (Dependency Follows Abstraction) Prinzip hingegen ist es umgekehrt: Abstraktes macht sich von Konkretem (dh weniger Abstraktem) abhängig.
Ja, ich glaube, das ist viel wichtiger als das DIP. Allerdings behält das DIP durchaus Wert: für Polymorphie in streng typisierten Sprachen.
Nur wozu braucht man denn eigentlich Polymorphie? Aber das ist nochmal eine ganze andere Frage, auf die der Artikel nicht eingeht.
Grundlegend für die Säuberung von Code ist nicht Polymorphie oder Wiederverwendbarkeit, sondern Abstraktion. Und zwar inhaltliche Abstraktion.
TL;DR: Die meisten Abhängigkeiten zwischen Funktionsbausteinen in heutigen Codebasen sind dysfunktional. Sie schaden, weil sie eng koppeln, was nicht gekoppelt gehört. Da helfen dann auch nicht die tollsten Architekturmuster bis hin zur Clean Architecture. Sie lösen das falsche Problem.
Und was ist das Problem? Das Software nicht systematisch mit Blick auf saubere Abstraktionen entworfen wird.
Der Artikel führt das näher aus...
Enjoy!
PS: Wie kann es sein, dass es beim DIP und beim DFA um Abstraktionen geht, aber in scheinbar so gegensätzlicher Weise? Weil es unterschiedliche Arten von Abstraktionen gibt für verschiedene Zwecke.
Bei DFA geht es um Abstraktion durch Integration, beim DIP um Abstraktion durch Destillation.

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