ein loop

Re: ein loop

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']

Re: ein loop

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

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.