Quality Management - Programmierrichtlinien


Alles Rund um SAP®.

Moderatoren: Jan, Steff, SRMler

Quality Management - Programmierrichtlinien

Beitragvon SaskuAc » 02.08.2017, 14:43

Hallo,

ich habe vor 2 Wochen die Anforderung bekommen, dass ich bei uns den SCI ( Code Inspector ) in Verbindung mit ATC ( ABAP Test Cockpit ) einrichten und anschließend auch betreuen soll.
Bisher habe ich reine ABAP Programmierung gemacht und bin der Meinung, dass ich dort auch recht fit bin!

Jetzt war meine Frage, ob es etwas in die Richtung "Quality Manager" gibt?
Es soll nämlich auch so sein, dass unser Solution Manager System die Prüfungen macht und dann gegebenenfalls weiter transportiert oder eben den Transport blockt. Und da dass dann für all unsere Systeme ( BW, FI/CO/PP, HCM ) gilt war ich am überlegen, ob es sich einerseits lohnt dort eine Art neue Stelle für sowas einzurichten ( bzw. es meinem Vorgesetzten vorschlagen, dass der das dann macht ^^ )

Meint ihr es lohnt sich auch Zeitmäßig so eine Art "QM" aufzubauen oder ist das eher sinnlos?

Danke euch.
Gruß
SaskuAc
ForumUser
 
Beiträge: 95
Registriert: 01.06.2015, 10:16
Dank erhalten: 2 mal
Ich bin: Entwickler/in

Sponsor

Alte ABAP-Entwicklerweisheit: Weißt du weder aus noch ein, baust du einen BADI ein

Re: Quality Management - Programmierrichtlinien

Beitragvon ralf.wenzel » 02.08.2017, 16:07

Ich bin ein Hardliner in diesem Thema. Ein QM ist absolut unverzichtbar, wobei im SCI in meinen Augen die Ungarische Notation einen enormen Stellenwert hat. Was ich davon halte, ist bekannt. Man kann QM auch nicht immer automatisieren, denn sowas wie "sprechende und einheitliche (!) Objekt-, Methoden- und Variablennamen" kann eine Automatik nicht erfassen. Es braucht also einen Codingverantwortlichen, der für die Codingqualität verantwortlich zeichnet. Der nimmt jedes Coding ab und sollte z. B. erkennen "das haben wir schon wo" oder "das brauchen wir noch öfters" und das Coding zurückweisen mit der Anweisung "Serviceklasse schreiben". Keine Doku? Geht nicht produktiv. Unter gar keinen Umständen!

Wie sagte ich bei einem langjährigen Kunden immer wieder? "Wenn ihr eure XXX* so bauen würdet wie eure IT ihr Produkt baut, wäre der Laden hier längst pleite!" (*Produktname aus Anonymisierungsgründen entfernt). Ich kann keinen Grund erkennen, warum ein SAP-Coding niedrigeren Qualitätsansprüchen genügen sollte als z. B. ein Schaltschrank. Da gibt es auch feste Regeln und Pläne und der Elektroniker (das habe ich zufällig mal gelernt!) sagt auch nicht "im Plan steht rotes Kabel, das ist aus und müsste ich aus dem Lager holen -- nehme ich halt blaues, geht viel schneller". Das wäre indiskutabel!!!


Ralf
Bild Ralf WenzelHeuristika
SAP-Development • Datenschutzberatung
PublikationenUngarische NotationXing
ralf.wenzel
Top Expert
 
Beiträge: 2679
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 122 mal
Ich bin: Freiberufler/in

Re: Quality Management - Programmierrichtlinien

Beitragvon SaskuAc » 03.08.2017, 08:15

Ich finde die Einstellung gut!
Leider müssen wir die nächsten 10 Jahre die Ungarische Notation noch durchlassen, bin selber auch kein Fan davon.
Ich habe im SCI es tatsächlich soweit hinbekommen, dass bei der UN eine Warnung erscheint, blockieren kommt später.

