Grundsätzlich gilt bei der Anpassung von Standardkomponenten: Es wird kein Code gelöscht, sondern nur auskommentiert. Jedes eingefügte Codesegment wird als solches gekennzeichnet.
Oben im Kopf des Programmskriptes wird unterhalb der Standardkommentare angegeben, dass man eine Änderung vorgenommen hat, wann das war, was man gemacht hat, und warum. Für diese Änderung wird ein bestimmtes Kürzel angeben, mit dem die Änderungen im Programmskript gekennzeichnet sind. Für die nächste Änderung (sei es, aufgrund neuer Anforderungen, oder weil man zwei Tage später noch einen Fehler gefunden hat, wird ein neuer Kommentar im Kopf eröffnet und ein neues Kürzel vergeben.
Wie diese Kürzel auszusehen haben, dafür hat sich leider noch keine Konvention durchgesetzt. Infor nutzt hier Solution- oder Businessrequestnummern. Hat die eigene EDV ein ähnliches Prinzip, dass jede Softwareänderung in Bezug auf einen Eintrag in einem Change-Managementsystem stehen muss, kann man es ähnlich halten. Vorausgesetzt, man kann da tatsächlich mehrere Nummern generieren, wenn man mehrfach wegen einer Anforderung eine Source ändert. Ich persönlich bevorzuge es, für diesen Zweck meine Initialen und eine dreistellige Zählnummer zu nutzen (also: UF001, UF002, UF003 etc.) Nicht sehr praktikabel dagegen finde ich die Methode, mit Initialien und Datum zu arbeiten (UF080813), das wird zu lang, und bei zwei Änderungen an einem Tag hat man ein Problem.
Wofür es aber eine Konvention gibt, ist die Art, wie man dieses Kürzel zum Markieren seiner Änderungen im Skript benutzt. Diese Konvention wurde seinerzeit unter Baan eingeführt, wird bis heute zur Markierung von Änderungen aufgrund Solutions genutzt und sollte eigentlich allgemeiner Standard sein. Leider halten sich nicht alle dran, darum hier mal in aller Ausführlichkeit: Gesetzt den Fall, wir haben für unsere Änderung das Kürzel UF001 definiert. Dann kennzeichnet:
- UF001.o eine herausgelöschte, (das heißt auskommentierte!) Proogrammzeile. Das o steht für "out".
- UF001.n eine neue Programmzeile. Ein n für "new" also
- UF001.so den Beginn einer größeren Anzahl von Zeilen, die man herausgenommen hat (so für "start out")
- UF001.eo das Ende eines solchen Blocks (end out)
- UF001.sn den Beginn einer größeren Anzahl von Zeilen, die man eingefügt hat (sn für "start new")
- UF001.en das Ende eines solchen Blocks (end out)
Möchte man also in folgendem Code...
|*
|* This would be the last part of the Infor standard comment
|* section on top of the script
|*
|*************************************************************
...
select tcibd001.*
from tcibd001
where tcibd001._index1 inrange {:item.f} and {:item.t}
and tcibd001.csel >= {:csel.f}
and tcibd001.csel <= {:csel.t}
and tcibd001.citg >= {:citg.f}
and tcibd001.citg <= {:citg.t}
order by tcibd001._index1
selectdo
call.a.funny.method (tcibd001.item)
endselect
|*
|* This would be the last part of the Infor standard comment
|* section on top of the script
|*
|*************************************************************
|*
|* UF001 - 2008-08-13,
|* Ulrich Fuchs, Büro für Informationsarchitekturen, mail@ulrich-fuchs.de
|* * Zusätzliche Artikelselektion statt über Selektionscode
|* und Artikelgruppe über Signalcode
|* * eine andere Lustige Funktion gerufen
|*
|*************************************************************
...
select tcibd001.*
from tcibd001
where tcibd001._index1 inrange {:item.f} and {:item.t}
|UF001.so
| and tcibd001.csel >= {:csel.f}
| and tcibd001.csel <= {:csel.t}
| and tcibd001.citg >= {:citg.f}
| and tcibd001.citg <= {:citg.t}
|UF001.so
|UF001.sn
and tcibd001.csig >= {:csig.f}
and tcibd001.csig <= {:csig.t}
|UF001.en
order by tcibd001._index1
selectdo
| call.a.funny.method (tcibd001.item) | UF001.o
call.another.funny.method (tcibd001.item) | UF001.n
endselect
...
selectdo
call.another.funny.method (tcibd001.item) | UF001
endselect
Das ist böse, gemein, unwartbar. Nicht tun, bitte.
Posts
