Umfrage zu euren Erfahrungen mit ATC

Umfrage zu euren Erfahrungen mit ATC

Hallo zusammen,
wir wollen in diesem Jahr das ATC (ABAP Test Cockpit) von SAP einführen. Es geht darum die Qualität unserer Eigenentwicklungen zu verbessern. Im Mittelpunkt stehen: Verbesserung der Performance, der Sicherheit und der Stabilität.
Wir hatten praktisch das gleiche Projekt vor zwei Jahren schon einmal mit dem „Code Profiler“ von VirtualForge versucht. Haben dann aber gestoppt, weil der CodeProfiler die neue ABAP-Syntax nur zu einem geringen Teil unterstützte.
Von einer Unternehmensberatung habe ich in Erfahrung gebracht, dass bislang keiner Ihrer Kunden das ATC einsetzt. Ein, zwei Kunden hätten mal damit begonnen, dann aber wieder gestoppt.
Dieses Tool hat natürlich spürbare Auswirkungen auf jeden Entwickler, da die im ATC eingestellten Pflicht-Regeln erfüllt werden müssen, um Eigenentwicklungen freigeben bzw. transportieren zu können.

Wir haben mit dem Projekt noch nicht wirklich begonnen. Zur Zeit sind wir dabei Informationen zu sammeln. Wäre toll, wenn ihr eure Erfahrungen zu dem Thema (auch über die nachfolgenden Fragen hinaus) mitteilen würdet.

• Gibt es eine Schulung zur Administration und Anwendung des ATC? Ich konnte nur eine Schulung bei SAP finden, bei der das ATC wie mir scheint als Randthema behandelt wird.
• Ist es realistisch, eine zusätzlich Sichtkontrolle einzuführen? Ist das zeitlich überhaupt zu schaffen.
• Wie sehr wird der Entwicklungsprozess durch die Prüfungen (und Genehmigungsverfahren bei Ausnahmen) behindert?
• Lohnt sich der Aufwand? Kommen dabei am Ende auch wirklich „bessere“ Anwendungen heraus?
• Kennt ihr Unternehmen, die das ATC einsetzen und ggf. zu einem Erfahrungsaustausch bereit sind?

Re: Umfrage zu euren Erfahrungen mit ATC

Klingt spannend, aber da braucht man richtig Manpower dafür. Schon so verwendet ein Entwickler den Löwenanteil seiner Zeit zum Lesen von Code. Wenn er jetzt noch den ganzen Code lesen und verstehen muss, den sein Nebenmann erstellt hat, dann kann er in der Zeit an keinen eigenen Projekten arbeiten. Man braucht also erheblich mehr Manpower für dieselbe Menge an Ergebnissen, freilich in potenziell bedeutend höherer Qualität. Den Anteil der Auftraggeber, die sich darauf einlassen, halte ich freilich für klein. Zeit ist traditionell knapp oder teuer oder beides.

Der andere Aspekt dabei ist der soziale. Wenn ein Unternehmen zwei Entwickler hat und diese anweist, wechselseitig am Code des jeweils anderen herumzukritteln, dann sehe ich auf lange Sicht nur zwei mögliche Ergebnisse. Entweder sie raufen sich zusammen nach dem Leben-und-Leben-lassen-Prinzip, und jeder winkt den Pfusch des anderen weitestgehend durch. Dann kann man sich das ATC aber auch sparen; dann ist es wirklich nur verschenkte Zeit. Oder sie sind penibel, aber das wird dann drastisch auf die Stimmung schlagen, wenn jeder dem anderen Vorschriften macht, wie er zu programmieren habe. Es reicht ja ein Blick in das Forum hier um festzustellen, dass es ebenso viele Meinungen wie Entwickler gibt, wie ein optimaler Programmierstil auszusehen hat. Ich denke, dass man sich auf diese Weise drastisch das Betriebsklima versaut.

Von daher kommt mir - nur basierend auf Ralfs Worten, also ohne eigene Erfahrungen mit ATC zu haben - ATC nur in der einen Situation praktikabel vor, in der man eine Aufgabe an einen externen Anbieter outsourct und dessen Arbeit dann mit Hilfe des Tools von einem Inhouse-Entwickler prüfen lässt. Dann kann es einem ggf. egal sein, wenn man die externen Entwickler verärgert, indem man an ihrem Stil herumkrittelt.

Re: Umfrage zu euren Erfahrungen mit ATC

Ich muss dir massiv widersprechen. Audits haben Vorteile und jemand mit Größe lernt gern dazu.

Da stellt sich als erstes die Frage, wieviel Prozent der Menschen tatsächlich Größe haben. Ich tendiere zu einem einstelligen Wert.

Psychologie im Arbeitsleben zu unterschätzen ist ein gravierender Fehler. Da kannst Du von der Sache her recht haben, so viel Du willst, und es auch noch so gut begründen können - wenn Du durch Gekränktsein und daraus resultierenden Hass die Arbeitsatmosphäre vergiftest, wirst Du zu keinen guten Teamergebnissen mehr kommen.

Gerade bei dem genannten Kunden wurde mir früh gesagt: „Du bist auch hier, um UNS besser zu machen, so wie du durch uns auch besser wirst“.

Das hat Dir ein einziger Freaken dort gesagt. Im besten Fall war es der dortige Inhouse-Entwicklungsleiter, im schlechtesten Fall eine Führungskraft, die zwar den Wert von Qualität sieht, aber selber nicht entwickelt.

