Zitat:
Mit kleienere Progrämmchen klappt, das solange, wie sie kein anderer verstehen muss und man zumindest ungefähr weis, was wann wo und wie passiert. Aber wenn ein anderer kann sehr warscheinlich nicht viel mit deinen guten namen anfangen, denn er hat für sich andere gute namen.
hmm .. ja .. solche Diskussionen die unterschwellig darum gehen, "meiner ist größer" mag ich überhaupt nicht.
Also ich arbeite nicht an kleinen Projekten sondern seitdem ich angefangen habe zu Programmieren an einem einzigen großen Projekt.
Ätsch, meiner ist Größer
Und ich sehe immer noch durch ! versprochen !
Das Buch "Code Complete" gibt sehr gute Hinweise zur Gestaltung von Quelltext.
Ich kann Dir nur sagen, dass ich, nachdem ich meinen Quellcode in
UML angeschaut habe, überhaupt nix mehr verstanden habe
Vielleicht sollte man in Erwägung ziehen, dass es auch am Lerntyp liegen könnte ( auditiv, visuell, kommunikativ, motorisch)
Und deswegen von Mensch zu Mensch unterschiedlich.
http://www.philognosie.net/index.php...ticleview/163/
Teamerfahrungen hab ich keine, das ist wohl wahr. Aber darum ging es dem Hilfesuchenden ja auch gar nicht.
Ich kann Dir also nicht sagen, ob mit meinem Quelltext jemand anderes zurecht kommen würde
Ich denke dann sollte
UML nur ein ZUSATZ sein. Wie eine Bedienungsanleitung. Seinen eigenen Quelltext sollte man auch ohne Bedienungsanleitung verstehen können !
Beim Autofahren macht sich das auch besser, wenn man alles ohne Bedienungsanleitung im Griff hat
Und wenn ich nach einem halben Jahr wirklich nicht mehr wußte, welcher Quelltext was genau macht, (vor allen Dingen welcher Teil macht das was ich suche und wo finde ich die
Unit) habe ich in kurzer zeit durch aufrufe und "Deklaration suchen" zu meinem Ziel gefunden. Dafür braucht man natürlich eine
IDE.
Zitat:
Eine einfache und gute Doku über die Zusammenhänge der implementierten Klassen, Objecte, Methoden ... würde sicher helfen.
ein sinngemäßes Zitat aus dem "Code Complete" Buch.
Dokumentiere nicht das WIE und WAS sondern das WARUM.
Warum Du etwas getan hast und wieso Du dieses oder jenes so gelöst hast und warum nicht anders.
Ich bin der Meinung, für Delphi mit seinem Interface und Implementation Konzept in Units braucht man nur bedingt ein kompliziertes
UML Werk.
Der Interfaceteil ist ja schon eine gute Zusammenfassung der Klassen, properties und Methoden. Und wenn dort noch bischen Text steht sollte man alles verstehen.
In anderen Programmiersprachen gilt das natürlich nicht.
Eine grobe Skizze sollte in meinen Augen viel nützlicher sein als von einem Programm generiertes
UML Diagramm. (Anders sieht es wahrscheinlich aus, wenn man zuerst das
UML Diagramm als Architektur entwirft und danach ausprogrammiert)
Und was ich noch gemerkt habe. // Lieber mal eine Erklärung zu viel, als zu wenig..... schreiben, schreiben, schreiben