Aber du hast recht, man kann nicht alles automatisieren, man kann es aber soweit es geht versuchen! z. B. Dokumentation. Wir haben eine Schnittstelle, die uns einerseits die Doku im SAP System direkt liefert und die Dokumentation die wir im Sol-Man anhängen. Erst wenn beides vorhanden ist ( und die SAP Doku gewisse Bereiche abdeckt ) wird der Transport durchgelassen. ( zumindest ist das der Plan ) Oder halt andere Themen, die man leichter automatisieren kann ( Übersetzungen - prüfen ob eine vorhanden ist --> alle Übersetzungen zu manuell zu prüfen würde gar nicht gehen ... sonst müsste ich 3 Sprachen zusätzlich zu deutsch und englisch sprechen ( im HCM Bereich reicht es bei uns, wenn ich den namen des programms nehme und daraus dann das land und die jeweilige übersetzung lese ) - oder kommentare prüfen ob sie englisch sind oder eben nicht ( vorgabe ist natürlich englisch ) ) USW

Und du hast mit deinem Beispiel vollkommen recht. Sowas wäre indiskutabel. Ich bin halt der Meinung dass wir uns viel Zeit und Geld sparen könnten, wenn man den Standard kennen und nutzen würde. Z. B. Hat eine Berater Firma bei uns einen RFC-FuBa gebaut, der aber im Prinzip genauso im Standard schon als Bapi existiert. ( Bloß, dass der Bapi mehr informationen zurück liefert )


Dann hoffe ich mal, dass ich meinen Chef da überzeugen kann, dass man so eine Stelle einrichten kann :)
SaskuAc
ForumUser
 
Beiträge: 95
Registriert: 01.06.2015, 10:16
Dank erhalten: 2 mal
Ich bin: Entwickler/in

Re: Quality Management - Programmierrichtlinien

Beitragvon ralf.wenzel » 03.08.2017, 09:57

SaskuAc hat geschrieben:Ich finde die Einstellung gut!
Leider müssen wir die nächsten 10 Jahre die Ungarische Notation noch durchlassen


Warum? Wer was anfasst, macht die UN raus, das dauert ja nicht lang.


Ralf
Bild Ralf WenzelHeuristika
SAP-Development • Datenschutzberatung
PublikationenUngarische NotationXing
ralf.wenzel
Top Expert
 
Beiträge: 2679
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 122 mal
Ich bin: Freiberufler/in

Re: Quality Management - Programmierrichtlinien

Beitragvon black_adept » 03.08.2017, 13:38

ralf.wenzel hat geschrieben:Warum? Wer was anfasst, macht die UN raus, das dauert ja nicht lang
Unnötiger Aufwand, da "Keine Variablennamensregeln" eine Obermenge von HN ist.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de
black_adept
Top Expert
 
Beiträge: 2725
Registriert: 08.01.2003, 13:33
Wohnort: Lehrte ( bei Hannover )
Dank erhalten: 397 mal
Ich bin: Freiberufler/in

Re: Quality Management - Programmierrichtlinien

Beitragvon ralf.wenzel » 03.08.2017, 14:34

Wer spricht von "keine Regeln"? Ich nicht.

Edit: Eine Änderung von lt_ekko in purch_order_headers (wenn es denn Bestellungen sind) ist kein Zeichen von Regelfreiheit. Die Entfernung eines g-Präfixes (das fachlich falsch ist, weil es keine globalen Daten im SAP gibt) auch nicht.


Ralf
Bild Ralf WenzelHeuristika
SAP-Development • Datenschutzberatung
PublikationenUngarische NotationXing
ralf.wenzel
Top Expert
 
Beiträge: 2679
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 122 mal
Ich bin: Freiberufler/in

Re: Quality Management - Programmierrichtlinien