Dennoch kann ich unter diesen Umständen den Sinn von solch Direktive durchaus nachvollziehen, denn Du bist eben ein "Externer". Wenn Du es Dir mit einem Inhouse-Entwickler verscherzt, weil Du an seinem Code herumkrittelst, dann ist das Kritik von außen, über die er sich mit seinen Kollegen das Maul zerreißen kann, ohne dass das den Inhouse-Teamzusammenhalt gefährdet. Die beabsichtigte positive Wirkung entfaltet Deine Kritik dann dennoch.

Genauso ist es, wenn Dein Code von einem Inhouse-Kollegen des Kunden geprüft und kritisiert wird. Dann riskiert der auch nur, Dich zu verärgern, aber Du bist der Dienstleister und hast Dich nach den Wünschen zu richten. Wobei Du persönlich immerhin den Vorteil hast, dass Du zu entsprechender Qualität in der Lage bist und allenfalls etwas Mehrarbeit auf Dich nehmen musst. Ich tendiere zu der Auffassung, dass die Mehrher der ABAP-Entwickler, die ich kenne, das gar nicht können. (Oder vielleicht könnten sie es doch, wenn man sie entsprechend unter Druck setzen würde, das ist schwer zu beurteilen.)

Etwas anderes wäre es aber, wenn Du sowas komplett inhouse machst, wenn also ein Inhouse-Kollege den Code seines Tischgegenüber auditiert und umgekehrt. Da hast Du ganz schnell böses Blut, das die ganze Arbeitsathmosphäre vergiftet. Da nützen Dir auch Deine ganzen rationalen Argumente nichts, obwohl sie alle richtig sind, denn das ist menschliche Psychologie, und die ist nicht rational.

Anekdote für fehlende QM: Obwohl der Entwicklungsleiter eigentlich gut Englisch spricht, arbeiten Wir mit HEADER und POSITION, als ich das an meinem ersten Tag gesehen habe, habe ich die Hände über dem Kopf zusammengeschlagen. Da ich aber spät ins Projekt kam, war das nicht mehr zu ändern. Wer nicht deutsch spricht, versteht das nicht, was besonders fatal ist, wenn man ein Add-On schreibt, das verkauft werden soll.

Besonders klasse wird das, wenn noch ein HCM-Modul hinzukommt, denn im HCM steht das englische Wort "position" für eine Planstelle.

Weiteres Beispiel: Unterschiedliche Feldnamen für dieselbe Funktion in unterschiedlichen Strukturen. Dann hat der Spender eine Nummer, die man DONOR heißt, mal DONOR_ID, DONORID, DNR_ID, etc. Da wird explizites Fieldmapping aufwendig und generisches unmöglich. Die SAP kann das besonders gut.

Darüber habe ich mich auch schon oft geärgert. Immerhin habe ich den Eindruck, dass ABAP bei seinen Schnittstellen toleranter geworden ist als früher, wenn ich es auch nicht genau an einer Releasenummer festmachen kann. Ich bin der Meinung, früher haben Funktionsbausteine gemeckert, wenn Du einen Parameter vom Typ PERSNO übergeben hast und dieser im FB als PERNR_D definiert war (obwohl beide Datenelemente redundanterweise für die Personalnummer stehen und als (8) TYPE N definiert sind). Heute schluckt ABAP das anstandslos und wirft Dir sogar eine Compilerwarnung, wenn Du beim CALL FUNCTION einen CONV angibst mit dem Warnungshinweis, dass dieser überflüssig sei.

Klar, schnell und billig ist das nicht. Aber in D wird kein Auto, kein AKW, keine Zigarette und keine Schraube „schnell und billig“ hergestellt, sondern jeweils in herausragender Qualität

Das möchte ich in dieser allgemeingültigen Formulierung in Zweifel ziehen. Da reicht es, mal nach "López-Effekt" zu googlen.

Wer, wenn nicht wir können die Qualität hoch halten?

Alle Nationen, die technologisch oben angekommen sind. Ein Land ist erst bettelarm, dann wird es Schwellenland und überschwemmt den Markt mit billigen Nachahmungen von Qualitätsprodukten. Im Laufe der Zeit und wird Know-How und Wohlstand angesammelt, und man geht zur Qualitätsproduktion über. In den 60er-Jahren waren Elektronikprodukte aus Japan Müll. In den 80ern hatte Südkorea diese Rolle übernommen. Danach kam China, aber inzwischen erreichen auch die den Punkt, an dem sich Qualität etabliert. Ich bin gespannt, wer als nächstes in die Lücke springt. Indien wäre eine Möglichkeit.

Heute sind Produkte aus Japan, Südkorea und zunehmend auch China locker auf qualitativer Augenhöhe mit deutscher Ware, nur dass dort eher andere Produktkategorien hergestellt werden als in Deutschland. Dadurch mussten viele deutsche Firmen ja auch den Laden dicht machen, weil sie sich eben nicht mehr über die Qualität von der fernöstlichen Konkurrenz absetzen konnten. Ich sage nur Nordmende, Telefunken, Grundig, Metz (gibt es alle noch, aber nicht mehr als Firmen, sondern nur noch als aufgekaufte Markennamen, unter denen jetzt Ramsch verkauft wird. Grundig ist mittlerweile türkisch - und wird ausgerechnet dadurch wieder besser.). Auch Loewe hätte es fast erwischt. Andere Firmen wie Braun fertigen längst nicht mehr in Deutschland - sondern in China. Ich war früher Braun-Fan, bin aber komplett auf Panasonic (Japan) umgeschwenkt. Heute bauen die IMHO die besseren Produkte. Selbst mein Rasierer ist von Panasonic, und ich habe es nicht bereut.

