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
Roland Golla Scala Mob Programming für den guten Zweck am 29.9. in Hamburg
Clean Code bedeutet auch eine hohe Lesbarkeit. Die entwickelt man am besten gemeinsam im Team. Am 29.9. machen wir bei OTTO in Hamburg ein Never Code Alone Event. Das Geld der Registrierung Spenden wir der "Sternenbrücke" für den guten Zweck.
4 * 1.5 Stunden Live Coding mit der Funktastatur.
Realtime Aggregation des Otto.de Event Streams
Du wolltest schon immer wissen, wie viele Produktseiten auf Otto.de pro Sekunden aufgerufen werden, welcher Artikel der meisgesehenste ist oder welcher Kunde die meisten Tabs offen hat?
All das und noch viel mehr werden wir in dieser Mob-Programming-Session herausfinden. Nebenbei beleuchten wir diverse Aspekte einer resilienten, Kafka-basierten Applikation.
- Mit Sebastian und Frederik
Live Coding - Using Akka Streams to write Microservice that supports end-to-end backpressure
Let's write a microservice based on Akka Streams that truly handles backpressure throughout the entire application.
Traditionally, routes built with Akka HTTP directly interact with actors implementing domain logic. One potential issue is the lack of backpressure: when the route just fires messages at the poor domain actors, these messages pile up in the mailbox faster than they can get processed. This is especially the case when the domain actors interact with a database or external services, waiting for a response.
Our microservice also offers an HTTP API, accesses a database and interacts with another external service. By using Akka Streams as the processing engine, incoming HTTP calls will fail fast while a system is overloaded.
- Mit Markus Jura
"Wo klemmt's?" - "Keine Ahnung..."
Mit der Einführung einer Microservice-Architektur und der Kopplung per Kafka ist es uns - dem Tracking-Team@OTTO - gelungen, einen großen Schritt in Richtung Skalierbarkeit und Ausfallsicherheit zu machen. Doch wie kann ich sicher sein, dass jedes Rad im Getriebe funktioniert? Wenn Service B 2.000 Nachrichten pro Sekunde verarbeitet, dann ist das echt toll, aber nur, solange Service A nicht 4.000 pro Sekunde schreibt.
Backpressure über MS-Genzen hinweg ist nicht trivial, aber machbar. Voraussetzung hierfür ist ein Monitoring der Schreib- und Leseraten der einzelnen Kafka Consumer und Producer. In dieser Session werden wir uns mithilfe von Akka (mal ohne Akka-Streams; richtig handgemacht) einer möglichen Lösung nähern. Dabei steht nicht die Kafka-API im Vordergrund, sondern der geeignete Aufbau eines Aktoren-Systems, oder untechnisch ausgedrückt: echte Umsetzung von Fachlichkeit.
- Mit Michael Arndt
Property-based Testing mit Scala
In dieser Session wollen wir gemeinsam in die Tasten greifen und Tests schreiben, um in kleinen Programmen Fehler zu finden und deren Funktionsweise zu ergründen. Dabei werden wir verschiedene Testbibliotheken nutzen und einfache Unittest und Property-based Tests entwicklen.
- Mit Thomas Hackbarth
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!
Paolo Strever oneresource ag
Hallo, liebe Gruppenmitglieder.
Herzlichen Dank für die Aufnahme in diese Gruppe.
Mein Name ist Paolo Strever und ich repräsentiere die Firma oneresource ag.
Ich freue mich auf regen Austausch.
Grüsse aus Wil, Ostschweiz
Paolo Strever
CEO
oneresource ag
_____________________________________________________________________________
Wir, oneresource, stehen an vorderster Front, wenn es um die Digitalisierung der Geschäftsmodelle und Trans¬formation zu SAP S/4HANA geht. Zusammen mit unseren zukunftsorientierten und renommierten Kunden erarbeiten wir die erfolgreiche Transformationsstrategie und setzen diese mit einer transparenten Methodik um.
Die 2012 gegründete Unternehmung mit Sitz in Wil (SG) ist in der ganzen Schweiz tätig und begeistert dank erfahrenen Berater bereits über 150 renommierte Kunden. Immer unter dem Motto 'mehr als Sie erwarten...'.
Aus einer Hand decken wir den gesamten Customer Lifecycle ab: Business Consulting, ERP Neueinführung, Optimierung einer bestehenden Lösung, SAP S/4HANA Transformation, Betrieb und Support.
Business Consulting
- Process & Organization Consulting
- Business Project Management
- IT Management Consulting
- Contract & License Management
Process Consulting
- oneresource Solutions
- SAP Cloud Solutions
- SAP Solution Consulting
- SAP Technology Consulting
- SAP S/4HANA Transformation
SAP Service
- SAP Operations
- SAP Support
- Software Maintenance
Wir freuen uns auf Ihre Kontaktaufnahme und Ihren Besuch.
oneresource ag
Zürcherstrasse 65
9500 Wil (SG)
+41 71 950 55 55
info@oneresource.com
https://www.oneresource.com

Moderatoren

Infos zu den Moderatoren

Über die Gruppe "Clean Code Developer"

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