Argumente für oder gegen Programmieraufgabe

[Uwe Raabe]

Ich stimme dir zu, daß die Anforderung ziemlicher Blödsinn ist und eigentlich zurückgewiesen werden müsste. Allerdings hatte ich selbst gerade einen ähnlich gelagerten Fall und mich auch erst auf einen Diskussion mit dem Auftraggeber eingelassen - ohne Erfolg!

Ich würde an deiner Stelle das Problem minimal-invasiv lösen:

- Schreibe eine Prozedur, die einen Auftrag gemäß den Vorgaben anhand der Auftragsnummer manipuliert (die zusätzlichen Eigenschaften musst du natürlich anlegen)
- Finde alle Stellen, an der eine Auftragsnummer einen Auftrag generiert (manuelle Eingabe, Import) und rufe die besagte Prozedur auf

Sollten später weitere oder andere Kriterien hinzukommen, kannst du das dann durch Anpassen dieser Prozedur einbauen.

Ich bin jetzt absichtlich nicht auf OOP eingegangen, da das ja in dieser Anwendung nicht existiert. Allerdings gäbe es da auch ein paar interessante Ansätze, wie z.B. eine Auftrags-Factory.

[mjustin]

Zitat von V08523:

Wir bekommen alle von uns benötigten Daten über die Schnittstelle. Di Schnittstelle zu erweitern, wäre kein Problem. Ob das PPS aber zusätzliche Auftragsinformationen generieren kann, weiß ich nicht (ich bin nur der Programmierer in der Dunkelkammer ).Mike

Ganz klar: sauberer wäre es die Schnittstelle zu erweitern und in zusätzlichen Datenfeldern die Auftragsparameter zu übergeben, als in der Auftragsnummer. Das wäre aus vielen Gründen vorteilhaft, bringt mehr Klarheit und erlaubt es auch den Aufbau der Auftragsnummer irgendwann mal (bei einer Unternehmensfusion z.B. ...) zu ändern ohne dass dadurch ein Rattenschwanz an Änderungen folgt.

Fragen kostet nichts: selbst wenn es bei der Erfassung der Aufträge (zur Zeit!) keine Möglichkeit gibt, die Steuerparameter zu erfassen, kann man doch eventuell in der Schnittstelle (die ja auch nur ein Programm ist) aus der Auftragsnummer die relevanten Informationen herausziehen und sie in getrennte Felder der Schnittstellendaten packen. Das wäre robuster und zukunftssicherer. Einfach mal vorschlagen und zu Ende diskutieren

Cheers,

[Reinhard Kern]

Mal was ganz und gar untechnisches: man sollte mit solchen Einwänden sehr vorsichtig und diplomatisch umgehen. Ich habe auch schon Kunden darauf hingewiesen, dass ihre Schaltungen nicht funktionieren könnten, dabei ist es mir aber auch passiert, dass der Entwickler mit mühsam unterdrückter Wut zugegeben hat, dass das zutrifft, es war aber der letzte Auftrag, der an mich erteilt wurde (obwohl der Hinweis der Fa. viel Geld erspart hat, aber der Entwickler hat dafür gesorgt). Ganz besonders schlimm ist es, wenn man auch noch Recht hat.

Wenn du dich weigerst, was suboptimales auszuführen, kannst du zwar stolz darauf sein, aber die Familie ernährst du damit nicht.

Gruss Reinhard

[V08523]

Ich sehe mich in meiner Meinung bestätigt, die Auftragsnummer nicht zu vergewaltigen. Mein Blick geht ja auch weiter. Die Schnittstellen sind nicht auf den Anwender speziell zugeschnitten, d.h. alle Anwender benutzen die gleichen Schnittstellen. Was ist, wenn ein anderer Anwender Nummernkreise oder ähnliches verwendet, die genau in das Raster fallen ? Was ist mit einem Programmierer, der mal nach mir an dem Projekt weiter macht ? Nein, es muß eine saubere Lösung her, die auch noch in Jahren nachvollziehbar ist.

Zitat von Reinhard Kern:

... Ich habe auch schon Kunden darauf hingewiesen, dass ihre Schaltungen nicht funktionieren könnten, ... es war aber der letzte Auftrag, der an mich erteilt wurde ... Wenn du dich weigerst, ... aber die Familie ernährst du damit nicht.
Gruss Reinhard

Den Punkt habe ich so noch nicht betrachtet. Aber wer soll dann das Projekt weiter entwickeln ? Ich bin doch allein in meiner Dunkelkammer und Rettung ist nicht in Sicht.