Auch mit meiner Miele-Waschmaschine war ich nicht wirklich zufrieden und habe mir danach eine aus dem Edel-Sortiment von Bosch gekauft. War die richtige Entscheidung - und sogar made in Germany.

In meiner Nachbarschaft sitzt HAUNI, Weltmarktführer im Bau von Automaten, die Zigaretten herstellen. Da schießen die Zigaretten aus dem Automaten in einem Tempo, dass man staunt (mehrere zigtausend pro Stunde). Und man staunt noch mehr, wenn man erfährt, dass JEDE EINZELNE ZIGARETTE gewogen und vermessen wird. Was nicht den eingestellten Toleranzen entspricht, fliegt raus! Das ist extrem aufwendig mit viel High-Tech, Lasern und weiß der Henker was. Ohne das wäre der Automat DEUTLICH billiger. Gekauft wird er, weil er so GUT ist und nicht über den Preis.

Ich gehe davon aus, dass auch ein hoher Automatenpreis Peanuts sind im Vergleich zu den sonstigen Kosten der Zigarettenherstellung, denn solch Automat hält ja sicherlich viele Jahre. Da lohnt es nicht, 10000 € bei der Anschaffung zu sparen; die findet man in der Gesamtkostenkalkulation nicht wieder.

Re: Umfrage zu euren Erfahrungen mit ATC

DeathAndPain hat geschrieben:

Wer, wenn nicht wir können die Qualität hoch halten?

Alle Nationen, die technologisch oben angekommen sind. Ein Land ist erst bettelarm, dann wird es Schwellenland und überschwemmt den Markt mit billigen Nachahmungen von Qualitätsprodukten. Im Laufe der Zeit und wird Know-How und Wohlstand angesammelt, und man geht zur Qualitätsproduktion über. In den 60er-Jahren waren Elektronikprodukte aus Japan Müll. In den 80ern hatte Südkorea diese Rolle übernommen. Danach kam China, aber inzwischen erreichen auch die den Punkt, an dem sich Qualität etabliert. Ich bin gespannt, wer als nächstes in die Lücke springt. Indien wäre eine Möglichkeit.

Warum fängst du erst in den 60er Jahren an? Made in Germany stand ursprünglich für genau das: Billige, minderwertige Importware.

Re: Umfrage zu euren Erfahrungen mit ATC

Insgesamt finde ich es sinnvoll. Alleine dass der Code Inspector ausgeführt wird, bringt viele Vorteile. Er erkennt Performancefallen, ungünstige Tabellenzugriffe und weist auf HANA-Kompatibilität hin.
Ich wundere mich häufig, was für Fallstricke der automatisch erkennt.
Man kann sich dann drüber streiten, ob und wenn welche Namenskonventionen einzuhalten sind, aber wenn man die Hinweise des Code Inspectors berücksichtigt, hat man definitiv qualitativ hochwertigeren Code.
Allerdings nicht viel. Und einige Prüfungen führen dazu, dass sie entweder mit einem Pragma ausgeblendet oder mit einem unsinnigen Befehl ausser Kraft gesetzt werden (Keine Fehlerbehandlung in TRY-CATCH Block? zcl_ci=>nothing_to_do( ). )
Immerhin muss man sich aber noch mal mit dem Code beschäftigen, was keine schlechte Sache ist.

97% der Qualität kann ATC aber nicht sicherstellen. Das geht nur durch Schulung, Audits, Fortbildung, Motivation usw.
Plus: Alles kann auf mehreren Wegen programmiert werden. Und während der eine Programmierer eine Variante wählt, hätte ein anderer Entwickler einen anderen Ansatz verfolgt.

Vorteil des ATC ist noch, dass auch Unit Tests durchgeführt werden. Eine tolle Sache. Wenn man Unit tests hat. Wo keine Unit tests sind, können auch keine fehlschlagen...

Und doch noch kurz zum leidigen und immer heiß diskutierten Thema Namenskonventionen:
Ich finde es tatsächlich hilfreich, zu wissen, dass lokale Variablen IMMER mit L beginnen. Klassenattribute IMMER mit M und Importing-Parameter IMMER mit I.
Natürlich kann man - und insbesondere Ralf - immer gerne darüber streiten, wie sinnvoll die ungarische Notation ist. Fakt ist, dass man Variablen komplett unsinnig, nichtssagend und sogar irreführend benennen kann. Egal ob mit oder ohne Prefix. Ich verwende häufig bei kleinen Methode keine Prefixe und sehr kurze Parameternamen, um den Aufruf kurz zu halten. Häufig stolpere ich dann aber darüber, wenn ich OBJ (Klassenattribut) OBJ (importingparameter) zuweisen möchte. Mit UN nie ein Problem.
Aber auch hier gilt: Man wird noch mal gezwungen ins Programm zu schauen. Und wenn nur das I beim Importing-Parameter fehlt. Man überlegt sich vielleicht noch mal, ob der Name dann wirklich IV_OBJ heissen sollte oder vielleicht doch lieber IV_NEW_OBJECT_NUMBER. Ob man die "Gelegenheit" nutzt oder nicht, hängt dann wieder von vielen Umständen ab.

jm2c

Re: Umfrage zu euren Erfahrungen mit ATC

ralf.wenzel hat geschrieben:

ewx hat geschrieben:Allerdings nicht viel. Und einige Prüfungen führen dazu, dass sie entweder mit einem Pragma ausgeblendet oder mit einem unsinnigen Befehl ausser Kraft gesetzt werden (Keine Fehlerbehandlung in TRY-CATCH Block? zcl_ci=>nothing_to_do( ). )
Immerhin muss man sich aber noch mal mit dem Code beschäftigen, was keine schlechte Sache ist.

Darum finde ich das Genehmigungsverfahren gut, weil dann jeder einzelne Verstoß gegen die eingestellten Regeln begründet und von einem Auditor genehmigt werden muss.

Naja, in diesem Fall würde über den Code Inspector keine Meldung auftreten, da im Catch-Block ja eine "Fehlerbehandlung" drinnen ist. - außer natürlich du triffst eine Prüfung auf gewisse code-schnipsel ( wie in diesem fall halt auf diese Methode ) - aber das ist etwas was sich auch noch viel leichter umgehen lässt...

Wir sind aktuell dabei das ATC auf einem extra System aufzusetzen, als zentrale Prüfstelle, die in alle anderen Dev-Systeme schaut.

Aktuell läuft bei unseren Entwicklern nur wöchentlich ein Job der ihnen eine Mail zusendet mit deren ATC-Ergebnissen. Allerdings noch kein Genehmigungsverfahren .. - kommt aber mit dem neuen System.

Persönlich finde ich, dass es die Code-Qualität steigert, besonders im Bezug auf Performance und Sicherheit. Robuste Programmierung wird zwar auch etwas gestärkt, aber insgesamt nicht sooo sehr wie man sich das vielleicht erhofft. Aktuell haben wir neben SAP noch ein weiteres ERP-System am laufen, allerdings sollen diese Entwickler im Laufe der nächsten 1 - 3 Jahre ins SAP kommen und das alte System abgeschafft werden. Das schöne hierbei ist, mit dem ATC kann ich den Entwicklern schöne Entwicklungsweisen auftragen, dass diese gleich lernen Qualitativ hochwertigen Code zu schreiben.

Um kurz zu dem hier diskutierten Argument zu kommen, ob der Frieden des Teams mit dem Ding gestört wird, jain ( oder jein? ) .
Da gibt es zwei essentielle Punkte.
1. Die Einführung:
Man sollte nicht direkt alle Prüfungen mit Prio 1 und dann einem Block versehen. Sondern langsam anfangen, am besten mit Namenskonventionen auf 1 und der Rest erstmal auf 3. In einer anderen Firma haben wir dann wöchentlich ( und das werde ich hier auch wieder tun ) zwei Prüfungen dazu getan und auf Prio 2 gesetzt, dadurch kann man dann das Genehmigungsverfahren einleiten.
Wenn man gleich auf alle Prüfungen einen Block setzt ist der Unfrieden so groß, weil teilweise aktuelle Entwicklungen geblockt werden die schon lange am laufen sind. Generell reagieren Entwickler hier dann sehr allergisch..

2. Der Umgang mit den Entwicklern:
Man darf bei den Entwicklern dann nicht auf den Putz hauen und sagen "NEIN NEIN NEIN, so geht das aber nicht!!!!!!!" ( habe ich leider auch schon so erlebt .. ) - sondern man sollte dann Verbesserungsvorschläge bringen und Argumente bringen, warum das so nicht funktioniert. Jetzt in dem oben genannten Beispiel mit dem leeren Catch-Block: Man könnte Log-Points verwenden um zu loggen dass hier ein Programm auf Fehler gelaufen ist, oder in eine Tabelle oder sonstiges. Da muss sich der QM oder der Entwicklungsleiter ( derjenige der das halt verantwortet ) halt immer etwas Zeit nehmen.

Man muss also immer etwas aufpassen. Natürlich kann man, wenn man die Rückendeckung vom Vorgesetzten hat, auch die Hau drauf Methode machen.. aber empfehlen würd ichs nicht.

Um zum Thema zurück zu kommen. Empfehle ich das ATC? Ja. Steigert einfach die Qualität und unterstützt sogar im Entwickungsprozess direkt.

Hoffe ich konnte weiter helfen.

Re: Umfrage zu euren Erfahrungen mit ATC

ralf.wenzel hat geschrieben:{Personen mit Größe}Dass das wenige sind, ist mir klar. Hier im Forum sind es relativ viele.

Noch nicht mal da bin ich mir sicher. Hier im Forum über abstrakte Probleme zu kritisieren ist eine Sache, am produktiven Code, den ein anderer geschrieben hat herumzukritisieren und diesem damit zusätzliche Arbeit aufzuhalsen, die er nicht für nötig hält, eine andere. Selbst hier bekommen wir uns oft genug in die Haare, und jeder hat seine Meinung. Stell Dir mal vor, der Deinen Code auditierende Chefentwickler eines Kunden würde Dir sagen, dass Du keine UN verwendest hast ist unprofessionell, die musst Du bitte in Deinem gesamten Code nachpflegen und wäre von Deinem Standpunkt nicht mal ansatzweise zu überzeugen. Dann könntest Du a) das machen oder b) schmollend die Zusammenarbeit beenden. In beiden Fällen aber würdest Du Fresse ziehen.

Wäre auf lange Sicht kein Problem, weil Du mit diesem Chefentwickler nicht (notwendigerweise) in Zukunft zusammenarbeiten musst. Wenn es sich aber um Deinen Firmenkollegen vom Schreibtisch gegenüber handelt, mit dem Du auf Jahre täglich zu tun hast, dann kann sowas ganz schnell ein Problem werden.