Beitragvon black_adept » 03.08.2017, 17:08

Naja - Ansichtssache.
1.) Wenn es schon lt_purch_order_headers heißt wüsste ich nicht was das Weglassen des "lt_" jetzt an Klarheit bringen sollte. Da es eine hinreichend große Anhängerschaft der HN gibt hilft der lange Name allen Fraktionen - bis auf die HN-Hasser.
2.) Und ganz speziell hier: Wenn ich eine Tabelle habe die ein paar vollsttändige EKKO-Zeilen beherbergt halte ich lt_ekko für einen sehr guten Namen - auch wenn es sich um Bestellköpfe handelt. Denn gerade wenn du mal einen nicht ganz so trivialen Fall nimmst - wie müssten denn nach deiner Logik Tabellen wie lt_vbak oder lt_afko genannt werden?
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de
black_adept
Top Expert
 
Beiträge: 2725
Registriert: 08.01.2003, 13:33
Wohnort: Lehrte ( bei Hannover )
Dank erhalten: 397 mal
Ich bin: Freiberufler/in

Re: Quality Management - Programmierrichtlinien

Beitragvon ralf.wenzel » 03.08.2017, 17:27

Ich habe gerade ein Projekt, bei dem die Benamung von Variablen total inkonsistent ist, weil man ständig an Längengrenzen stößt. Außerdem: Da es keine globalen Daten im SAP gibt, ist das l schon Quatsch. Sonst müsstest du bei einer Variable auch davorschreiben, dass es sich um eine Variable handelt.

EKKO-Zeilen können alles mögliche sein. Rahmenverträge, Bestellungen, etc. Nach irgendeinem Kriterium werden die ja wohl in die interne Tabelle geschrieben worden sein - und genau das gehört in den Namen. Dann weiß ich auch, was drin ist. Will ich das wissen, muss ich das ganze Programm nach der Befüllung der Tabelle absuchen, wenn es nicht im Namen steht. Aber klar, Hauptsache lt_ steht davor, drei Zeichen für eine Nicht-Information.


Ralf
Bild Ralf WenzelHeuristika
SAP-Development • Datenschutzberatung
PublikationenUngarische NotationXing
ralf.wenzel
Top Expert
 
Beiträge: 2679
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 122 mal
Ich bin: Freiberufler/in

Re: Quality Management - Programmierrichtlinien

Beitragvon black_adept » 03.08.2017, 21:16

ralf.wenzel hat geschrieben:Außerdem: Da es keine globalen Daten im SAP gibt, ist das l schon Quatsch.
Nicht schon wieder dieser Unsinn. Erstens gibt sehr wohl globale Variablen- und zwar bezogen auf den Program-Load. Zweitens gibt es a) so was wie Verschattungen oder viel schlimmer b) wenn man vergisst eine (lokale) Variable zu definieren und es die leider im globalen Kontext schon gibt kommt man in Teufels Küche. Und drittens verstehe ich einfach nicht, warum du so unflexibel bist, dass du es nicht schaffst über die ersten 2-3 Buchstaben einer HN hinwegzusehen um den Rest des Variablennamens zu interpretieren. Wenn es Kollegen von mir leichter fällt HN zu lesen schreibe ich HN ( die sollen das schließlich später warten ) - wenn sie besser nicht-HN lesen können schreibe ich halt so. Der Compiler/Interpreter weiß eh was du meinst - da geht es eher darum den anderen Kollegen die Arbeit so leicht wie möglich zu machen
ralf.wenzel hat geschrieben:EKKO-Zeilen können alles mögliche sein. Rahmenverträge, Bestellungen, etc. Nach irgendeinem Kriterium werden die ja wohl in die interne Tabelle geschrieben worden sein - und genau das gehört in den Namen. Dann weiß ich auch, was drin ist. Will ich das wissen, muss ich das ganze Programm nach der Befüllung der Tabelle absuchen, wenn es nicht im Namen steht. Aber klar, Hauptsache lt_ steht davor, drei Zeichen für eine Nicht-Information.

