Hallo,
ich beschäftige mich rein aus Hobby mit der Entwicklung von µC
Programmen- also letztendlich von Firmware.
Selbst bei diesen, im Vergleich zu den Profis, sehr einfachen und wenig
komplexen Programmen wird es für einen anderen schwierig werden alles im
Detail nach zu vollziehen, was und warum ich da Programmiert habe, auch
mit vielen Kommentaren im Quellcode.
Bei Großkonzernen und Sicherheitskritischen Bereichen arbeiten gibt es
sicherlich Systeme und Vorschriften die dafür sorgen das die
Entwicklungsarbeit von ehemaligen Mitarbeiter immer Nachvollziehbar und
damit Nutzbar ist.
Wie ist das aber bei der kleinen "Entwicklungsbude" die irgendwelche
Einzellösungen für die Industrie entwickelt z.B. irgendeine spezielle
Steuerung für eine Maschine die "so" nur bei einer Firma genutzt wird ?
Wenn da ein Mitarbeiter die Firma verlässt, wie wird gesichert das die
Firmware für solche Steuerungen immer noch gewartet und verbessert
werden kann bzw. Probleme auf Softwareebene behoben werden können.
Der ehemalige Entwickler wird wohl nur soviel Kommentare in seinen
Quellcode geschrieben haben das er selber nach längerer Zeit alles
verstehen konnte - gezielte Fehlinformationen oder "leere"
Programmanteile im Quellcode um zu verhindern das ein Nachfolger das
Programm gut nachvollziehen kann wird es wohl leider auch im
professionellen Umfeld geben.
Sebastian
Da geht viel Geld flöten, darauf kannst du wetten ;-)
Das Problem, wie z.B. einen Bug beheben, wird in einem solche Fall gerne
irgendwelchen Entwicklern, vorzugsweise Neulingen vorgeworfen (macht
mal). Die werkeln dann da Monate hin.
Sowas zu ändern ist harte Arbeit:
Man muss entweder den Quelltext verstehen, die Firmware komplett neu
schreiben, oder das Firmwareproblem durch eine Hardwareänderng beheben.
Wie die Quoten genau liegen, ist mir nicht klar. Persönlich habe ich
schon alle 3 Möglichkeiten erlebt.
Mein Lieblingsprojekt bei einem ehemaligen Arbeitgeber ist ein
kompletter Softcore für FPGAs (ein 32-Bit-Prozessor immerhin), in dem
keine einzige Kommentarzeile vorkommt und zu dem kein einziges Dokument
existiert. Kein einziger Entwickler in der Firma geht da dran, also wird
das Teil seit 10 Jahren unverändert verwendet.
Die flanschen lieber ein externes RAM an jedes einzelne FPGA, statt den
VHDL-Code so zu ändern, dass (ausreichend vorhandene) interne RAM-Blöcke
des FPGAs verwendet wereden können. Das traut sich nämlich keiner. Das
kostet einen 4-5-Stelligen Betrag im Jahr für RAMs...
Der zuständige Entwickler ist in Pension und war Firmengründers
Liebling, daher ist der Code noch dazu "heilig", kennt man ja.
Das ist der sogenannte Heldenansatz, den gerade viele kleine, aber auch
manche große Firmen pflegen.
Dokumentation, die richtige Art von Dokumentation, bei der Entwicklung
zu erstellen und diese über Jahre hinweg mit dem Produkt zu pflegen
kostet Geld. Das sparen sich solche Firmen lieber und beschäftigen
Helden, die die Software schreiben und warten und arme Würstchen nur zum
Warten.
Alternativ wird Wegwerfsoftware erstellt. Wenn was Signifikantes
geändert werden soll wird die ganze alte Software weggeworfen und neu
gemacht. Das ist bei der Software für Webseiten fast schon der
Normalfall. Ein Webseiten-"Relaunch" ist nichts anderes als dass man die
gesamte Webseite, von der Grafik bis zum Code, weg wirft und neu macht.
Es gibt in dem Umfeld noch anderes Verhalten, zum Beispiel die
Fahrerflucht bzw. Verbrannte Erde. Das ist wenn ein Programmierer einen
unwartbaren Scheiß zusammenprogrammiert, er das auch weiß, und deshalb
bei der ersten sich bietenden Gelegenheit die Flucht antritt. Sei es
eine Versetzung in eine andere Abteilung oder er wechselt zu einer
anderen Firma, bevor es auffällt was für einen Mist er gebaut hat.
Dann kenne ich noch das "drive by shooting". Das geht so ähnlich. Hier
kommt ein Berater mal kurz vorbei, richtet ein Codemassaker an und
flieht mit Höchstgeschwindigkeit vom Tatort. Natürlich nicht ohne sich
die Taschen mit einem saftigen Honorar vollgestopft zu haben.
Sebastian schrieb:> Wie ist das aber bei der kleinen "Entwicklungsbude" die irgendwelche> Einzellösungen für die Industrie entwickelt z.B. irgendeine spezielle> Steuerung für eine Maschine die "so" nur bei einer Firma genutzt wird ?>> Wenn da ein Mitarbeiter die Firma verlässt, wie wird gesichert das die> Firmware für solche Steuerungen immer noch gewartet und verbessert> werden kann bzw. Probleme auf Softwareebene behoben werden können.
Ein gängiger Weg ist, dass der Mitarbeiter seinen Nachfolger einlernt.
Je nach Kündigungsfristen und der Dauer, bis man einen Nachfolger
gefunden hat, funktioniert das mal mehr, mal weniger gut.
> Der ehemalige Entwickler wird wohl nur soviel Kommentare in seinen> Quellcode geschrieben haben das er selber nach längerer Zeit alles> verstehen konnte - gezielte Fehlinformationen oder "leere"> Programmanteile im Quellcode um zu verhindern das ein Nachfolger das> Programm gut nachvollziehen kann wird es wohl leider auch im> professionellen Umfeld geben.
Im Idealfall gibt es nicht nur einen, der sich mit der Software
auskennt.
Die Erfahrung zeigt, dass es auch für den Mitarbeiter von Nachteil ist,
wenn er der einzige ist. Kann ja auch mal sein, dass was dringendes
anfällt, wenn derjenige eigentlich Urlaub hat oder einfach schon mit
anderen genauso dringenden Themen ausgelastet ist. Dann kann man
entweder sagen: "ist mir egal" und dann schuld dran sein, dass es nicht
funktioniert und der Kunde Terror macht, oder man hat viel zusätzlichen
Stress.
Rolf Magnus schrieb:> Im Idealfall gibt es nicht nur einen, der sich mit der Software> auskennt.
Die Realität ist einer der erbittertsten Feinde des Idealfalls.
es wird versucht mit agilen methoden ein wenig entgegen zu wirken,
Code reviews mit wechselnden reviewern, wechselnde tasks,
klar klappt das nicht immer in der realität :)
ich bin schon für ein Objektorientiertes Programm mit zumindest einer
sehr groben erkennbaren Struktur dankbar.
<zitat vieler entwickler (mich eingeschlossen)>
Doku? was ist das? der code dokumentiert sich doch selbst :)
</zitat>
Ich hatte einen Fall, wo der ehemalige Entwickler eine komplexe Firmware
in Assembler erstellt hat und dann die Firma verlassen. Angeblich war
Assembler nötig, da man die Firmware in einem Atmega128 nicht anders
unterbringen könnte. Als Neuling in der Fa. sollte ich diese ausbauen
und pflegen. Schön dass ich blöderweise im Studium ebenfalls Assembler
hatte und das in meiner Bewerbung erwähnt habe...Nach einer Woche
Befehlssalat ging ich zum Chef und habe vorgeschlagen die gesamte Fa.
umzucoden und zwar in C. Mein Argument war: entweder 4 Monate
Einarbeitungszeit in die aktuelle Fw. oder in 3 Monaten hat er die
Firmware in C, die sich weiterhin pflegen lässt. Gesagt getan. Die
komplette Firmware hat wegen vielen SCPI Strings gerade Mal 60% des
Flashs verbraucht.
♪Geist schrieb:> in 3 Monaten hat er die> Firmware in C
Wenn das geklappt hat, Gratulation.
Das kann auch böse nach hinten losgehen.
Eine bestehende Firmware neu zu schreiben ist ein Risiko. Der
ursprüngliche Entwickler hat oft Probleme gelöst an die man selber
garnicht denkt. Viele Probleme treten auch erst während des Betriebs
auf.
Nach 3 Monaten gibt es dann zwar eine SW, diese muss aber dann weitere
Wochen/Monate weiterbearbeitet werden bis sie so zuverlässig läuft wie
die alte.
Grade die Absolventen unterschätzen solche Aufwände oft massiv. Weil "da
muss man ja nur..."
Nochmal, wenn das bei dir geklappt hat, Glück gehabt, und Gratulation.
♪Geist schrieb:> ein Argument war: entweder 4 Monate> Einarbeitungszeit in die aktuelle Fw. oder in 3 Monaten hat er die> Firmware in C, die sich weiterhin pflegen lässt.
Lass das nicht den Moby lesen. Oder war es gar Moby (oder ein geistig
Nahverwandter) der diese Firmware verbrochen hat?
Hallo,
das mit dem dokumenterien ist überall ein Problem.
Ausnahmen sind natürlich sicherheitskritische Bereiche.
Auch kann man nicht immer die Kollegen dazu zu überreden ausreichend zu
dokumentieren, oder aber die Dokumentation ist irgendwann veraltet.
Dann muss der Chef oder Abteilungsleiter schon direkt dahinter stehen
und die Leute zwingen.
Aber wir haben gute Erfahrung damit gemacht, dass es eine
Bug&Feature-Liste gibt (ob manuell, oder im Bugtracker ist egal) mit
einer Bug-ID und einer kurzen Beschreibung. Im Quellcode ist dann an den
jeweiligen Stellen ein Kommentar mit der Bug-ID im Kommentar. Wenn dann
noch mit einem Versionierungs-Tool gearbeitet wird, kann man
zumindestens nachvollziehen warum bestimmte Dinge geändert wurden.
Genau, die oben genannten Besonderheiten in der History sind bei einer
Neuprogrammierung häufig nicht vorhanden. Einige treten vielleicht nicht
auf, werden nicht mehr benötigt, etc. Aber bei manchen Features fällt es
es viel Später auf, was nicht berücksichtigt wurde.
In unseren VHDL Modulen soll jeder Entwickler anstatt zu dokumentieren,
zumindestens eine vernünftige Testbench mit aussagekräftigen Wave-Files
ablegen. Das hilft ganz gut beim Verstehen des Moduls, und falls man was
geändert hat, kann man dagegen simulieren. Ist meiner Meinung fast
besser als eine Dokumentation bzw. viele (sinnlose) Kommentare im VHDL
Code.
Macht leider aber auch nicht jeder Entwickler.
In der Software-Entwicklung setzt sich das mit dem
Test-driven-devolopment leider noch nicht durch.
Sebastian schrieb:> ei Großkonzernen und Sicherheitskritischen Bereichen arbeiten gibt es> sicherlich SystemeSebastian schrieb:> Wie ist das aber bei der kleinen "Entwicklungsbude"
So schwarz-weiss kann man das nicht sehen. Was wie lange entwickelt und
gepflegt wird ist ja vorwiegend eine wirtschaftliche Frage, und da
entscheiden Grosskonzerne genauso oder eher noch rücksichtsloser, was
aufgegeben wird. Ich habe hier bei Kollegen miterlebt, wie für einen
Millionenbetrag CAD-Software von HP neu angeschafft wurde, die 6 Monate
später abgekündigt und eingestellt wurde - da sagt der Schwabe halt Pech
kett. Entgegen anderslautenden Gerüchten gibt es auch keine gesetzlichen
Verpflichtungen, Ersatzteile eine bestimmte Zeit lang zu liefern oder
Reparaturen durchzuführen, die über die Gewährleistung hinausgehen. Man
kann auch über mögliche zukünftige Entwicklungen keine vernünftigen
Verträge abschliessen. Wenn Ubuntu sagt, 14.04 LTS wird länger gepflegt,
ist das rein freiwillig, es dürfte auch schwierig sein, das einzuklagen.
Bei kundenspezifischen Projekten kann man sich bei Kleinfirmen oft
absichern, indem z.B. der Sourcecode hinterlegt wird und im Fall einer
Insolvenz oder aus anderen Gründen dem Kunden zugänglich wird. Auf so
etwas würde sich eine Firma wie Siemens nie einlassen.
Dass erhebliche Kosten durch die Einarbeitung anderer Mitarbeiter
entstehen ist aber einfach unvermeidlich. Dass es auch Programmierer
gibt, die ihren Code so weit wie möglich verschleiern, ist auch nicht zu
bestreiten, aber sowas darf der Chef niemals zulassen, schon im eigenen
Interesse.
Georg
Georg schrieb:> Dass es auch Programmierer> gibt, die ihren Code so weit wie möglich verschleiern, ist auch nicht zu> bestreiten
Das liest man ja öfter hier (sich wichtig machen in dem Code nicht
dokumentiert oder verkompliziert wird).
Allerdings, kennt da jemand wirklich ein Beispiel aus der Praxis?
Irgendwie wüsst ich nicht wie ich hier (oder in den Firmen die ich sonst
kenn) solch fragwürdigen Code durch die Reviews kriegen will...
Wir hatten mal so einen Entwickler.
Hat alles in eine einzige Datei gepackt weil er der Meinung war das wäre
übersichtlicher. Auch seine Variablennamen waren mehr durchnummeriert
als hatten sie Namen.
Ob das Absicht war, oder einfach nur Unwissenheit. Er ist dann auch
schnell gegangen und ich war dann der Dumme der die Problem dann beim
Kunden ausbaden durfte.
Franz schrieb:> wie ich hier (oder in den Firmen die ich sonst> kenn) solch fragwürdigen Code durch die Reviews kriegen will...
Erfahrungen mit solchen Programmierern sind ja der Grund, warum solche
Reviews eingeführt wurden. Deswegen sind die auch vom Aussterben
bedroht, in der guten alten Zeit waren sie jedenfalls viel häufiger. Oft
verbunden mit langen Haaren, Jesuslatschen und selbstgewählten
Arbeitszeiten vom Spätnachmittag bis nach Mitternacht.
Georg
Franz schrieb:> Irgendwie wüsst ich nicht wie ich hier (oder in den Firmen die ich sonst> kenn) solch fragwürdigen Code durch die Reviews kriegen will...
ich denk das ist der Trick: in der Firma einen ordentlichen
Review-Prozess implementieren und dafür sorgen daß der auch wirklich für
alles verwendet wird und funktioniert.
Wenn eine Firma mit 1 oder 2 Mann anfängt geht das noch nicht. Wenn die
aber langsam wachsen dann wird es bald Zeit sowas einzuführen. Manche
erkennen die Notwendigkeit, andere nicht...
Es ist nicht immer der entwickler, der keine Doku machen will. es kann
auch der Verkauf sein, der Projekte als gemacht verkauft, die noch nicht
mal angefangen wurden. Weil ... es ist ja nur dieses Projekt plus dieses
Detail ...
Der Entwickler ist so immer unter Druck, moeglichst schnell etwas zu
liefern. Und wenn der Verkauf nicht eine satte Menge des Prototypen
verkaufen konnte, lohnt es sich auch nicht zuviel Aufwand in Doku zu
stecken. Wenn kein Folgeauftrag kommt, braucht's die Doku auch nicht...
.. und wenig spaeter, wenn alle alles vergessen haben beginnt das
Produkt zu laufen..
Gerd E. schrieb:> Wenn eine Firma mit 1 oder 2 Mann anfängt geht das noch nicht. Wenn die> aber langsam wachsen dann wird es bald Zeit sowas einzuführen. Manche> erkennen die Notwendigkeit, andere nicht...
Du schreibst von ziemlich reinen Softwarebuden. In der Realität bei
Maschinenbauern, Apparateherstellern, Energie, Automobil und Meßgeräte
sieht das völlig anders aus. Da ist Software für 99% der Firma eine Art
Nebenangelegenheit und völlig außerhalb jeglichen Interesses. Guck dich
mal auf der Hannovermesse um, da siehst du, worauf die Leute dieser
Sparten denn so Wert legen. Und vergiß nicht, die Jeans daheim zu lassen
und nen schwarzen Anzug zu tragen.
W.S.
Freddy schrieb:> Hat alles in eine einzige Datei gepackt weil er der Meinung war das wäre> übersichtlicher.
Ist es auch.
> Auch seine Variablennamen waren mehr durchnummeriert als hatten sie> Namen.
Nun, das vielleicht nicht.
Georg schrieb:> Wenn Ubuntu sagt, 14.04 LTS wird länger gepflegt,> ist das rein freiwillig, es dürfte auch schwierig sein, das einzuklagen.
Da kann man von Haus aus vermutlich gar nichts erfolgreich einklagen.
Wenn man einen Wartungsvertrag mit Canonical hat, und die stellen die
Wartung vertragswidrig ein, dann hätte man was in der Hand.
W.S. schrieb:> Du schreibst von ziemlich reinen Softwarebuden. In der Realität bei> Maschinenbauern, Apparateherstellern, Energie, Automobil und Meßgeräte> sieht das völlig anders aus. Da ist Software für 99% der Firma eine Art> Nebenangelegenheit und völlig außerhalb jeglichen Interesses.
Wer heutzutage Software als "Nebenangelegenheit" sieht, muss vor so
Dingen wie "Industrie 4.0" und der Konkurrenz ganz schön Angst haben und
sollte sich mit Hochgeschwindigkeit daran machen seinen Laden auf die
Höhe der Zeit zu bekommen.
Die Probelematik ist doch meistens die, dass immer wieder misachtet
wird, wiviel Arbeit die Dokumentation macht. Also macht man alles
zusammen, ein bischen proggen ein bischen was aufschreiben und ab und an
ändern. Das sieht immer schneller aus und ist am Ende langsamer, wenn
geändert werden muss.
Würde man Konzepte machen, alles sauber aufschreiben, wäre es am Ende
besser, stabiler und testbarer. Den Vorteil hätten aber andere
Abteilungen und andere, spätere Entwickler und das will keiner leisten
oder bezahlen, weil alle unter grossem Zeotdruck stehen.
Das ist ein Problem, dass man nie lösen wird können und das auch nich an
den Entwicklern liegt.
Entwickler müssten sich durchsetzen und knallhart nach Prozessen
arbeiten. Dann würde alles erstmal länger dauern und man hätte aber
einen Benefit davon.
Aber die die sich das trauen, werden als Querulaten abgetan, man
schreibt ihnen Trägheit vor und lagert das Ganze aus an eine schnelle
flexible Diesntleisterfirma.
Und die schmiert es dann wieder schnell hin. :D
PC-Verbinder schrieb:> Also macht man alles> zusammen, ein bischen proggen ein bischen was aufschreiben und ab und an> ändern. Das sieht immer schneller aus und ist am Ende langsamer, wenn> geändert werden muss.>> Würde man Konzepte machen, alles sauber aufschreiben, wäre es am Ende> besser, stabiler und testbarer.
Erst ein großes, tolles Konzept bis ins Detail zu machen, das genau zu
dokumentieren und dann erst umzusetzen funktioniert meist nicht. Denn
trotz des tollsten Konzepts hast Du immer irgendeinen Aspekt übersehen
oder falsch eingeschätzt. Und das erkennst Du erst, wenn Du es
tatsächlich umsetzt oder gar das erste Mal in der Praxis einsetzt. Oft
ändern sich auch die Anforderungen des Kunden oder der weiß eigentlich
noch gar nicht so genau was er braucht und erkennt erst beim Arbeiten
mit einem Prototypen was ihm fehlt.
Natürlich musst Du am Anfang ne grobe Idee haben wie das ganze aufgebaut
werden soll. Dann solltest Du aber möglichst schnell einen irgendwie
lauffähigen Prototypen hinbekommen um die Praxistauglichkeit zu
beweisen. Und den dann in weiteren Iterationen immer weiter verfeinern
und verbessern.
Die Dokumentation würde ich dabei während der Entwicklung machen und
möglichst im Code halten. Mit Tools wie Doxygen bekommt man daraus dann
eine Übersicht extrahiert. Soetwas wie eine High-Level-Doku kann man
dann zusätzlich z.B. in Markup oder so schreiben. Wichtig ist daß die
zusammen mit dem Code eingecheckt werden muss (daher nur textbasierte
Formate, sonst bekommt man keine brauchbaren Diffs) und Teil des
Review-Prozesses ist (Merge wird abgelehnt wenn Doku ungenügend).
Naja, der wichtigste Aspekt fehlt hier: Geld.
Es geht immer nur darum, was billiger ist bzw. was ein Kunde bereit ist
zu akzeptieren und was sich gerade noch möglichst teuer verkaufen lässt.
Industriesoftware muss nicht ewig halten, bzw. wenn die Maschine mal
läuft, wird die Software relativ selten geändert, und dann nur bei einem
Umbau der Hardware. Das ist auch der Grund warum auf vielen Maschinen
wirklich noch alter Mist läuft.
Zumindest war es in der Vergangenheit so. Mit der ganzen
Vernetzungsgeschichte ändert sich schon einiges und es wird sich noch
viel mehr verändern. Erste Unternehmen habe inzwischen ernsthafte
Probleme mit ihrem Softwaremüll, weitere werden folgen, und meiner
Meinung nach wird das in den kommenden 10 bis 15 Jahren eine ganz schöne
Marktbereinigung geben.
Gerd E. schrieb:> Die Dokumentation würde ich dabei während der Entwicklung machen und> möglichst im Code halten. Mit Tools wie Doxygen bekommt man daraus dann> eine Übersicht extrahiert.
Dies!
PC-Verbinder schrieb:> Die Probelematik ist doch meistens die, dass immer wieder misachtet> wird, wiviel Arbeit die Dokumentation macht.
Eigentlich gar keine.
Schau dir doch mal dein Handy oder Smartphone an.
Ausser einem Blatt auf dem steht wo man Ohrhörer und Ladekabel
einsteckt, hat es keine Dokumentation.
Es wird weder erklärt, wie man SMS mit T9 tippt und was in den
Wörterbüchern steckt, noch wird beim Smartphone irgendwas zur Software
erklärt.
Das war bei den allerersten Handys noch besser, da stand wenigstens drin
wie man die Menüs bedient, aber spätestens seit dem die Dinger WAP
konnten war die Dokumentation doch Essig.
Die Hersteller sagen zumindest gegenüber den Kunden: Dokumentation wird
überbewertet, ohne Doku geht auch.
Bei Waschmaschine, Laptop und Audioanlage ist es doch nicht besser.
Technische Daten fehlen inzwischen völlig, ausführliche
Bedienungserklärung jeden Bedienbefehls ebenfalls, und ein Handbuch wie
bei Windows 3.1, als noch jede Applikation erklärt wurde, findest du
schon lange nicht mehr. Im Internet findest du Anleitungen zwar
millionenfach, aber niemals die genau zu deiner Version passende.
Da ist es kein Wunder, wenn auch Sourcen als selbsterklärend bewertet
werden.
Michael Bertrandt schrieb:> Ausser einem Blatt auf dem steht wo man Ohrhörer und Ladekabel> einsteckt, hat es keine Dokumentation.>> Es wird weder erklärt, wie man SMS mit T9 tippt und was in den> Wörterbüchern steckt, noch wird beim Smartphone irgendwas zur Software> erklärt.>> Das war bei den allerersten Handys noch besser, da stand wenigstens drin> wie man die Menüs bedient, aber spätestens seit dem die Dinger WAP> konnten war die Dokumentation doch Essig.
Brauchts auch nicht. Die Dinger sind hinreichend einfach gehalten, man
könnte auch sagen "intuitiv zu bedienen". Bin ganz froh dass heutige
Konsumer-Elektronik nicht mehr solch rießige Papiermüllberge verursacht.
Das gilt auch für Stereo-Anlagen, Fernseher etc...
Und um gleich mal das Argument des älteren, weniger technikaffinen
Klientels zu entkräften: das Mütterlein, das einen heutigen Fernseher
nicht intuitiv ohne Anleitung programmieren kann würds mit Anleitung
auch nicht schaffen. Meist scheitert es am Willen.
Seitdem ich meinen Eltern nicht mehr jeden Mausklick vorkaue sondern sie
selbst denken lasse kommen die viel besser zurecht...
Michael Bertrandt schrieb:> und ein Handbuch wie> bei Windows 3.1, als noch jede Applikation erklärt wurde, findest du> schon lange nicht mehr.
Schon witzig dass du Win3.1 als Musterbeispiel heranziehst.
Wenn ich mich recht erinnere hatten die Programme die mitgeliefert
wurden (Paintbrush, Writepad, Dateimanager...) Anleitungen
(Hilfe-Dateien) in der Größenordnungen von 1-3 Bildschirmseiten.
Da stand dann sinngemäß:
OK - Klicken sie hier um zu bestätigen
Abbrechen - Klicken sie hier um abzubrechen
Datei Speichern - Klicken sie hier um zu speichern...
Völlig nutzlos, Doku um der Doku Willen. Hauptsache Papier erzeugt.
Ne du, früher war nicht besser. Nur anders.
On-Topic:
Doku macht Arbeit, ja. Meist wird die Doku auf später verschoben, aber
später steht ja schon das nächste Projekt an.
Aussagekräftige Kommentare kann der Entwickler noch relativ einfach
einstreuen (ganz wichtig: das "wieso" beschreiben. Das "was" steht ja
schon im Code).
Den größten Nutzen, vor allem auf einem abstrakteren Standpunkt auf
Systemebene bieten Diagramme.
Flussdiagramme, Klassendiagramme, State-Machines usw.
Auch wenn bunte Bilder verpönt sind und den Opis oft das Grauen bei
"Buzzwords" wie UML kommt: der Mensch erfasst komplexe Sachverhalte
immer noch am Besten visuell. Auch lässt sich in Bildform eine Unmenge
an Informationen auf wenig Raum darstellen.
Aber das macht eben extra Arbeit (Tools besorgen, erlernen, Doku
anlegen, pflegen...).
Und natürlich muss diese Doku auch aktuell gehalten werden. Da
scheiterts oft.
Hannes Jaeger schrieb:> Das ist der sogenannte Heldenansatz> Alternativ wird Wegwerfsoftware erstellt> die> Fahrerflucht bzw. Verbrannte Erde> noch das "drive by shooting"
Einfach wunderbar! Ich finde, du hast die gesamte Problematik richtig
gut auf den Punkt gebracht.
