Probleme beim Einloggen
Nur für XING Mitglieder sichtbar Clean Java Script - Strategien für die Quadratur des Kreises
Dieser Inhalt ist nur für eingeloggte Mitglieder sichtbar.
Roland Golla Stefan Lieser Denis Kuniss
+6 weitere Kommentare
Letzter Kommentar:
Markus Kraus Gradwechsel
CCD: "Sobald ein Entwickler [...] 21 Tage ohne Wechseln des Armbands gearbeitet hat, kann er den Grad als gemeistert ansehen, zum nächsten fortschreiten und dessen Armband überstreifen."
Das hat mich frustriert. Ich wäre nie aus dem Roten Grad heraus gekommen. An irgendeinem der 21 Tage habe entweder mal ISOP verletzt oder die Root Cause Analysis abgebrochen oder ... Nobody is perfect - ich jedenfalls nicht 21 Tage lang.
Jetzt wechsele ich unabhängig davon alle 3 Wochen in den nächsten Grad. Ich mache mir bei der täglichen Reflektion meine Verfehlungen bewusst, gelobe mir Besserung und habe wieder mehr Freude am CCD.
Markus Wagner Stefan Lieser
+2 weitere Kommentare
Letzter Kommentar:
Christian Schmoll
Oder, um es mit den Worten von Joshua Bloch zu sagen:
"Learning the art of programming, like most other disciplines, consists of first learning the rules and then learning when to break them."
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:
Nur für XING Mitglieder sichtbar Senior IT Recruiter für den Raum Verständnis gesucht
Dieser Inhalt ist nur für eingeloggte Mitglieder sichtbar.
Alexander Weinhard
+2 weitere Kommentare
Letzter Kommentar:
Jürgen Mottok Promotionsmöglichkeit im Bereich "Lernen von Software Engineering" (Informatik)
Sehr geehrte Kolleginnen und Kollegen,
das Qualitätspakt Lehre Projekt EVELIN ("Experiementelle Verbesserung des Lernens von Software Engineering") bietet Promotionsmöglichkeiten an.
Die Attraktivität des ausgeschriebenen Themas liegt sowohl im spannenden Feld des Software Engineering mit
seinen Methoden und Techniken, als auch in dessen fachdidaktischen Herausforderungen begründet.
Die Promotionsstellen sind ab 1.10.2014 oder später zu besetzen.
Bitte wenden Sie sich bei Interesse an Prof. Dr. Jürgen Mottok, OTH Regensburg, LaS³ (juergen.mottok@oth-regensburg.de).
Viele Grüße
Jürgen Mottok
--
Prof. Dr. Jürgen Mottok
Faculty of Electrical Engineering and Information Technology
Laboratory for Safe and Secure Systems, LaS3
- a software engineering discipline (http://www.las3.de)
_
OTH Regensburg
Ostbayerische Technische Hochschule Regensburg
Seybothstrasse 2
93053 Regensburg
Phone +49 (0)941/943-1120
FAX +49 (0)941/943-1424
Mobile +49 0160 966 569 62
E-Mail: juergen.mottok@oth-regensburg.de
LaS³: http://www.las3.de
OTH: http://www.oth-regensburg.de
--

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