Probleme beim Einloggen
Roland Golla Wie ein Slider zur Katastrophe wird - Prototyping und Planung holen viel Zeit raus - Von Never Code Alone
Robert Bruckbauer Clean Code ist lesbarer Code?
Ich verfolge seit einem Jahr einen agilen Ansatz für die Erstellung und Pflege einer Produktdokumentation in einem Projekt mit agiler Entwicklung. Ein wesentlicher Aspekt von CARDS+ (http://cardsplus.info) im Bereich der technischen Dokumentation ist die Vermeidung von redundanten Dokumenten durch die Einbeziehung von lesbarem Code als Teil der Produktdokumentation.
Reichen die Regeln der Clean-Coder aus, um lesbaren Code zu bekommen, den nicht nur das Scrum-Team versteht?
Konkretes Beispiel aus meinem aktuellen Projekt:
Das REST-API wird mit swagger beschrieben, die Datenstrukturen der Daten, die über REST ausgetauscht werden, definieren wir mit einem avro-Schema. Swagger und avro-Schema sind Teil der Dokumentation und werden vom PO "gelesen" und verstanden.
Ralf Westphal Dirk Pass Robert Bruckbauer
+14 weitere Kommentare
Letzter Kommentar:
Nur für XING Mitglieder sichtbar
Aus eigener Erfahrung kann ich den Vorrednern nur zustimmen:
- Clean code zielt auf (software crafmanship) bzw. eine Verbesserung des Codes ab, die sich auch auf die Lesbarkeit auswirkt.
- Zum Verständnis von Code muss man aber die Sprachsyntax und die Semantik des Codes verstehen, letzteres erfordert in der Regel Domänenwissen, z.B. Methode mit Name "checkSmgwCertRequest" -> ohne Kenntnis, dass sich das auf TR-03109-4 (Public Key Infrastructure for Smart Metering) und die Rolle "SMGW" (Smart Meter Gateway) bezieht, wird das Verständnis schwer.
Allerdings habe ich nur selten Fälle gesehen, in denen es sinnvoll war, dass Analysten / Berater Code verstehen. Das waren dann eher Fälle in denen beim Kunden Fehler aufgetreten sind und wo dann jemand nach oberflächlichem Verständnis meinte, er könne mal eben schnell einen workaround einbauen. Das war dann eher kontraproduktiv.
Ich halte es für sinnvoller verschiedene Dokumentation für die verschiedenen Abstraktionsebenen zu erstellen. Das erleichtert auch orthogonale Dokumentation, wie von Ralf beschrieben. Da wäre z.B. Architekturdokumentation, Anforderungsdokumentation usw. IEEE-1998:830 (ist mittlerweile durch ein neueres Dokument abgelöst, das ich aber nicht so toll finde) gibt einige sehr gute Hinweise zum Schreiben von Doku.
Nur für XING Mitglieder sichtbar Wo ist das agile development framework hin?
Hallo,
ich fand das ADF ziemlich interessant als ich vor einigen Jahren darauf gestoßen bin. Mittlerweile ist aber die Seite http://www.agile-development-framework.net/ anscheinend spurlos aus dem Netz verschwunden.
Weiß jemand wo das hin ist? Wurde das umbenannt oder ist es in der Versenkung verschwunden, weil es sich nicht durchgesetzt hat ... ?
Dank im Voraus.
Gruß Sebastian
Paul Kunze
Ein weiterer Kommentar
Letzter Kommentar:
Okay, danke.
Ich habe mal bei Herrn Roden nachgefragt. Er hat die Seite aufgrund zu geringer Resonanz abgeschaltet. In der dotnetpro hatte er 2011 eine Artikelserie zu ADF geschrieben, welche er mir gerne als pdf schickt. Bei Interesse kann ich also nur empfehlen, bei ihm nachzufragen.

Moderatoren

Infos zu den Moderatoren

Über die Gruppe "Clean Code Developer"

  • Gegründet: 11.03.2009
  • Mitglieder: 4.955
  • Sichtbarkeit: offen
  • Beiträge: 477
  • Kommentare: 2.973