Technische (!) Dokumentation von Changes

Technische (!) Dokumentation von Changes

Moin moin,

ich beschäftige mich gerade intensiv mit der Frage, wie man eine technische Dokumentation von Changes und anderen Entwicklungsaufträgen am besten realisiert. Ich kenne inzwischen mehrere Varianten - vom "Missbrauch" des Codings als Versionshistorie ("es darf keine Zeile entfernt werden"), was zur faktischen Unlesbarkeit von altem Coding führt über "wir dokumentieren nicht, dafür haben wir keine Zeit" über "wir führen in Word-Dokumenten Dokumentationen zur technischen Umsetzung, ohne vorhandene Doku wird kein Change zum Transport freigegeben".

Frage daher: Wie macht ihr das? Wo und wie dokumentiert ihr, wo ihr welche Änderungen warum durchgeführt habt?

Re: Technische (!) Dokumentation von Changes

Hallo Ralf,

ich halte das meist wie folgt ( wenn es keine anderen Richtlinien gibt ).

1.) Programme für die ich als hauptsächlicher Ansprechpartner gesehen werde:( Dann, wenn man auf mich zukommt und fragt, wenn Änderungen am Coding (von anderen) gemacht werden sollen)
- Bei echten Fehlerkorrekturen oder simplen Erweiterungen ( weitere Felder werden benötigt, eine neue Navigation irgendwo ): Ändern mit minimalen Kommentaren( bei simplen Fehlerkorrekturen evtl. auch gar nicht ) ( aber meist das alte Coding nur auskommentieren )
- Größere Changes, die an diversen Programmteilen Änderungen nötig machen: Irgendwo zentral im Programm (üblicherweise Kopf) werden die wesentlichen Änderungen in Prosa festgehalten und dann an den angepassten Stellen wird ein Hinweis auf den zentralen Prosatext gesetzt ( häufig kodiert mit der Transportauftragsnummer oder Ticketnummer wo so etwas im Einsatz ist ).
- Funktionale Änderungen an recht eingrenzbaren Stellen des Programms: Kommentar an dieser Stelle inkl. des Grundes für die Änderung. ( Meist auch Transportauftragsnummer oder Ticketnummer )

2.) Programme, an denen ich rumfummeln soll, aber die üblicherweise von jemand anderem betreut werden:
- Bei echten Fehlerkorrekturen oder simplen Erweiterungen ( weitere Felder werden benötigt, eine neue Navigation irgendwo ): Ändern inkl. eines Kommentars an der Stelle wo die Änderung passiert ( meist das alte Coding nur auskommentieren )
- Größere Changes, die an diversen Programmteilen Änderungen nötig machen: siehe 1.) Zusätzlich evtl. Hinweise auf Mailverkehr o.ä. an den "Hauptbetreuer" des Programms.
- Funktionale Änderungen an recht eingrenzbaren Stellen des Programms: siehe 1.) Zusätzlich evtl. Hinweise auf Mailverkehr o.ä. an den "Hauptbetreuer" des Programms.



Und noch ein Zusatz zu 1.) Wenn sich im Laufe der Jahre zu viele Änderungen angesammelt haben und das von dir angesprochene "Unlesbarkeitsproblem wg. zu vieler alter Kommentarzeilen" beginnt sich zu zeigen:
Sobald dann in einer solch problematischen Routine eine neue Änderung gemacht wird in so einer Routine eine Bereinigung durchführen, bevor ich die aktuelle Änderung durchführe:
1.1) Altes Coding von allen alten auskommentierten Stellen befreien
1.2) Kommentar einfügen, dass man eine große Säuberungsaktion gestartet hat inkl. Hinweis mit welchem Transport das geschehen ist (damit man das in der Versionshistorie leichter findet )
optional 1.3) In einem Einzeltransport das de facto gleichgebliebene aber schlankere Coding transportieren
1.4) Weiter bei 1.)

Im Fall 2.) gehe ich ähnlich vor - aber da beschränkt sich die Aufräumarbeit darauf den Hauptverantwortlichen zu suchen und ihm eine Aufräumaktion nahe zu legen.

Re: Technische (!) Dokumentation von Changes

Evtl. könnte dieses hier einen Blick Wert sein:
http://www.saltapps.com/version-vault.html