Und selbst, wenn Du tatsächlich menschlich damit ohne Negativeffekte klarkämst (was ich offen anzweifle, ohne Beweise erbringen zu können), so denke ich doch, dass auch hier im Forum die wenigsten emotional unbeschwert mit so einer Situation umgehen könnten.

ralf.wenzel hat geschrieben:Das hat mir einer gesagt, aber alle haben es praktiziert. Ich habe noch nirgends so produktiv gearbeitet wie bei diesem Kunden und mich bei noch keinem Kunden so gut gefühlt. Wir haben wirklich alle voneinander gelernt. Wenn man mehrere Ansätze für eine Lösung hatte, hat man sich mit einem anderen zusammengesetzt und sie diskutiert und sich dann für einen entschieden.

Wenn man das schon auf Ansatz-Ebene tut, kann ich mir das gut vorstellen. Beim ATC-Audit läuft das aber anders: Jemand hat das so implementiert, wie er es für richtig gehalten hat. Die Sache war für ihn so klar, dass er vorher keinen Diskussionsbedarf gesehen und daher auch nicht gefragt hat. Jetzt kommst Du her und sagst, das findest Du nicht in Ordnung so, wie er das gemacht hat. Das wirst Du so nicht durchwinken, dass soll er gefälligst umbauen. Dann hast Du eine ganz andere Situation, und zwar vor allem auch aus sozialer (zwischenmenschlicher) Sicht!

ralf.wenzel hat geschrieben:

DeathAndPain hat geschrieben:Dennoch kann ich unter diesen Umständen den Sinn von solch Direktive durchaus nachvollziehen, denn Du bist eben ein "Externer". Wenn Du es Dir mit einem Inhouse-Entwickler verscherzt, weil Du an seinem Code herumkrittelst, dann ist das Kritik von außen, über die er sich mit seinen Kollegen das Maul zerreißen kann, ohne dass das den Inhouse-Teamzusammenhalt gefährdet. Die beabsichtigte positive Wirkung entfaltet Deine Kritik dann dennoch.

Das ist schon wieder eine negative Stimmung - wenn jemand sachliche Kritik vorbringt, sollte einen das erfreuen.

Soweit die Theorie. Menschliche Psyche funktioniert aber anders. Das merkst Du nicht notwendigerweise sofort, weil die Leute nicht immer gleich das Maul aufmachen, sondern viel in sich hineinfressen - gerade am Arbeitsplatz, wo Politik immer ein Thema ist. Aber die Auswirkungen gibt es dennoch.

ralf.wenzel hat geschrieben:Ich hab als Kind auch nicht verstanden, warum der Lehrer sich bedankt hat, wenn man ihn auf einen Fehler an der Tafel aufmerksam macht.

Das ist ein Lehrer, der hat eine pädagogische Ausbildung, und davon abgesehen sind die Umstände andere. Zum einen ist es leicht, großzügig mal einen Fehler einzuräumen, wenn unstrittig ist, dass man im Grundsatz viel mehr über die Materie weiß und kann als sein Gegenüber. Zum anderen geht es in solch Fall nur über einen (mehr oder weniger objektiv nachweisbaren und dem Lehrer durchaus einleuchtenden) Sachfragen-Fehler, den er gemacht hat.

Etwas anderes ist es, wenn ein Schüler zum Lehrer geht und ihm im Auditor-Stil sagt, dass er seine Unterrichtsmethoden nicht in Ordnung findet und dass er der Meinung ist, der Lehrer solle seinen Unterrichtsstil in dieser und jener Richtung umstellen. Da wird es auch Lehrer geben, die damit ohne negative emotionale Reaktion umgehen können - aber ich bezweifle, dass das auch nur die Mehrheit ist. Ich behaupte, wenn man sich die Mühe machen würde, eine Statistik mit hinreichend großer Probandenzahl zu machen und Schüler zu vergleichen, die in solch Situation das Maul aufgemacht haben, vergleichen mit solchen, die lieber die Schnauze gehalten haben, dann hätten letztere am Ende des Schuljahres statistisch signifikant bessere Schulnoten von den jeweiligen Lehrern bekommen. Das muss dem Lehrer noch nicht mal bewusst sein; da läuft auch viel im Unterbewusstsein ab.

ralf.wenzel hat geschrieben:

DeathAndPain hat geschrieben:(Oder vielleicht könnten sie es doch, wenn man sie entsprechend unter Druck setzen würde, das ist schwer zu beurteilen.)

Neulich zum ersten Mal gehört: "Unter Druck entstehen Diamanten, unter DRUCK!" LOL

Aber es entsteht keine Liebe zum UnterDRÜCKer.

ralf.wenzel hat geschrieben:Ernsthaft: Wir brauchen eine Fehlerkultur. Das Bewusstsein, dass wir alle noch dazulernen können UND müssen, dass keiner von uns alles weiß und andere vielleicht bessere Ideen haben, bringt uns weiter. Ich habe gestern zweimal einen Kollegen gebeten, sich ein Stück Coding anzusehen, weil ich nicht einsah, warum es nicht funktioniert. Der guckt weniger betriebsblind drauf und zeigt sofort mit dem Finger auf die Wunde. Das spart mir Zeit, der freut sich dass er mir helfen konnte, alles Tutti.