Ist dir schon mal der Gedanke gekommen, dass es bei einem Programm implizit klar sein könnte ( weil es z.B. im Klassennamen steht ) ob es sich um Rahmenverträge, Bestellungen oder was auch immer handelt und dass man es nicht explizit angeben muss? Oder dass es evtl. wichtig sein könnte die Quelle der Daten anzugeben ( EKKO )? Nicht jeder denkt so wie du, Ralf - aber das heißt nicht, dass alle anderen Idioten sind, deren Ansätze schon mal per se nix taugen weil sie nicht von dir sind.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Für diese Nachricht hat black_adept einen Dank bekommen :
Unit605
black_adept
Top Expert
 
Beiträge: 2725
Registriert: 08.01.2003, 13:33
Wohnort: Lehrte ( bei Hannover )
Dank erhalten: 397 mal
Ich bin: Freiberufler/in

Re: Quality Management - Programmierrichtlinien

Beitragvon ralf.wenzel » 04.08.2017, 06:04

Pass mal auf. Hier wird nach Meinungen gefragt und das ist meine. Wenn sie dir nicht passt, lies sie einfach nicht. Ich habe sie (siehe Link in der Signatur) mehrfach mit verschiedenen Ansätzen schlüssig begründet.

Wenn meine Meinung hier nicht gefragt ist, kann ich meinen User gern löschen und das Posten einstellen.

Ich soll hier ständig Rücksicht nehmen auf die Befindlichkeiten anderer. Auf mich nimmt auch keiner Rücksicht.

Zum letzten Mal: "Global" ist ein absoluter Begriff. Eine globale Klasse (auch ein Datentypen) ist systemweit verfügbar. Dieses Kriterium erfüllt KEINE Variable, also gibt es keine globalen Variablen. Klar kann ich "global" auf was anderes beziehen als auf das, was man darunter versteht, dann ist HN globaler Unfug (global auf mich bezogen) und ganz toll (global auf dich bezogen). Und zur Benamung nochmal: Ich diskutiere hier den allgemeinen Fall. Dass es IMMER Spezialfälle gibt, liegt auf der Hand. Für ein Materialdaten-Migrations-Framework habe ich lauter Tabellennamen verwendet, von denen ich hier abrate. Also komm mir bitte nicht mit "aber wenn dies und das und jenes zutreffen". Wir machen hier keine Fließbandarbeit.

Ich schaue oft und gern über den Tellerrand und erlebe gerade bei Leuten, die aus anderen Welten der Softwareentwicklung kommen, völliges Unverständnis für die im SAP üblichen Präfixe. Und "mal HN und mal nicht" ist kein definierter Standard. Einen Schaltplan, der von mehreren Leuten erstellt wird, wirst du auch nicht "mal kursiv, mal nicht" beschriftet sehen (auch wenn beides Normschrift ist). Wenn das einer sieht, sagt er wie es alle machen sollen, weil Einheitlichkeit eine Reihe von Vorteilen hat.

So, nochmal: Willst du meine Meinung nicht wissen, ignoriere sie bitte. Aber ich lasse mich hier nicht als Arsch vom Dorf hinstellen, der nur >>SPAM<< schreibt. Man könnte meine durch Fakten schlüssig belegte Meinung einfach mal akzeptieren. (Zur HN höre ich immer nur, es fiele Leuten leichter. Deutsch fällt vielen auch leichter als englisch, trotzdem sollten Variablen englisch sein).

Wenn man das (Akzeptieren) nicht will, kann ich auch gehen!!


Ralf *sauer

