ein loop

Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.

Getting started ... Alles für einen gelungenen Start.
35 Beiträge • Vorherige Seite 3 von 3 (current)
35 Beiträge Vorherige Seite 3 von 3 (current)

Re: ein loop

Beitrag von Unit605 (Expert / 975 / 37 / 93 ) »
Hier mal die Fakten ueber die Dokumentation von Kundeneigenen Entwicklungen aus einem mehrjaehrigen internationalem Projekt in Deutschland:

Hier "nur" die Klassen und Methoden, bei Reports und Funktionsbausteinen sieht es nicht besser aus:
Kundeneigener Namensraum /…/

Erstellte Klassen: 395
Erstellte Methoden: 1714

Dokumentierte Klassen: 15
Dokumentierte Methoden: 5


Kunden Namensraum Z* oder Y*

Erstellte Klassen: 380
Erstellte Methoden: 1351

Dokumentierte Klassen: 3
Dokumentierte Methoden: 4
Selbst Klassen, die von jedem Programmierer genutzt werden sollen, sind undokumentiert.
[Ironie on]Deshalb nutzt die auch jeder[Ironie off']

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: ein loop

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Es ist mir ein völliges Rätsel, warum ein Kunde sowas abnimmt, ehrlich.


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: ein loop

Beitrag von Unit605 (Expert / 975 / 37 / 93 ) »
ralf.wenzel hat geschrieben:Es ist mir ein völliges Rätsel, warum ein Kunde sowas abnimmt, ehrlich.
Ralf
Da muss ich Dir sogar zustimmen, auch ehrlich!

Wenn man das Thema allerdings anspricht, macht man sich ganz schnell, ganz unbeliebt.

Nicht nur beim Kunden, sondern auch bei den Entwicklerkollegen!

Fazit: Sprich nicht drueber und verschwende keine Zeit mit Dokumentation.

Re: ein loop

Beitrag von ralf.wenzel (Top Expert / 3776 / 176 / 262 ) »
Aber dann ändert sich ja nix. In derselben Firma wird kein Schaltkasten gebaut ohne Schaltplan. Bei mir ist das so, dass sich JEDER Kunde anhören muss, wieviel Zeit ich (bzw. wieviel Geld er) durch Dokumenation eingespart hätte. Und ich dokumentiere.

Ganz besonders, als ein Kunde ganz begeistert war, dass wir eine Anwendung praktisch schulungsfrei in Norwegen ausrollen konnten, weil die F1-Doku von mir keine Fragen offen ließ.

Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: ein loop

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
Die Faulheit steckt ganz tief drin, und da Menschen Gewohnheitstiere sind, ändert niemand gerne seinen Arbeitsstil.
Wenn man das Thema allerdings anspricht, macht man sich ganz schnell, ganz unbeliebt.

Nicht nur beim Kunden, sondern auch bei den Entwicklerkollegen!
Nicht weil die es nicht gut fänden, dass man selber dokumentiert, sondern weil sie sich unter Druck gesetzt sehen, es auch machen zu sollen. Und das haben sie noch nie gemacht, das liest sich ja eh nie jemand durch und bla.

Es gibt allerdings noch einen zweiten Aspekt bei der Sache: Nicht jeder kann mit Sprache umgehen, noch nicht mal mit seiner eigenen. Ich kenne Entwickler, die sind clever und finden Lösungen für vertrackte Probleme. Aber ihr Codekommentar liest sich zuweilen recht legasthenisch. Ich kenne sogar einen Kinderpsychiater, der bei allen möglichen Fachkräften (Jugendamt eingeschlossen) als Koryphäe gilt und einen ausgezeichneten Ruf genießt, aber ich habe auch mal Emails von ihm gesehen. Das sind kaum richtige Sätze, eher bedingt zusammenhängend aneinandergereihte Satzfragmente.

Und das ist ein Problem, das Du und ich uns vielleicht nur schwer vorstellen können, Ralf, weil es uns beiden leicht fällt, Sachzusammenhänge nachvollziehbar in zusammenhängende Sätze zu kleiden (und das sogar auf deutsch und englisch). Andere haben damit von ihren Fähigkeiten her richtig ein Problem, obgleich sie ansonsten alles andere als Deppen sind.

Aber wie dem auch sein mag, Tatsache ist, dass nicht dokumentiert wird und dass man in prozeduraler Programmierung noch wesentlich besser eine Chance hat, mies dokumentierten Code zu warten (weil man sich da notfalls in Kleinarbeit die Funktionsweise herleiten kann). Und auf diesem Hintergrund ist OO ein Irrweg (außer, wie gesagt, bei Großprojekten mit umfassendem Blueprint und sonstiger Doku).

Ich weiß, das Wort "Irrweg" klingt sehr hart. Aber denk mal an Atomkraftwerke. Ich behaupte, von unserem technischen Wissen her sind wir durchaus in der Lage, ein AKW so sicher zu betreiben, dass man das Restrisiko unter Ulk verbuchen kann. Warum müssen wir dennoch Angst haben (mal abgesehen von der Endlagerthematik)? Weil AKWs von Menschen betrieben werden, die Fehler machen (Experiment in Tschernobyl) und unter Kostendruck Kompromisse eingehen, die - genau wie die fehlende Programmdokumentation - vom Soll abweichen. Vor einiger Zeit wurden in Frankreich die Notstromgeneratoren der AKWs überprüft. Ergebnis: 0% befanden sich in einwandfreiem Zustand. Die restlichen Zahlen habe ich nicht mehr genau im Kopf, aber ein zweistelliger Prozentsatz befand sich im Zustand "heruntergekommen" und waren nicht in startbereitem Zustand. Und das ist nur ein Schlaglicht auf einen Sicherheitsaspekt von vielen in einem AKW. Daneben wissen wir von Rissen im Druckbehälter in Tihange, und ich wette, unter der Haube gibt es zahllose Mängel in den AKWs, die man alle beheben könnte, wenn man das Geld in die Hand nehmen würde - aber das wird nicht gemacht.

Theoretisch wären AKWs also sicher betreibbar. In der Praxis ist das unter der Führung real existierender Menschen jedoch unmöglich. In der Konsequenz lassen sich AKWs also nicht sicher betreiben.

Mit Codedoku ist es genau das gleiche. In der Theorie kann man jede Klasse, jede Methode, jedes Attribut und jeden Report sorgsam dokumentieren. In der Praxis ist das jedoch nicht durchsetzbar. Es wird nicht gemacht, und es wird auch in Zukunft nicht gemacht werden. Damit ist es äquivalent zu "unmöglich" einzuschätzen. Und damit verbietet sich der Einsatz von Programmiermitteln, die nur unter dieser Bedingung wartbar sind.

Man kriegt die Programmierer ja noch nicht mal dazu, nicht immer SELECT * zu schreiben. Na ja, vielleicht bringt HANA an dieser Stelle eine Verbesserung.

Vergleichbare Themen

1
Antw.
721
Views
4
Antw.
3450
Views
LOOP in einem LOOP
von Bjuti » 10.09.2013 15:18 • Verfasst in ABAP® für Anfänger
39
Antw.
7076
Views
Loop
von Kai999 » 27.07.2017 16:15 • Verfasst in ABAP® für Anfänger
52
Antw.
9281
Views
LOOP AT
von cuncon » 01.02.2018 09:28 • Verfasst in ABAP® für Anfänger
7
Antw.
2262
Views
Loop-Problem
von TobiB » 17.12.2007 13:15 • Verfasst in ABAP® Core

Über diesen Beitrag


Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.

Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Aktuelle Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Interne Tabelle
vor 5 Tagen von black_adept 2 / 133
MaLo-Checker in ABAP
vor einer Woche von A6272 6 / 254

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 3 Tagen von Lucyalison 1 / 64
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 107
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 140