Umfrage

Re: Umfrage

ewx hat geschrieben:Ärgert ihr euch häufiger über bestimmte "Programmierunarten" oder schlechte Umsetzungen bei Programmen, die ihr korrigieren oder warten müsste? Wenn ja, welche sind das?

Ein paar Dinge wurden ja schon genannt.

Ich liebe so etwas wie Also Konstanten ohne Bezug auf einen DDIC-Typ o.ä. und mit einem Namen, der nichts über die Bedeutung verrät, und dann die gleiche Konstante für verschiedene. voneinander unabhängige Dinge verwenden, z.B. die Konstante 1234 einmal für eine Bewegungsart, einmal für BUKRS o.ä.

Gern gesehen auch: Massenhaft globale Variablen, die dann irgendwo in Unterroutinen geändert werden oder innerhalb einer Routine als Parameter an andere Routinen übergeben werden, die dann den Parameter, der natürlich anders heißt als die globale Variable, ändern.

Auch genial:
EIne globale Variable an eine FORM übergeben, in der Form dann abwechselnd den Namen des FORM-Parameters und den Namen der globalen Vairablen verwenden.

Kopieren von SAP-Standard-Programmen und an den Kopien dann Anpassungen vornehmen, weil Modifikationen ja böse sind.
Dass nach 3 Jahren, einem Releasewechsel und etlichen eingebauten SAP-Hinweisen kein Mensch mehr weiß, welche im SAP-Standard schon lange behobenen Fehler in der Kopie noch enthalten sind, ist ja egal.
Ebenso, dass man dann nur noch mit "Grundlagenforschung" herausfindet, welche Abweichungen denn nun durch die Kundenanforderung bedingt sind und welche durch Änderung am SAP-Standard entstanden sind.
(Das Original hat natürlich damals niemand mit in denTransportauftrag aufgenommen, so dass es für das SAP-Original auch keinen Eintrag in der Versionshistorie gibt, der den Zustand des Originals zu dem Zeitpunkt dokumentier,t als die Kopie erstellt wurde.)
Und natürlich kopiert man am besten auch gleich alle Includes des Rahmenprogramms mit, auch wenn man an denen gar keine Änderungen vornehmen möchte.

Ganz toll auch diejenigen, die an irgendwelchen Programmen rumbasteln, dann das im Transportauftrag gesperrte Objekt aus dem Auftrag löschen und die unerwünschten Abweichungen zwischen Entwicklungs- und Produktivsystem sozusagen als Stolperstein für den nächsten, der das Objekt anfassen muss, liegen lassen.

Es ist auch eine ganz tolle Idee, im Entwicklungs- und/oder Testsystem mit SAP_ALL zu testen, um sich dann überraschen zu lassen, wie sich fehlende Berechtigungen im Produktivsystem auswirken.
Im besten Fall eine Fehlermeldung.
Im schlimmsten Fall ein Datenverlust, der erst Tage oder Wochen später bemerkt wird.

Ganz toll finde ich auch direkte Updates auf SAP-Standard-Tabellen aus Kundenprogrammen heraus.
Selbst wenn man alle die Konsistenz-Prüfungen, die der SAP-Standard vornimmt, auch in seinem Programm implementiert hat:
-Wer sagt, dass nicht mit dem nächsten SAP-Hinweis im Standard weitere/andere Prüfungen vorkommen?
-Wer denkt bei so etwas schon daran, vor dem Lesen des zu ändernden Objekts den passenden ENQUE-Funktionsbaustein aufzurufen?
-Und wozu Änderungsbelege schreiben, selbst wenn es zu der Tabelle, die geändert wird, ein Änderungsbelegobjekt gibt

Bestimmt fallen mir mit etwas Nachdenken noch weitere Dinge ein.

Frank

Re: Umfrage

Was ich auch bei anderen Entwicklern eher selten finde, mir aber zur Angewohnheit gemacht habe:

Bei Programmen, die im Hintergrund laufen sollen und die (zumindest mit produktionsnahem Datenvolumen) eine nicht zu vernachlässigende Laufzeit haben, sorge ich dafür, dass im Joblog ein paar Informationen landen, die den Fortschritt dokumentieren und die Ursachenforschung erleichtern, wenn irgendwann mal ein Job länger als üblich läuft.
Minimalanforderungen also:
-S-Message nach wichtigen Zwischenschritten, damit erkennbar ist, welcher Teilschritt wie lange dauert.
-ein paar Hintergrund-Infos dazu, wie viele Objekte (Darlehen, FI-Belege, Geschäftspartner, was auch immer) verarbeitet werden

Damit man diese Informationen schon hat, während der Job-Step noch läuft, mache ich es oft so: Dann muss man nicht auf Programmende oder -abbruch oder ein COMMIT WORK am Ende der Verarbeitung warten, um zu sehen, was los ist.
(Natürlich muss man dabei aufpassen, kein DB-Commit inmitten von DB-Änderungen auszulösen, die nur zusammen oder gar nicht committed werden dürfen.)

Je nach Komplexität kommen manchmal optional noch weitere statistische Informationen hinzu.
Zum Beispiel (wenn die Daten paketweise verarbeitet werden): wie lange (min./max./Durchschnitt/...) die Verarbeitung eines Pakets dauert.
Wenn man dann noch die Paketgröße (z.B. im Selektionsbild) einstellen kann und Von-Bis-Intervalle oder zumindest die Nummer des letzten in jedem Paket verarbeiteten Objekts im Joblog ausgibt, kann man auch schnell herausfinden, für welches Objekt eine Verarbeitung besonders lange dauert, und dann gezielt prüfen, warum das so ist.

Apropos paketweise Verarbeitung: Schon erstaunlich, wie viele Programme man so findet, die z.B. 2 GB an Daten aus einer SAP-Tabelle komplett in den Hauptspeicher lesen und dann damit arbeiten.
Und dann sich darüber wundern, dass das System nur noch mit Paging beschäftigt ist oder die Jobs abbrechen, weil die anderen zur gleichen Zeit laufenden Programme das genau so machen.

Frank

Re: Umfrage

ralf.wenzel hat geschrieben:Leider hat dieser Kunde auch die Regel: Coding wird niemals gelöscht, sondern immer nur auskommentiert (mit Verweis auf das Ticket). Zu welchen Codingwüsten das führt, kann sich jeder vorstellen. Stellt euch ein Programm vor, in dem ein Block von zehn Zeilen auskommentiert und darunter komplett anders geschrieben wurde, dann sind in diesem Block zwei Zeilen eingefügt und noch später drei andere gelöscht worden.

Deswegen habe ich mich bei dem Wunsch von Alexander D.

für uns wird in naher Zukunft das Thema "Programmierrichtlinie für ABAP" interessant. Zur Zeit gibt es bei uns keine Vorgaben, dementsprechend sehen auch unsere Programme aus.

auch etwas mit Kommentaren zurückgehalten.

Es ist traurig, dass es selbst 2012 neu eingeführte Entwicklungs-Richtlinien gibt, die so einen Unsinn vorschreiben.
Solche Entwicklungsrichtlinien kommen entweder von Leuten, die nicht selbst entwickeln müssen, oder von Leuten, die nicht wissen, was sie tun.

Bisher bin ich von solchem Unfug verschont geblieben. Wenn ich so etwas wirklich nicht verhindern kann, wäre ein Tool, das die Schmerzen für mich ertragbar macht, das erste, was ich entwickeln würde.
Also einen Editor, der alle diese Unsinns-Kommentare irgendwo zwischenparkt und dann entsorgt (wegen der in solchen Fällen garantiert auch definierten formalen Anforderungen an die Formatierung eines solchen Kommentars sollten sie also relativ gut automatisch erkennbar sein) und beim Sichern bzw. erst, wenn die Korrektur freigegeben wird (wozu gibt es denn an der Stelle die Erweiterungsmöglichkeiten im SAP-Standard) die alten Kommentare wieder einfügt und entsprechend den Regeln meine eigenen ergänzt.
Mimimalvariante wäre vielleicht erst mal die Möglichkeit, den Quelltext ohne die Kommentare anzuzeigen und/oder auszudrucken, alles andere wird dann nach und nach aufgebohrt...

