Probleme beim Einloggen
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.
Marwin Wiechert Global Day of Coderetreat 2017
Hallo zusammen,
am Samstag, den 18.11.2017 findet weltweit der diesjährige Global Day of Coderetreat statt.
Wenn ihr euch nun fragt: Was ist bitte sehr ein Coderetreat? Ein Coderetreat ist eine ganztägige Veranstaltung zum Üben und Verbessern der Fähigkeiten zur Software-Entwicklung und des Software-Designs. In entspannter Atmosphäre und ohne den Druck "fertig" werden zu müssen, können sich Entwickler vollständig auf das Programmieren selbst konzentrieren, Erkenntnisse gewinnen und Erfahrungen mit anderen Teilnehmern austauschen.
Wer also Interesse hat in entspannter Runde an seinen Fertigkeiten zu arbeiten, kann sich bei dem folgenden Meetup anmelden:
https://www.meetup.com/de-DE/JUG-Essen/events/244337551/
Bei Rückfragen kommt gerne auf mich zu.
Beste Grüße
Marwin
Rolf Cerff Wieviel sogenannter allgemeiner Basiscode ist sinnvoll? Wann wird dieser kontaproduktiv?
In den Best Practices der Softwareentwicklung, auch in der Clean Code Bewegung, existiert ein Prinzip: Don't repeat yourself.
Übersetzt lautet es etwas vereinfacht ausgedrückt:
Wenn Du Code mehr als einmal brauchst, dann lagere ihn in eine eigene Methode oder Klasse aus.
Das wird in Projekten tatsächlich auch sehr oft gemacht. Es entstehen dann die allbekannten Helper- und Utilitiesklassen und die Basiskomponenten als eigene Libraries.
So weit so gut.
In Projekten erlebe ich aber immer wieder, dass diese Vorgehensweise zu negativen Effekten führt und die Produktivität stark leidet.
- Basiskomponenten werden immer größer und komplexer, so dass sie zu einem erheblichen eigenen Wartungsaufwand führen, der dann dem eigentlichen Ziel,
der Entwicklung von Business Value fehlt.
- Es gibt Projekte, bei der die Wartung und Weiterentwicklung solcher Komponenten erhebliche Resourcen verschlingt.
- Diese Komponenten und ihre Nutzung sind oft schlecht dokumentiert und sie werden oft von bestimmten Leuten entwickelt, die allein dazu in der Lage sind diese zu warten..
Wie kann es dazu kommen:
Solche Basiskomponenten, Methoden und Klassen fangen oft einfach an. Code wird zweimal benötigt, daher wird er ausgelagert.
Eine neue Methode die die Funktion dieses Codes benötigt, benötigt eine gewisse Abwandlung davon, z.B. ein zusätzlicher Parameter der Methode übergeben wird,
und natürlich Funktionalität die diesen Parameter einsetzt.
So geht es dann weiter, es kommen immer mehr Spezialfälle hinzu. Es entstehen immer mehr solcher Basiskomponenten.
Nicht nur der Code der Basiskomponente wird immer komplexer, auch die Schnittstelle diese Komponente zu benutzen wird komplizierter.
Oft ist es dann auch so, dass die Wartung der Komponenten von bestimmten Entwicklern, oft auch Senior Entwicklern oder Chefarchitekten genannt, vorgenommen wird.
Das scheint zuerst auch durchaus sinnvoll, weil der Code irgenwann umfangreich wird und nicht mehr von jedem verstanden wird.
Es entstehen Abhängigkeiten von einigen wenigen Entwicklern, wenn es darum geht die Basiskomponente zu erklären,
neue Anforderungen darin umzusetzen oder Bugs darin zu fixen.
Und wie schon angesprochen,
nimmt die Wartung dieser Komponenten irgendwann einen erheblichen Aufwand ein der dem eigentlichen Ziel, Business Value zu erzeugen, verloren geht.
Im Extremfall hat man das deutliche Gefühl, mit dieser Vorgehensweise deutlich über das Ziel hinausgeschossen zu sein, eine Gesamtlösung entwickelt zu haben,
bei der die Wartung der Basiskomponenten und die beschriebenen Probleme, die Produktivität des Projektes lähmt und zu viele Resourcen bindet.
Eine einfache Änderung scheint dann auch nicht mehr möglich, da ja sehr viele Komponenten von diesen Basiskomponenten abhängig sind.
So weit zur Symptombeschreibung:
Fragen die sich für mich daraus ergeben sind:
- Wer kennt dieses Phänomen ud wie ist er oder sie dieses Problem angegangen?
- Wie viel Repeat yourself und Copy & Paste ist vielleicht dann doch nicht so schlecht?
- Gibt es Kriterien, die helfen zu entscheiden, wann eine mehrfach verwendete, aber leicht abgewandlete Funktion auszulagern ist, oder doch einfach zu kopieren ist?
- Für das Prinzip "Don't Repeat yourself": Gibt es Regeln für den pragmatischen Einsatz, und wo fängt die ideologisch kontraproduktive Nutzung dieses Prinzips an?
Ich habe mir dazu auch eigene Gedanken gemacht, stelle diese Fragen aber einfach mal offen in den Raum und bin gespannt auf Ideen, Erfahrungen und Lösungsansätze.
Oliver Löffler John Boyd-Rainey Maximilian Raab
+13 weitere Kommentare
Letzter Kommentar:

Moderatoren

Infos zu den Moderatoren

Über die Gruppe "Clean Code Developer"

  • Gegründet: 11.03.2009
  • Mitglieder: 5.001
  • Sichtbarkeit: offen
  • Beiträge: 482
  • Kommentare: 2.983