Die Aufgabe macht doch eher den Eindruck, daß hier Leute sich etwas ausgedacht haben, was für den Augenblick gut klingt, aber dann in der weiteren Praxis Probleme bringen kann. Es wurden nur die Belange eines Anwenders berücksichtigt. Unser Programm soll aber auch noch von anderen Anwendern eingesetzt werden. Warum werden Programmierer nicht mal mit in die Klärung eines Sachverhalts eingebunden, gerade wenn es um die Erweiterung vorhandener Funktionen geht ? Am Geld kann es bei mir nicht liegen !

[p80286]

Hallo VO8523,

Zitat von V08523:

..... Warum werden Programmierer nicht mal mit in die Klärung eines Sachverhalts eingebunden, gerade wenn es um die Erweiterung vorhandener Funktionen geht ?

Dann lies Dir mal alle Beiträge, mit möglichst viel (geistigem) Abstand durch. Da werden Dir Patentlösungen um die Ohren geknallt, das ist eine wahre Freude. Mit OOP löst man keine Probleme! Das ist nur ein Werkzeug/Hilfsmittel zur Problemlösung! Und wenn man so mit dem Kunden umspringt, das ist es kein Wunder wenn man in der Dunkelkammer sitzt. (ist nicht pers. gemeint.)

Zu Deinem Problem, Du hast Recht, wenn Du die Richtigkeit der "Multifunktionalen Auftragsnummer" anzweifelst. Ich habe Erfahrung mit sehr langlebigen Nummern (>20 Jahre), und ich kann Dir versichern, daß jede Änderung in der Generierung dieser Nummern, die Genialität des Augenblicks, spätestens nach ein oder zwei Dekaden, als Schnapsidee erscheinen läßt. Eine Auftragsnummer ist eine Auftragsnummer und kein Hilfsmittel zur Produktionssteuerung oder was auch immer.

Aber wenn der Kunde es will, nachdem man ihn freundlich und sachlich auf die Nachteile hingewiesen hat....
Da kann ich Reinhard nur recht geben, mit Recht haben ernährt man keine Familie.

Gruß
K-H

[mjustin]

Zitat von p80286:

Aber wenn der Kunde es will, nachdem man ihn freundlich und sachlich auf die Nachteile hingewiesen hat....

Wenn ich es richtig verstehe, ist es nicht nur ein einziger Kunde / Anwender. Bei einem Kunden eine besondere Logik verwenden - das macht es noch weitaus schlimmer als befürchtet

Ich habe schon einigen Code gesehen (und auch schreiben dürfen) der nach diesem Muster ablief:

Delphi-Quellcode:

case Mandant of
 1234: ExecAuftragsMaskeFuerKunde1234;
 6789: ExecAuftragsMaskeFuerKunde6789; 
else
  ExecNormaleAuftragsMaske;
end;

Das macht Spass, vor allem wenn man nach Änderungen alle Mandanten (Kunden) testen darf um ungewollte Seiteneffekte zu finden.

Eine andere 'beliebte' Lösung für mandantenspezifische Logik ist es, das Programm zu forken und dann je Kunde (Anwender) eigene Quelltextzweige zu pflegen (jeweils mit eigenen Testdatenbeständen, Dokumentationen etc.). Eine nie versiegende Quelle der Freude bei übergreifenden Änderungen, wenn 3000 Formulare (dreißig Mandanten x zehn Anwendungsmodule x zehn Formulare) von Delphi 7 auf Delphi 2009 umgestellt werden müssen

Cheers,
Michael Justin

[V08523]

Zitat von mjustin:

Wenn ich es richtig verstehe, ist es nicht nur ein einziger Kunde / Anwender. Bei einem Kunden eine besondere Logik verwenden - das macht es noch weitaus schlimmer als befürchtet

Es ist genau anders herum. Nur ein Kunde. Und es ist nicht mal der Wunsch des Kunden, sondern er soll es erst so machen bzw. bekommen.

Zitat von mjustin:

Ich habe schon einigen Code gesehen (und auch schreiben dürfen) der nach diesem Muster ablief:

Delphi-Quellcode:

case Mandant of
 1234: ExecAuftragsMaskeFuerKunde1234;
 6789: ExecAuftragsMaskeFuerKunde6789; 
else
  ExecNormaleAuftragsMaske;
end;

Das macht Spass, vor allem wenn man nach Änderungen alle Mandanten (Kunden) testen darf um ungewollte Seiteneffekte zu finden.

Und genau das will ich auch vermeiden. Einige dieser Ungetüme konnte ich auch schon verbannen. Vor langerZeit hat das gleiche Programm noch komplett in drei Varianten existiert, jetzt gibt es auch nur noch eine Variante.

Ich habe heute erst mal um weitere Informationen gebeten. Vielleicht geht ja doch noch was einfacher.