Das mache ich auch zuweilen. Ob es Zeit spart, bin ich mir aber nicht sicher, denn manchmal kommt die Lösung (so wie in Deinem Fall), in vielen Fällen guckt der aber auch nur drauf, lässt sich den Sachverhalt erklären, rätselt und kapituliert am Ende, wobei ich dann das (auch faktisch nicht von der Hand zu weisende) Gefühl habe, dass er von dem Problem und seinen möglichen Ursachen noch weniger verstanden hat als ich. In ersterem Fall habe ich Zeit gespart, in letzterem Fall welche draufgelegt. Ob die Bilanz am Ende günstig für mich ist, bin ich nicht ganz sicher.

Manchmal reicht es aber auch aus, das Problem jemand anderem zu erklären oder detailliert niederzuschreiben. Plötzlich sieht man selber die Lösung.

Was sich bei mir in schwierigen Fällen auch bewährt hat: Auf Klo gehen. Was ich beim großen Geschäft schon an Geistesblitzen zur Lösung von Problemen hatte, an denen ich zuvor verzweifelt war, geht auf keine Kuhhaut. Und das, obwohl ich dort den Bildschirm mit dem fraglichen Code gar nicht vor Augen habe.

ralf.wenzel hat geschrieben:

DeathAndPain hat geschrieben:Etwas anderes wäre es aber, wenn Du sowas komplett inhouse machst, wenn also ein Inhouse-Kollege den Code seines Tischgegenüber auditiert und umgekehrt. Da hast Du ganz schnell böses Blut, das die ganze Arbeitsathmosphäre vergiftet. Da nützen Dir auch Deine ganzen rationalen Argumente nichts, obwohl sie alle richtig sind, denn das ist menschliche Psychologie, und die ist nicht rational.

Das habe ich bisher anders gelebt.

Ja, Du bist ja auch Lone Wolf-Freelancer. Na logisch hast Du dieses Problem da nicht.

ralf.wenzel hat geschrieben:Bei einem Kunden haben einige "Young Guns" einiges von mir zu hören bekommen. Den Spruch "Sie warten diese Anwendung 15 Jahre. Machen Sie das doch vernünftig. Sie machen sich hier Ihr Bett für die nächsten 15 Jahre - Sie sollten nicht reinpissen!" kennen die bis heute. Erst hab ich aufgerissene Augen kassiert, weil das so unflätiger Ton ist, aber den merkt man sich wenigstens.

Du weißt aber nicht, was sie im stillen Kämmerlein über Dich gedacht oder in der Pause über Dich geredet haben. Und wie Dein Arbeitsklima sich entwickelt hätte, wenn Du als ihr Kollege in dem Laden Deinen Arbeitsalltag der nächsten Jahre hättest verbringen müssen.

ralf.wenzel hat geschrieben:Und wo sind Opel und VW mit dem hingekommen? Lopez und Mehdorn sind heute Synonyme für "kaputtgespart".

Wenn das so wäre, dann hätte man Mehdorn nicht im Anschluss für den BER rekrutiert. Dass er dort ebenso wenig gerissen hat wie seine Vorgänger, steht auf einem anderen Blatt. Ich gehe davon aus, dass es da korrupte Strukturen gibt, die von einem Mann an der Spitze allein nicht aufzubrechen sind. Das Ganze erinnert mich stark an die Unvollendete in Italien.

https://www.welt.de/politik/ausland/art ... Macht.html

ralf.wenzel hat geschrieben:Das gilt für einfache Produkte wie Fernseher und DVD-Player. Aber wenn man ein Schiff auseinanderschneiden, ein Stück reinsetzen und alles wieder zusammenschweißen will, geht man heute immer noch zu Blohm & Voss. Auch die Queen Mary II wird in Hamburg gewartet, weil die Qualität der Arbeit UND die Termintreue weltweit unerreicht sind.

Beim Schiffbau haben wir halt einen Schwerpunkt. U-Boote werden aber in Griechenland gebaut. So hat halt jedes Land seine besonderen Stärken. Gerade bei Kreuzfahrtschiffen ist Deutschland ganz vorne. Die ganzen Riesenschiffe z.B. der Oasis-Klasse, die vorwiegend in der Karibik herumschippern, laufen alle in Deutschland vom Stapel.

ralf.wenzel hat geschrieben:Und an dem Tag, an dem unsere Kunden verstehen, dass das für die Wartung, die Sicherheit und die Zuverlässigkeit von Software auch gilt, haben wir gewonnen Eben WEIL die Sachen lange laufen und es daher nicht reicht, wenn der Entwickler weiß, wie er was warum umgesetzt hat (und es im Zweifel wieder vergisst).

Da gibt es aber noch andere Aspekte. Beispielsweise den, dass die Firma an doppelt so vielen Stellen nicht weiterkommt, wenn nur halb so viele Projekte umgesetzt werden, weil die Entwickler pro Projekt doppelt so viel Zeit benötigen (etwa wenn sie sich gegenseitig ihren Code auditieren, so dass sich in jeden Code gleich zwei Leute reindenken müssen). Da kommen dann Vorgaben, xyz muss gemacht werden, aber die Entwickler sind dicht bis oben hin mit Arbeit, also bleibt das liegen. Budget für mehr Leute ist nicht da. Dann eskalieren die Stakeholder des liegengebliebenen Projektes das bis zum Senior Vice President, der macht dann Druck, dann werden kurzfristig Prioritäten geändert, und dann nehmen die Dinge ihren Gang.

So läuft das in der Realität.

ralf.wenzel hat geschrieben:Macht halt keiner, weil er Diskussionen und Gemecker scheut. Ich scheue die nicht und keiner hier sollte das tun.

