Fuba oder Methode
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Gut, dann sagst du dem Kunden "Geht nicht" wenn er dir eine Anforderung beschreibt, für die er derzeit eine SAPGUI braucht, die er aber auf dem Endgerät nicht zur Verfügung hat?Daniel hat geschrieben:Nur weil etwas gerade vorhanden ist muss es nicht unbedingt
auch geeignet sein.
Dann geht er zur nächsten Firma, die ihm eine UI5-Lösung baut, die genau das tut was er will - was machst du dann?
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Das behauptet ja keiner - ich höre aus einer Richtung immer nur "ist zu unsicher", "ist ungeeignet", etc. Ohne Ansicht auf den Einzelfall. Warum die Sicherheit ein Problem sein soll, wenn ich in einem Lager (also im lokalen Netz) einen Barcodereader verwende, der einen Browser verwendet, ist mir ein Rätsel.Daniel hat geschrieben:Und es gibt sicher auch Anwendungen wo das passt. Das kann man
nur für den Einzelfall seriös beantworten.
Da müsste man mir schon schildern, warum das in welchen Fällen unsicher sein sollte. Und dass Dynpros sehr wohl Schwierigkeiten machen (z. B. in Sachen Kapselung, hatten wir ein paar Postings vorher), ist ja bekannt. Das ist auch kein Allheilmittel. Ich warte immer noch auf eine tabellenartige Eingabemöglichkeit, die nicht so "holzig" ist wie Table Controls, die ich ein furchtbares Gewürge halte. Eingabefähige ALVs sind nicht freigegeben und haben andere Tücken.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Das bezieht sich auf die Idee Browser-Lösungen als DIE Lösungralf.wenzel hat geschrieben: ich höre aus einer Richtung immer nur "ist zu unsicher", "ist ungeeignet", etc. Ohne Ansicht auf den Einzelfall.
für alles zu betrachten. Das kann im Einzelfall durchaus auch
anders sein. Aber als Ablösung für die GUI? Bitte nicht.
Auch die Rechner im Lager werden einen Anschluß an den Rest
der Welt haben. Ob eine Anwendung mit Browser da sicher sein
kann? Ich denke nicht.
Die Frage kann bestenfalls lauten: Ist es relevant? Wenn nur die
Lagerplätze angezeigt werden kann ja kaum jemand viel damit
anfangen.
Die eingabefähigen ALVs arbeiten recht ordentlich. Alternativ
kann man ja auch EXCEL rufen. Es gibt viele Wege nach Rom.
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Ich beende jetzt die "Diskussion", in der mir Sachen in den Mund gelegt werden, die ich weder geschrieben noch gemeint habe.Daniel hat geschrieben:Das bezieht sich auf die Idee Browser-Lösungen als DIE Lösung
für alles zu betrachten. Das kann im Einzelfall durchaus auch
anders sein. Aber als Ablösung für die GUI? Bitte nicht.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4087 / 126 /
940
)
»
Ich gebe dir ja ungern recht - aber hier mache ich das mal ausnahmsweise in den Teilen wo du sagst, dass es schön wäre eine einheitliche Entwicklungsumgebung für alles zu haben. Ist schließlich fast Wochenende.ralf.wenzel hat geschrieben:Für den Barcodereader haben wir eine andere Möglichkeit (von der ich nicht viel halte), ich habe andere aufgezählt, wo es dann aufhört. Es gibt etliche Anforderungen, von beliebigen Geräten aus Prozesse anzusteuern (das klassische iPhone ist nur ein Beispiel unter vielen). Diese Geräte haben alle die Gemeinsamkeit, einen Browser zu haben. Und die SAP wird keine GUI für alle diese Geräte schreiben wollen oder können.
DIESER fortschreitenden Entwicklung können wir uns alle nicht verwehren.
Nichtsdestotrotz. Auch wenn SAP keine Lust hat eine GUI für alle Geräte zu schreiben bzw das die UI5-Umgebung sein soll. Sie haben eine GUI für Windows, eine Portierung auf HTML derselben und tatsächlich browserbasierten Krams.
Der Hauptunterschied für meine Kunden. Sie brauchen jetzt Lösungen für ihre Probleme, "schönere" Darstellungen sind schnuppe weil entweder irgendwann auf Hana migriert wird und das dann sowieso hinfällig wird bzw. die Gui häufig für's tägliche Arbeiten als sinnvoller angesehen wird. Gerade die Beispiele à la "Produktionsleiter will via Handy eine Freigabe erteilen" ist bei den meisten meiner Kunden völlig irrelevant. Die Leute, die am SAP arbeiten haben nicht ohne Grund zwei oder drei Monitore um alle Informationen parat zu haben - die IPhone-SAP-Benutzer sind da eher die Sonderfälle für die keine Extrawürste gebraten werden. Und wenn es dann doch gebraucht wird, dann wird halt auch mal eine Browserversion angeboten - aber nicht für die "normalen" Benutzer, die mit der Windows-SAPGUI sehr gut leben können und damit eigentlich alles am System erledigen können und sich zudem noch über eine bessere Haptik und bessere Antwortzeiten freuen dafür aber über die prähistorische Aufbereitung ärgern.
Und letztendlich: Ich erwähnte es irgendwo anders schon: Kosten/Nutzen Relation.
Für eine dynprobasierte Anwendung brauche ich eine gewisse Zeit - alles andere dauert länger. Kann nicht State-of-the-Art OO-mäßig aufgebaut werden - aber das sieht der Anwender sowieso nicht sondern nur diejenigen die das nachher warten müssen. Und wenn das nachträglich tatsächlich auf einen weiteren View erweitert werden muss kostet das später weiteren Aufwand um es dann von mir aus auf MVC umzuschreiben. Das muss multipliziert werden mit der Wahrscheinlichkeit, dass es diesen weiteren View später geben muss. Hier muss ich ehrlich sagen - bei den Anwendungen die ich meist schreibe ist das eher unwahrscheinlich und bis dann irgenwann mal HANA eingeführt wird absolut ausreichend für die User. Klar würde ich gerne "schönere" Programme erstellen - aber aus Gründen die nur die AGs verstehen scheint man dort der Meinung zu sein, dass der eben beschriebene Ansatz für sie günstiger ist. Meine Aufgabe ist es aber auch nicht ein Programm zu erstellen so wie ich es haben möchte ( was deinen Vorstellungen vielleicht deutlich näher ist als du denkst ) sondern so wie der Kunde es wünscht wobei ich ihm natürlich beratend die anderen Vorteile erklären kann. Aber rechnen muss der am Ende selbst - und du siehst an diesem Post wo es dann fast immer endet.
Vielleicht noch mal ein anderer Gesichtspunkt der Budgetplaung - nämlich die Kapzitätskomponente. Wenn alles schick, modern, erweiterbar gemacht werden soll kostet das auch mehr Zeit ( und damit meist auch mehr Geld ) und somit mehr Entwickler, wenn eine feste Arbeitslast zu einem speziellen Datum fertig sein muss. Und du weißt ja selber wie es gerade jetzt wo ich das schreibe aussieht: Finde mal gute Entwickler.
a-dead-trousers hat geschrieben:Da Dynpros noch aus prozeduralen Urzeiten stammen muss man sich überlegen wie man diese mit einem modernen (klassenbasierten) MVC (oder von mir aus auch MVVM) verbindet.4byte hat geschrieben: Wie kann ich mir das vorstellen?
Es gibt einige interessante Ansätze dazu von SAP selbst, aber die Frameworks sind irgendwo mittendrinnen stehengebleiben, als die SAP den Schwenk zu HTML5 (UI5 usw.) vollzog.
Was ich bislang von unseren Software-Lieferanten so gesehen hab ist, dass alle (notgedrungen) ein eigenes Dynpro <-> Klasse Framework begonnen haben.
Eine Klasse pro Dynpro, pro Dynpro(View) wäre auch richtig nach MVVM. NuR dann ist die Oberfläche tatsächlich leicht austauschbar, was bei MVC nicht der unbedingt der Fall ist. Nicht umsonst ist MVVM entwickelt worden.
Für Dynpros gilt, dass sie ein paar Sonderlocken haben ( mal zum Vorteil, mal zum Nachteil), die in anderen UIs so nicht vorkommen. Um MVVM einzuhalten muss man bei Dynpros Funktionaltität nachbilden, die das Dynpro selbst schon hat. Anders wiederherum.hat man nicht die volle Kontrolle über ein Dynpro, da sie selbst vor Jahren nur "angedockt" wurden. Man sieht die Schwächen auch oft in Standard-SAP Programmen,wie MV45A usw.
Man kann auch Dynpro-Attribute als Klassenattribute angeben. Nur fehlt dann leider ein Dictionary-Bezug. Da sie public sein müssen, bricht man auch mit OO. Zumindest aber als eine Art DTO können sie dann dienen.
"Code lügt nicht ^^"
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Da ist ja immer auch eine Frage, WAS man macht. Klar, wenn man mal ein bisschen was programmiert, einen Report oder eine kleine Eingabemaske, dann ist das etwas anderes als wenn man ein Add-On schreibt mit ganz neuen Prozessen mit einer irren Komplexität. Und wenn man dann noch dafür sorgen muss, dass das Ganze maschinell testbar ist.
Und wenn man HEUTE was auf der Grünen Wiese anfängt, ist der Anwender geprägt durch Non-SAP-Anwendungen (und es sind eben nicht mehr die Vollzeit-Anwender, die den ganzen Tag am SAP sitzen, sondern zunehmend auch Leute, die etwas ganz anderes machen und *nebenher* das SAP befüttern müssen).
Zu GTOXX: Die Klassenattribute im Dynpro werden auch kaum unterstützt, das macht ziemlich viel Arbeit. Die Dynprotechnik ist schon lange nicht mehr state-of-the-art und müsste eigentlich grundsätzlich überarbeitet werden. Das wird die SAP aber kaum tun.
Ralf
Und wenn man HEUTE was auf der Grünen Wiese anfängt, ist der Anwender geprägt durch Non-SAP-Anwendungen (und es sind eben nicht mehr die Vollzeit-Anwender, die den ganzen Tag am SAP sitzen, sondern zunehmend auch Leute, die etwas ganz anderes machen und *nebenher* das SAP befüttern müssen).
Zu GTOXX: Die Klassenattribute im Dynpro werden auch kaum unterstützt, das macht ziemlich viel Arbeit. Die Dynprotechnik ist schon lange nicht mehr state-of-the-art und müsste eigentlich grundsätzlich überarbeitet werden. Das wird die SAP aber kaum tun.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
black_adept hat geschrieben:Ich gebe dir ja ungern recht - aber hier mache ich das mal ausnahmsweise in den Teilen wo du sagst, dass es schön wäre eine einheitliche Entwicklungsumgebung für alles zu haben. Ist schließlich fast Wochenende.ralf.wenzel hat geschrieben:Für den Barcodereader haben wir eine andere Möglichkeit (von der ich nicht viel halte), ich habe andere aufgezählt, wo es dann aufhört. Es gibt etliche Anforderungen, von beliebigen Geräten aus Prozesse anzusteuern (das klassische iPhone ist nur ein Beispiel unter vielen). Diese Geräte haben alle die Gemeinsamkeit, einen Browser zu haben. Und die SAP wird keine GUI für alle diese Geräte schreiben wollen oder können.
DIESER fortschreitenden Entwicklung können wir uns alle nicht verwehren.
Nichtsdestotrotz. Auch wenn SAP keine Lust hat eine GUI für alle Geräte zu schreiben bzw das die UI5-Umgebung sein soll. Sie haben eine GUI für Windows, eine Portierung auf HTML derselben und tatsächlich browserbasierten Krams.
Der Hauptunterschied für meine Kunden. Sie brauchen jetzt Lösungen für ihre Probleme, "schönere" Darstellungen sind schnuppe weil entweder irgendwann auf Hana migriert wird und das dann sowieso hinfällig wird bzw. die Gui häufig für's tägliche Arbeiten als sinnvoller angesehen wird. Gerade die Beispiele à la "Produktionsleiter will via Handy eine Freigabe erteilen" ist bei den meisten meiner Kunden völlig irrelevant. Die Leute, die am SAP arbeiten haben nicht ohne Grund zwei oder drei Monitore um alle Informationen parat zu haben - die IPhone-SAP-Benutzer sind da eher die Sonderfälle für die keine Extrawürste gebraten werden. Und wenn es dann doch gebraucht wird, dann wird halt auch mal eine Browserversion angeboten - aber nicht für die "normalen" Benutzer, die mit der Windows-SAPGUI sehr gut leben können und damit eigentlich alles am System erledigen können und sich zudem noch über eine bessere Haptik und bessere Antwortzeiten freuen dafür aber über die prähistorische Aufbereitung ärgern.
Und letztendlich: Ich erwähnte es irgendwo anders schon: Kosten/Nutzen Relation.
Für eine dynprobasierte Anwendung brauche ich eine gewisse Zeit - alles andere dauert länger. Kann nicht State-of-the-Art OO-mäßig aufgebaut werden - aber das sieht der Anwender sowieso nicht sondern nur diejenigen die das nachher warten müssen. Und wenn das nachträglich tatsächlich auf einen weiteren View erweitert werden muss kostet das später weiteren Aufwand um es dann von mir aus auf MVC umzuschreiben. Das muss multipliziert werden mit der Wahrscheinlichkeit, dass es diesen weiteren View später geben muss. Hier muss ich ehrlich sagen - bei den Anwendungen die ich meist schreibe ist das eher unwahrscheinlich und bis dann irgenwann mal HANA eingeführt wird absolut ausreichend für die User. Klar würde ich gerne "schönere" Programme erstellen - aber aus Gründen die nur die AGs verstehen scheint man dort der Meinung zu sein, dass der eben beschriebene Ansatz für sie günstiger ist. Meine Aufgabe ist es aber auch nicht ein Programm zu erstellen so wie ich es haben möchte ( was deinen Vorstellungen vielleicht deutlich näher ist als du denkst ) sondern so wie der Kunde es wünscht wobei ich ihm natürlich beratend die anderen Vorteile erklären kann. Aber rechnen muss der am Ende selbst - und du siehst an diesem Post wo es dann fast immer endet.
Vielleicht noch mal ein anderer Gesichtspunkt der Budgetplaung - nämlich die Kapzitätskomponente. Wenn alles schick, modern, erweiterbar gemacht werden soll kostet das auch mehr Zeit ( und damit meist auch mehr Geld ) und somit mehr Entwickler, wenn eine feste Arbeitslast zu einem speziellen Datum fertig sein muss. Und du weißt ja selber wie es gerade jetzt wo ich das schreibe aussieht: Finde mal gute Entwickler.
Ein guter Entwickler schafft erweiterbare Programme in der selben Zeit, wie ein schlechter den Standard ^^.
Was der AG bezahlt ist eine andere Sache. Wenn ich den Aufwand später in Wartbarkeit und Funktionalitätseinbussen bzw. Mehraufwand xür Anpssungen stecke, ist keinem geholfen.
Ich kenne natürlich die Argumentation, die Du meinst. Mit aber ein wenig Invest in das Design, was ich später in der Entwicklung dann ausgleichen kann, wäre oft viel geholfen.
Lustig sind doch immer die Anforderungen. uML ja bitte, aber lesen kann es keiner ... Doku .. Ja bitte. Aber in Word. Bloss nicht inplace, wo jeder neue User auch drauf zu greifen kann.
Die erste Lüge ist immer : "Das wird sich nie ändern" und die 2.te : "Das geht auf keinen Fall anders."
Klar gilt immer abzuwägen wrlche Komplexität sinnvoll ist und für einen Auftragsprogrammierer sind absehbare Anpassungen ja kein Nachteil^^.
Folgende Benutzer bedankten sich beim Autor gtoXX für den Beitrag:
ralf.wenzel
"Code lügt nicht ^^"
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Nominiert für das Posting des Monats!gtoXX hat geschrieben:Ein guter Entwickler schafft erweiterbare Programme in der selben Zeit, wie ein schlechter den Standard ^^.
Was der AG bezahlt ist eine andere Sache. Wenn ich den Aufwand später in Wartbarkeit und Funktionalitätseinbussen bzw. Mehraufwand xür Anpssungen stecke, ist keinem geholfen.
Ich kenne natürlich die Argumentation, die Du meinst. Mit aber ein wenig Invest in das Design, was ich später in der Entwicklung dann ausgleichen kann, wäre oft viel geholfen.
Lustig sind doch immer die Anforderungen. uML ja bitte, aber lesen kann es keiner ... Doku .. Ja bitte. Aber in Word. Bloss nicht inplace, wo jeder neue User auch drauf zu greifen kann.
Die erste Lüge ist immer : "Das wird sich nie ändern" und die 2.te : "Das geht auf keinen Fall anders."
Klar gilt immer abzuwägen wrlche Komplexität sinnvoll ist und für einen Auftragsprogrammierer sind absehbare Anpassungen ja kein Nachteil^^.
Ralf
Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag:
gtoXX
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von black_adept (Top Expert / 4087 / 126 /
940
)
»
Leider ist es aber meist so: Ich habe einen Entwickler und der muss was entwickeln, so dass dieses Argument nicht zieht.gtoXX hat geschrieben:Ein guter Entwickler schafft erweiterbare Programme in der selben Zeit, wie ein schlechter den Standard ^^.
Wieder die Diskrepanz zwischen Wunschdenken und Realität. Das kannst du noch so oft vorbeten - wenn der Verantwortliche für das Entwicklungsbudget nicht der selbe ist wie derjenige für das Wartungsbudget nützt die beste Argumentation nichts. Wenn es dann doch mal der selbe ist müsstest du den Vorteil beziffern können - und ich wüsste nicht, wie du das machen willst. Aber hier ist auch wieder ein Unterschied ob du für ein Systemhaus arbeitest, welches ihr Produkt an andere Kunden weitervertreiben oder für einen Enduser, der nur für sein Sytem entwickelt. Und das Letzere ist in meiner Realität meist der Fall. Als Entwickler kannst du dann nur so gut es geht für spätere Wartbarkeit sorgen - aber wenn das dann spürbar ins Budget geht bekommst du Ärger weil dein Auftrag eben ein anderer ist.gtoXX hat geschrieben:Was der AG bezahlt ist eine andere Sache. Wenn ich den Aufwand später in Wartbarkeit und Funktionalitätseinbussen bzw. Mehraufwand xür Anpssungen stecke, ist keinem geholfen.
Ich kenne natürlich die Argumentation, die Du meinst. Mit aber ein wenig Invest in das Design, was ich später in der Entwicklung dann ausgleichen kann, wäre oft viel geholfen.
Ich kenne tatsächlich keinen brauchbaren Entwickler, der so denkt. Gibt es bestimmt - aber irgendwie sind mir bisher nur Leute untergekommen, die ein gesundes Berufsethos haben.gtoXX hat geschrieben:und für einen Auftragsprogrammierer sind absehbare Anpassungen ja kein Nachteil^^.
Nachtrag: Eher kommt mir folgendes unter: "Ich habe da noch folgende Lücke entdeckt - das müsste man noch irgendwie abfangen, aber das dauert halt ein wenig und ihr müsstet vorher noch klären wie dann zu verfahren ist" "Antwort: Ist egal - wir haben das jetzt so definiert und getestet und das passt. Wenn die Anwender das dann doch mitkriegen können die ja einen Change-Request stellen"
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Das ist leider oft so, aber manchmal gibt es eben auch Entwicklungsleiter, die für das Coding im System verantwortlich sind. Das merkt man einem Endkunden dann auch an, weil er Coding abnimmt statt es einfach abzunicken. Der weiß, dass ein Test etwas anderes ist als Ausprobieren. Und der sagt "mein Produkt (das Coding) soll ähnlichen Qualitätskriterien unterliegen wie die Produkte, die meine Firma verkauft".black_adept hat geschrieben:Als Entwickler kannst du dann nur so gut es geht für spätere Wartbarkeit sorgen - aber wenn das dann spürbar ins Budget geht bekommst du Ärger weil dein Auftrag eben ein anderer ist.
Dieses Spielchen "Wir haben ein Programm, aber keiner weiß GENAU, was das Ding überhaupt macht", ist in meinen Augen unprofessionell. Ich hab schon öfters "Altprogramme" neu geschrieben, weil sie nicht mehr erweiterbar waren und eines Redesigns bedurften, der Entwickler war nicht verfügbar, eine schriftlich formulierte Anforderungen gab es nicht, eine Doku natürlich auch nicht und dann sind da Funktions-Krücken eingebaut, wo einem die Haare zu Berge stehen. Und dann kommt ein Anwender um die Ecke der sagt "wenn ich in das Werksfeld nix eingebe, macht das Programm aber was GANZ anderes".
Sowas ist MURKS! Darüber diskutiere ich auch nicht. Ja, es funktioniert, aber keiner weiß, warum. Das hat mit einer ingenieurartigen Tätigkeit nichts zu tun (und das IST Softwareentwicklung definitiv).
Und nochmal: Wenn man nicht nur das eine oder andere kleine Progrämmchen schreibt (die für sich allein arbeiten), sondern große, komplexe Add-Ons mit vielen Programmen, die ineinandergreifen müssen, hat man andere Kriterien als der Inhouse-Entwickler, der für jede Migration ein Einmalprogramm schreibt, das er dann wegwirft.
Ralf
Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag (Insgesamt 2):
gtoXX • black_adept
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
black_adept hat geschrieben:Leider ist es aber meist so: Ich habe einen Entwickler und der muss was entwickeln, so dass dieses Argument nicht zieht.gtoXX hat geschrieben:Ein guter Entwickler schafft erweiterbare Programme in der selben Zeit, wie ein schlechter den Standard ^^.Wieder die Diskrepanz zwischen Wunschdenken und Realität. Das kannst du noch so oft vorbeten - wenn der Verantwortliche für das Entwicklungsbudget nicht der selbe ist wie derjenige für das Wartungsbudget nützt die beste Argumentation nichts. Wenn es dann doch mal der selbe ist müsstest du den Vorteil beziffern können - und ich wüsste nicht, wie du das machen willst. Aber hier ist auch wieder ein Unterschied ob du für ein Systemhaus arbeitest, welches ihr Produkt an andere Kunden weitervertreiben oder für einen Enduser, der nur für sein Sytem entwickelt. Und das Letzere ist in meiner Realität meist der Fall. Als Entwickler kannst du dann nur so gut es geht für spätere Wartbarkeit sorgen - aber wenn das dann spürbar ins Budget geht bekommst du Ärger weil dein Auftrag eben ein anderer ist.gtoXX hat geschrieben:Was der AG bezahlt ist eine andere Sache. Wenn ich den Aufwand später in Wartbarkeit und Funktionalitätseinbussen bzw. Mehraufwand xür Anpssungen stecke, ist keinem geholfen.
Ich kenne natürlich die Argumentation, die Du meinst. Mit aber ein wenig Invest in das Design, was ich später in der Entwicklung dann ausgleichen kann, wäre oft viel geholfen.Ich kenne tatsächlich keinen brauchbaren Entwickler, der so denkt. Gibt es bestimmt - aber irgendwie sind mir bisher nur Leute untergekommen, die ein gesundes Berufsethos haben.gtoXX hat geschrieben:und für einen Auftragsprogrammierer sind absehbare Anpassungen ja kein Nachteil^^.
Nachtrag: Eher kommt mir folgendes unter: "Ich habe da noch folgende Lücke entdeckt - das müsste man noch irgendwie abfangen, aber das dauert halt ein wenig und ihr müsstet vorher noch klären wie dann zu verfahren ist" "Antwort: Ist egal - wir haben das jetzt so definiert und getestet und das passt. Wenn die Anwender das dann doch mitkriegen können die ja einen Change-Request stellen"
Es ist nicht zwangsläufig eine Diskrepanz zwischen Wunschdenken und Realität, wenn Unsinniges gefordert wird. Natürlich hat man manchmal mehr Diskussionsbedarf. Manchmal länger als die Umsetzung dauert.
Wo Du dabei arbeitest, spielt nicht die Rolle aus meiner Erfahrung. Und ich war dabei schon in allen Positionen. Ob sich eine ROI-Ermittlung lohnt hängt auch vom Einzelfall ab.
Dennoch, es generell nicht zu versuchen ist auch keine Lösung. Es gibt viele Wenn und Abers ubd Varianten. Am meisten scheitern Dinge daran, dass im Nachhinein keiner Verantwortung für eine Entscheidung übernehmen will.
"Code lügt nicht ^^"
Vergleichbare Themen
0
Antw.
Antw.
1143
Views
Views
1
Antw.
Antw.
1460
Views
Views
0
Antw.
Antw.
1666
Views
Views
2
Antw.
Antw.
2293
Views
Views
FuBa/Methode Sperrgrund löschen
von Thomas R. » 11.12.2013 10:05 • Verfasst in Material Management & Produktionsplanung
von Thomas R. » 11.12.2013 10:05 • Verfasst in Material Management & Produktionsplanung
5
Antw.
Antw.
1096
Views
Views
FUBA mit FUBA RSPO_OUTPUT_DEVICEDATA eine Liste ausgeben
von Thomas E » 06.05.2021 12:49 • Verfasst in ABAP® Core
von Thomas E » 06.05.2021 12:49 • Verfasst in ABAP® Core
Frage die ABAP Experten
Über diesen Beitrag
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.