Was soll das, wenn ich auf meinem Bildschirm gar keinen Kontext mehr zu den Anweisungen sehe, die ich ändern will, weil alles mit sinnlosen Kommentaren zugepflastert ist? Die SAP-Versionshistorie ist ja schon sehr lange nicht mehr state of the art, aber dazu, in einer linearen Kette von Versionen zwei beliebige Versionen miteinander zu vergleichen, reicht sie locker aus.

Das Schlimme ist, dass man mit solchen Entwicklungs-Richtlinien dann extra Klimmzüge machen muss, um die Versionshistorie überhaupt noch halbwegs sinnvoll nutzen zu können (die Checkbox für "Kommentare ignorieren" muss dann schon mal zwangsweise markiert werden).

Vielleicht ist es ja auch einfacher, ein Programm zu schreiben, das aus einer nicht verkorksten Versionshistorie den Quelltext erzeugt, der entstanden wäre, wenn sich alle an die Richtlinien zum Auskommentieren alten Codes gehalten hätten...
Das kann man dann bei Bedarf demjenigen auf den Tisch legen, der es haben will.

Das bereits empfohlene Buch "ABAP-Programmierrichtlinien" http://www.sap-press.de/katalog/buecher ... telID-1922 halte ich auch für im Großen und Ganzen sehr brauchbar. Lediglich um das Thema "wie gehe ich mit Altlasten um" wird sich wie üblich gedrückt.

Frank

Re: Umfrage

Vielen Dank für Eure Anmerkungen!

Re: Umfrage

JHM hat geschrieben:

ralf.wenzel hat geschrieben:Das habe ich den zwei Dutzend Entwicklern bei einem Kunden mal um die Ohren gehauen.....Dieser Kunde hatte TOP-Includes, bei denen erstmal das ganze Alphabet "durchkonstantiert" wurde (gc_a, gc_b, ....) und dann die Ziffern 0-9 per Konstante festgelegt wurden.
...
Leider hat dieser Kunde auch die Regel: Coding wird niemals gelöscht, sondern immer nur auskommentiert (mit Verweis auf das Ticket).

Ich bin gerade in einem System unterwegs, welches 1998 von R2 nach R3 migriert wurde. Da gab es wohl auch eine Programmrichtline, das man möglichst viele sinnfreie Konstanten definiert.

Ich hielt das immer für ein Gerücht, dass Programmierer früher pro Codingzeile bezahlt wurden, so langsam denke ich, dass da was dran ist.

JHM hat geschrieben:Wobei ich mich mehr über die Vollpfosten aufrege, die dann in den folgenden Jahren diese Programme "gewartet" haben. Ich weiß nicht in wievielen Programmen ich mitlerweile vorbeigekommen bin wo man sowas im TOP-Include findet:

Code: Alles auswählen.

* CONSTANTS gc_x VALUE 'X'.   "T01xxxxxxx: wegen Umstellung xyz
CONSTANTS gc_x VALUE 'V'. 

So macht die Konstante dann richtig viel sinn.

YMMD, so einen Schwachsinn hab ich ja selbst noch nie gesehen LOL

Re: Umfrage

hehe. Da kann ich mich auch noch dran erinnern...

Re: Umfrage

black_adept hat geschrieben:Das Resultat war, dass wir neue Formroutinen nur noch möglichst kurz benennen konnten bzw. ältere Formroutinen in kürzer Benamte umbenannt hatten, um auch hier Buchstaben zu sparen.

Das SAP früher mal mit weniger Resourcen auskommen mußte ist ja ok. Aber auch kurze Namen können sprechend sein

Re: Umfrage

black_adept hat geschrieben:

JHM hat geschrieben:Das SAP früher mal mit weniger Resourcen auskommen mußte ist ja ok. Aber auch kurze Namen können sprechend sein

Versuch mal sprechende Namen für ein- oder zweibuchstabige Formroutinen zu finden. Hier können eigentlich nur sinnvolle Kommentare helfen.

Definitiv. Ich nenne meine Form_Routinen zum Beispiel GET_MARA und meistens kommentiere ich auch noch. Sicherheitshalber.

Meine Probleme bestehen meistens darin, daß wenn ich Vorschläge mache, daß die Leute nicht gewillt sind, etwas zu ändern. Sondern so auf der Basis, das haben wir schon immer so gemacht.