Das sagst Du so leicht. Man merkt bei Deinen Worten immer wieder, dass Du selbständiger Freelancer bist. In Unternehmensstrukturen läuft das anders. Und glaub mir: den Arbeitsplatz zu wechseln ist nicht die Lösung. Jeder hat das Gefühl, in einem "komischen" Unternehmen zu arbeiten. Das hängt damit zusammen, dass alle Unternehmen aus Menschen bestehen.

Dein Standpunkt kommt mir an dieser Stelle etwas realitätsfremd vor. Man merkt, dass Du den Arbeitsalltag großer Unternehmen nur von außen mitbekommst.

ewx hat geschrieben:Insgesamt finde ich es sinnvoll. Alleine dass der Code Inspector ausgeführt wird, bringt viele Vorteile. Er erkennt Performancefallen, ungünstige Tabellenzugriffe und weist auf HANA-Kompatibilität hin.
Ich wundere mich häufig, was für Fallstricke der automatisch erkennt.
Man kann sich dann drüber streiten, ob und wenn welche Namenskonventionen einzuhalten sind, aber wenn man die Hinweise des Code Inspectors berücksichtigt, hat man definitiv qualitativ hochwertigeren Code.
Allerdings nicht viel. Und einige Prüfungen führen dazu, dass sie entweder mit einem Pragma ausgeblendet oder mit einem unsinnigen Befehl ausser Kraft gesetzt werden

Wie Du schon sagst, sind die Vorteile der Hinweise des Code Inspectors sehr überschaubar. Was mich persönlich davon abhält, ihn zu nutzen, ist die Tatsache, dass er meine Prioritäten nicht respektiert: Für die Warnungen, die ich gerne ausblenden möchte, weil ich sie nicht für bedeutsam halte, gibt es keine Pragmas. Das ist in meinen Augen die größte Schwäche der Pragma-Technik (die bei dem Vorgängersystem aber auch nicht besser war): Für die meisten Sachen gibt es keine Pragmas.

Gäbe es sie, dann würde ich sie nutzen und hinterher den Code Inspector starten, um eine übersichtliche Liste für mich relevanter Meldungen zu bekommen. Pragmas nicht einzubauen hat aber dermaßen etwas von Bevormundung durch die SAP, dass dadurch die Motivation für mich verloren geht, den Inspector zu starten und mich anschließend durch den Wust der Meldungen zu kämpfen, die mich nicht interessieren, um die Perlen zu finden.

ewx hat geschrieben:Ich finde es tatsächlich hilfreich, zu wissen, dass lokale Variablen IMMER mit L beginnen.

Ich nicht. Davon abgesehen beobachte ich bei vielen Kollegen, die UN nutzen, eine abstumpfende Gewöhnungshaltung. Da steht irgendwann pauschal vor allem "LV_" - auch vor Variablen, die gar keine lokalen Variablen sind. Spätestens an der Stelle merkt man, dass im Kopf dieser Entwickler gar keine UN mehr aktiv ist, da die Bedeutung ja gar nicht mehr vorliegt. Es wird nur noch als Wasserkopf-Overhead LV_ vor alles gesetzt. Und da denke ich nicht nur an eine Person.

Ich persönlich habe jedenfalls niemals UN eingesetzt und dennoch nie ein Problem gehabt zu überblicken, wofür meine Felder stehen. Allerdings habe ich auch keine Scheu, die erlaubte Länge von 30 Zeichen Variablennamen auszuschöpfen, um sprechende Feldnamen zu verwenden. Mein besonderer Dank gebührt dabei Eclipse mit seiner sagenhaften automatischen Feldnamensergänzung beim Tippen. Dagegen ist die in der SE38 implementierte als kaum mehr als "rudimentär" einzuschätzen.

Es gibt kaum ein Thema, bei dem ich so klar hinter Ralfs Meinung stehe, wie dieses.

Re: Umfrage zu euren Erfahrungen mit ATC

DeathAndPain hat geschrieben:Dann könntest Du a) das machen oder b) schmollend die Zusammenarbeit beenden. In beiden Fällen aber würdest Du Fresse ziehen.

Ich würde ihm sagen, warum ich das anders sehe und es machen. Wenn der so dämlich ist, mir das erst nachher zu sagen, muss er mit den Mehraufwandes leben. Ich werde ja pro Stunde bezahlt

DeathAndPain hat geschrieben:Wäre auf lange Sicht kein Problem, weil Du mit diesem Chefentwickler nicht (notwendigerweise) in Zukunft zusammenarbeiten musst. Wenn es sich aber um Deinen Firmenkollegen vom Schreibtisch gegenüber handelt, mit dem Du auf Jahre täglich zu tun hast, dann kann sowas ganz schnell ein Problem werden.

Das ist wie bei allen Regeln in einem Betrieb - man muss nicht jede Regel verstehen oder gut finden. Wenn sie angeordnet sind, sind sie angeordnet. Ich habe halt die Freiheit, mit auszusuchen, mit wem ich arbeite.

DeathAndPain hat geschrieben:Wenn man das schon auf Ansatz-Ebene tut, kann ich mir das gut vorstellen. Beim ATC-Audit läuft das aber anders: Jemand hat das so implementiert, wie er es für richtig gehalten hat.

Ja, das gibt es auch. Und wenn der Auditor mir begründet, warum das Kappes ist, dann muss ich das ändern, das ist das Risiko, das ich immer habe. Egal ob mit ATC oder ohne, bei Daniel reicht es schon, den PP zu benutzen, um ähnlichen Ärger zu kriegen.