Edit für alle die, die fünf Jahre nicht aufgepasst haben: Sog. "globale" Variablen sind OBSOLET, weil intransparent. Schon deshalb sollten sie in einer gescheiten Anwendung gar nicht vorkommen. Und WENN sie unvermeidbar sind, kann man sie so kapseln, dass man sie nicht direkt verwendet.
Bild Ralf WenzelHeuristika
SAP-Development • Datenschutzberatung
PublikationenUngarische NotationXing
ralf.wenzel
Top Expert
 
Beiträge: 2679
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 122 mal
Ich bin: Freiberufler/in

Re: Quality Management - Programmierrichtlinien

Beitragvon black_adept » 04.08.2017, 07:29

ralf.wenzel hat geschrieben:Zum letzten Mal: "Global" ist ein absoluter Begriff. Eine globale Klasse (auch ein Datentypen) ist systemweit verfügbar. Dieses Kriterium erfüllt KEINE Variable, also gibt es keine globalen Variablen.

Langsam wird mir klar wo dein Problem liegt - du verwendest eine eigene Definition von "globale Variable" und nicht diejenige, die üblicherweise im Kontext von Programmiersprachen verwendet wird.
  • https://en.wikipedia.org/wiki/Global_variable hat geschrieben:In computer programming, a global variable is a variable with global scope, meaning that it is visible (hence accessible) throughout the program, unless shadowed.
  • https://de.wikipedia.org/wiki/Variable_(Programmierung)#Sichtbarkeitsbereich_von_Variablen_.28Scope.29 hat geschrieben:Ein wichtiges Konzept von Programmiersprachen ist das Unterprogramm, ob es nun Prozedur, Funktion, Methode oder noch anders heißt. Die allgemeinste Form dieses Konzepts ist der in der Programmiersprache ALGOL 60 erstmals eingeführte Block. Praktisch alle Programmiersprachen, die dieses Konzept in irgendeiner Form anbieten, erlauben es, dass Blöcke ihre eigenen Variablen besitzen, die sich von den Variablen anderer Blöcke eindeutig unterscheiden lassen. Solche Variablen heißen lokale Variablen. Eine Variable, die im ganzen Programm für alle Blöcke zur Verfügung steht, heißt globale Variable.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de
black_adept
Top Expert
 
Beiträge: 2725
Registriert: 08.01.2003, 13:33
Wohnort: Lehrte ( bei Hannover )
Dank erhalten: 397 mal
Ich bin: Freiberufler/in

Re: Quality Management - Programmierrichtlinien

Beitragvon black_adept » 04.08.2017, 07:36

ralf.wenzel hat geschrieben:Edit für alle die, die fünf Jahre nicht aufgepasst haben: Sog. "globale" Variablen sind OBSOLET, weil intransparent. Schon deshalb sollten sie in einer gescheiten Anwendung gar nicht vorkommen. Und WENN sie unvermeidbar sind, kann man sie so kapseln, dass man sie nicht direkt verwendet.

1.) Wenn ich den rot markiertem Teil anschaue frage ich mich, warum du dich wunderst wenn man dich darauf hinweist Rücksicht zu nehmen?
2.) Die Worte "obsolet" und "unvermeidbar" sind eine Tautologie.
3.) Ralfs grundsätzliche Aussage hingegen ist durchaus valide:
https://en.wikipedia.org/wiki/Global_variable#Use hat geschrieben:They [global variables] are usually considered bad practice precisely because of their non-locality: a global variable can potentially be modified from anywhere (unless they reside in protected memory or are otherwise rendered read-only), and any part of the program may depend on it. A global variable therefore has an unlimited potential for creating mutual dependencies, and adding mutual dependencies increases complexity. See action at a distance. Global variables also make it difficult to integrate modules because software written by others may use the same global names unless names are reserved by agreement, or by naming convention. However, in a few cases, global variables can be suitable for use. For example, they can be used to avoid having to pass frequently-used variables continuously throughout several functions. In practice, large programs may well require a large number of global variables because there are so many parameters that are shared between different functions, and care must be taken to make sure different functions share the global data without mishap.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de
black_adept
Top Expert
 