DeathAndPain hat geschrieben:Soweit die Theorie. Menschliche Psyche funktioniert aber anders.

Mit der Einstellung könntest du die gesamte Wissenschaft und Forschung auf der Welt zumachen.

DeathAndPain hat geschrieben:Das ist ein Lehrer, der hat eine pädagogische Ausbildun

Das macht jeder andere, der einen Vortrag hält, auch.

DeathAndPain hat geschrieben:Etwas anderes ist es, wenn ein Schüler zum Lehrer geht und ihm im Auditor-Stil sagt, dass er seine Unterrichtsmethoden nicht in Ordnung findet und dass er der Meinung ist, der Lehrer solle seinen Unterrichtsstil in dieser und jener Richtung umstellen.

Hab ich gemacht, 9. Klasse. Und mir damit nicht den Lehrer zum Feind gemacht, sondern die anderen Schüler. Abgesehen davon, dass einem Schüler der Auditor-Stil nicht zusteht, weil er kein Auditor ist. Bei einem Auditor weiß ich: Was der sagt, ist erstmal Gesetz!

DeathAndPain hat geschrieben:Aber es entsteht keine Liebe zum UnterDRÜCKer.

Wenn ich von meiner Frau und meinen Kindern geliebt werde, reicht mir das. Kollegen und Kunden sollen mich respektieren, nicht lieben.

DeathAndPain hat geschrieben:Das mache ich auch zuweilen. Ob es Zeit spart, bin ich mir aber nicht sicher, denn manchmal kommt die Lösung (so wie in Deinem Fall), in vielen Fällen guckt der aber auch nur drauf, lässt sich den Sachverhalt erklären, rätselt und kapituliert am Ende

Ah, weil die Wahrscheinlichkeit besteht, dass es schiefgeht, versuchst du es erst gar nicht?

DeathAndPain hat geschrieben:Ja, Du bist ja auch Lone Wolf-Freelancer. Na logisch hast Du dieses Problem da nicht.

Ich habe trotzdem schon 5 Jahre mit denselben Leuten zusammengearbeitet.

DeathAndPain hat geschrieben:Du weißt aber nicht, was sie im stillen Kämmerlein über Dich gedacht oder in der Pause über Dich geredet haben. Und wie Dein Arbeitsklima sich entwickelt hätte, wenn Du als ihr Kollege in dem Laden Deinen Arbeitsalltag der nächsten Jahre hättest verbringen müssen.

Ach, weißt du.. Ich war Stotterer auf einer Ruhrgebietshauptschule, Hauptschüler in einer Familie von lauter hochbegabten Akademikern, die ganze Stadt wusste dass mein Stiefvater meine Mutter im Suff verprügelt hat. Und ich beschränke mich explizit auf den nicht so schlimmen Teil meiner Lebensgeschichte. Wenn du SO eine Lebensgeschichte hast, ist dir Getuschel egal.

Und immerhin weiß ich, dass die Leute mich heute noch anrufen, wenn sie Fragen haben - statt die Kollegen oder Freiberufler zu fragen, die ein paar Armlängen weit weg sitzen. Weil ich mir die Zeit nehme, es ihnen gescheit zu erklären und diese Erklärungen keine Bastelanleitungen sind, sondern sie fachlich wirklich weiterbringen.

DeathAndPain hat geschrieben:So läuft das in der Realität.

Aber nur in der Software-Entwicklung. Kein Mensch würde die QM bei einer Schraube in Frage stellen, nur weil kein Geld dafür da ist. Es liegt an uns, den Leuten klarzumachen, dass wir keine Script-Kiddies sind.

DeathAndPain hat geschrieben:Das sagst Du so leicht. Man merkt bei Deinen Worten immer wieder, dass Du selbständiger Freelancer bist. In Unternehmensstrukturen läuft das anders. Und glaub mir: den Arbeitsplatz zu wechseln ist nicht die Lösung. Jeder hat das Gefühl, in einem "komischen" Unternehmen zu arbeiten. Das hängt damit zusammen, dass alle Unternehmen aus Menschen bestehen.

Ich sitze nicht selten vier bis fünf Jahre, manchmal länger in einem Unternehmen. Du tust gerade so, als wäre ich zwei Wochen da und würde wieder gehen.

DeathAndPain hat geschrieben:Davon abgesehen beobachte ich bei vielen Kollegen, die UN nutzen, eine abstumpfende Gewöhnungshaltung. Da steht irgendwann pauschal vor allem "LV_" - auch vor Variablen, die gar keine lokalen Variablen sind. Spätestens an der Stelle merkt man, dass im Kopf dieser Entwickler gar keine UN mehr aktiv ist, da die Bedeutung ja gar nicht mehr vorliegt. Es wird nur noch als Wasserkopf-Overhead LV_ vor alles gesetzt. Und da denke ich nicht nur an eine Person.

Das zitiere ich jetzt mal nur, weil das so treffend formuliert ist.

DeathAndPain hat geschrieben:Ich persönlich habe jedenfalls niemals UN eingesetzt und dennoch nie ein Problem gehabt zu überblicken, wofür meine Felder stehen.

Schon der Quatsch, dass Klassen mit CL und Interfaces mit IF anfangen, zeigt, dass die, die sich das ausgedacht haben, nicht viel von Softwareentwicklung verstehen. Das ist in anderen Sprachen (soweit ich das überblicken kann) "sehr unüblich", um das mal vorsichtig formulieren.



Ralf