Beiträge: 2725
Registriert: 08.01.2003, 13:33
Wohnort: Lehrte ( bei Hannover )
Dank erhalten: 397 mal
Ich bin: Freiberufler/in

Re: Quality Management - Programmierrichtlinien

Beitragvon ralf.wenzel » 04.08.2017, 08:00

Der rot markierte Satz steht da so, weil das schon seit Jahren so gilt, offensichtlich aber von einigen fröhlich weiterverwendet wird.

Obsolet heißt "nicht mehr gebräuchlich", unvermeidbar kann es z. B. bei Dynpros sein. Ja, ich habe auch schon Klassenattribute dafür eingesetzt, aber das birgt viele Fehlerquellen in sich (z. B. wird nicht mehr gefragt, in der DDIC-Typ als Basis herangezogen werden soll, auch wenn das Attribut auf einem basiert). Es wird nichtmal verprobt, ob es das Attribut überhaupt gibt.

Ich hab so mal einen Tippfehler suchen müssen (bzw. einen Fehler, der sich als Tippfehler herausstellte), da wird man bekloppt.


Ralf
Bild Ralf WenzelHeuristika
SAP-Development • Datenschutzberatung
PublikationenUngarische NotationXing
ralf.wenzel
Top Expert
 
Beiträge: 2679
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 122 mal
Ich bin: Freiberufler/in

Re: Quality Management - Programmierrichtlinien

Beitragvon Romaniac » 07.08.2017, 11:27

Jetzt hört's halt auf, bis einer weint... ;-)

mich würde jetzt nur ein link zur korrekten Darstellung von Variablen interessieren. Ich gehe mal davon aus das HN und UN das gleiche bedeuten (ungarische oder hungarian Notatition), habe bisher auch meine Variablen mit l+<typ> benannt, (auch lt_ekko weil ich dann weis woher die Daten stammen, unter Umsatänden dann noch lt_ekko_po etc. für Differenzierung). Das G_ habe ich weggelassen weil alles was nicht lokal definiert ist kann war dann eben global(soweit das nötig ist)

Habe nur diesen link gefunden: https://help.sap.com/http.svc/rc/abapdo ... _guidl.htm
oder gibt es da noch ausführlichere Information?

Danke und Gruß aus dem Urlaub in Portugal,

Wolfgang
Geht nicht gibts nicht
Romaniac
ForumUser
 
Beiträge: 57
Registriert: 20.03.2017, 10:31
Wohnort: Augsburg
Dank erhalten: 7 mal
Ich bin: Freiberufler/in


Zurück zu SAP - Allgemeines

  Aktuelle Beiträge   
Barcodes in Warenbewegungen & Belegen
vor 14 Stunden von marc.braun 0 Antw.
HTML Daten als Anhang an Mail unter AOO
vor 16 Stunden von SAP_ENTWICKLER 0 Antw.
SAP Access & Identity Management - noch aktuell?
vor 19 Stunden von SaskuAc 0 Antw.
gelöst SELECT...WHERE mit ähnlichen String-Feldern
vor 18 Stunden von Suta_K 4 Antw.
gelöst Seitensteuerung Adobe Forms
vor 14 Stunden von Lucyalison 12 Antw.

  Ähnliche Beiträge beta
GISA Change Management Handbuch
14.10.2013, 04:35 von hänsel 3 Antw.
globales Label, Etiketten management
26.07.2013, 07:00 von ratsnus 0 Antw.
Suche Literatur zum Records Management
06.06.2016, 15:19 von Nuke 5 Antw.
SAP Access & Identity Management - noch aktuell?
14.12.2017, 11:54 von SaskuAc 0 Antw.

 

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder

Feedback ...?

Was können wir verbessern? Hinterlasse deine Kontaktdaten, wenn du eine direkte Antwort möchtest.

... Absenden!