Argumente für oder gegen Programmieraufgabe

[V08523]

Hallo zusammen,

heute brauche ich mal keine Hilfe zur Programmierung, ich suche Argumente für oder gegen eine Aufgabe. Ich soll ein Programm so ändern, daß anhand der Auftragsnummer weitere Programmfunktionen gesteuert werden (es ist KEINE Auftragsverwaltung !). Ein Beispiel: Enthält eine Auftragsnummer eine bestimmte Zeichenfolge (am Anfang, am Ende oder in der Mitte), so soll der Auftrag mit bzw. ohne Zuschlägen (oder auch nur teilweise) berechnet werden. Ich finde diese Variante überhaupt nicht sinnvoll, da Sie auch nur für einen einzigen Kunden eingesetzt werden soll. Eine Kopplung der Programmfunktionen an die Auftragsnummer schränkt den Anwender zu sehr ein und macht dem Programmierer das Leben schwer. Da viele Auftragsdaten auch per Schnittstelle übernommen werden, müßten hier zusätzliche Prüfungen erfolgen. Außerdem ist zu beachten, daß viele andere Programme die Auftragsnummer eventuell automatisch generieren. Wie soll da eine Steuerung anhand der Auftragsnummer erfolgen ? Generell halte ich eine Festlegung entsprechender Funktionen bei Erstellung eines Auftrags schon für sinnvoll, aber dann muß das Thema anders umgesetzt werden (z.B. mit zusätzlichen boolschen Steuerfeldern).

Argumente dafür:

• fallen mir keine ein

Argumente gegen:

• Einschränkung des Anwenders bei der Vergabe von Auftragsnummern
• falsche Berechnungen durch Eingabefehler
• zu viel Programmieraufwand jetzt und später

Wie ist Eure Meinung dazu ?

[Mithrandir]

Wenn das Programm OOP-konform geschrieben wurde, lassen sich solche Änderungen eigentlich recht flink umsetzen. ;)

[mjustin]

Zitat:

Zitat von V08523

Argumente gegen:

• Einschränkung des Anwenders bei der Vergabe von Auftragsnummern
• falsche Berechnungen durch Eingabefehler
• zu viel Programmieraufwand jetzt und später

Wie ist Eure Meinung dazu ?

Ich stimme zu - das wird sehr wahrscheinlich im Laufe der Zeit zu einer Korruption des Programms und entsprechenden Folgekosten für Wartung, Test, Fehlersuche führen.

Es gibt Ausnahmefälle in denen man es nicht vermeiden kann: bei Anbindung an Altsysteme, die diesen Aufbau zwingend vorgeben, und wenn Altsysteme durch das neue System ersetzt werden und eine bestimmte Nummernkreislogik existiert und nicht aufgegeben werden soll. Selbst dann würde ich versuchen, Nachteile deutlich zu machen, und meistens ist Argument 'Geld' das einzige das verstanden wird.

Siehe z.B. Wikipedia:
http://en.wikipedia.org/wiki/Technical_debt

Frei übersetzt: man erkauft sich die schnelle ("hastige") Umsetzung des Kundenwunsches durch "Schulden", die im Laufe der Zeit abgezahlt werden müssen. Vergleichbar mit Pfusch am Bau, damit es schnell und billig ist. Den Schaden haben dann beide, Auftraggeber und Auftragnehmer. Wenn man im Sinne des Auftragnehmers ('kundenorientiert') denken soll, muss man auf diese Folgekosten hinweisen.

[alzaimar]

Es ist immer schwer, bestehende Programme an Extrawünsche anzupassen. Man merkt dabei sofort, wie gut die Architektur der Anwendung ist.
Hier hast Du zudem noch eine ziemlich dämliche Vorgabe, aber es kann ja sein, das es nicht anders geht. Vielleicht ist das Datenbankformat vordefiniert o.ä.
Wenn Du allerdings eine andere Lösung implementieren könntest, würde ich alles daran setzen, diese blöde Funktionsverwurstung in Auftragsnummern zu kicken. Denn transparent und nachvollziehbar ist das nicht. Wird man sich in 2 Jahren noch an die Bedeutung des 2.Buchstabens erinnern? War das nun 'Zuschlag 5%', oder 'Teilweise Rabattierfähig'?

Dein Ansatz mit den Booleanfeldern ist schon mal nicht schlecht, aber bei der nächsten Änderungen (noch eine Option) müsstest Du die Klasse "Auftrag" ja schon wieder aufblähen.
Ich würde dem Auftrag eine Liste von Key-Value-Paaren mitgeben. Dort kannst du Optionen reinpacken, bis der Arzt kommt. Z.B. so:

Delphi-Quellcode:

Type
  TAuftrag = Class ...
  ...
  Public 
    Property Option[Key : String] : Variant Read GetOption Write SetOption;
  End;
...
DerAuftrag.Option['IstRabattierfähig'] := 1;  
DerAuftrag.Option['Zuschlag'] := 'teilweise';

Damit ist dann Ruhe. Du könntest damit sogar soweit gehen, um im Setter der 'Option'-Eigenschaft die Auftragsnummer wirkllich so zu ändern, wie es gewünscht ist. Aber über

[V08523]

Zitat:

Zitat von Daniel G

Wenn das Programm OOP-konform geschrieben wurde, lassen sich solche Änderungen eigentlich recht flink umsetzen. ;)

OOP ?
In dem Programm ist das ein Fremdwort. ;)

[Mithrandir]

Zitat:

Zitat von V08523

OOP ?
In dem Programm ist das ein Fremdwort. ;)

Aii... Ok, dann würde ich mich auch dagegen sträuben... ;)

[V08523]

Das sind ja für einen Samstag morgen schon viele Antworten. Ich bin überrascht.

Zitat:

Zitat von mjustin

Es gibt Ausnahmefälle in denen man es nicht vermeiden kann: bei Anbindung an Altsysteme, die diesen Aufbau zwingend vorgeben, ...

Der Kunde setzt komplett auf neue Software: ein PPS, eine Zeiterfassung und unser Programm für Controlling und Prämie. Wir bekommen die Aufträge und Zeiten über eine Schnittstelle. Die 'steuernde' Auftragsnummer soll nur in unserem Programm eine Rolle spielen, muß aber im PPS angelegt werden. Da sollte doch eine bessere Lösung machbar sein, als eine Auftragsnummer zu vergewaltigen.

[V08523]

Zitat:

Zitat von alzaimar

Dein Ansatz mit den Booleanfeldern ist schon mal nicht schlecht, aber bei der nächsten Änderungen (noch eine Option) müsstest Du die Klasse "Auftrag" ja schon wieder aufblähen.
Ich würde dem Auftrag eine Liste von Key-Value-Paaren mitgeben.

Eine Klasse "Auftrag" gibt es nicht. Ich bin schon froh, daß ich das ganze Array mit Auftragsdaten aus dem Programm verbannen konnte, da das Array die komplette DB-Tabelle enthalten hat.

Zitat:

Zitat von alzaimar

Delphi-Quellcode:

DerAuftrag.Option['IstRabattierfähig'] := 1;  
DerAuftrag.Option['Zuschlag'] := 'teilweise';

Kannst Du das noch etwas mehr erkären ?

[fkerber]

Hi!

Die Frage, die sich mir stellt, wenn euer Programm nur die Auftragsnummer bekommt, dann müssen ja alle Informationen, die direkt den Auftrag betreffen irgendwo (DB vermutlich) abgelegt sein.
Dann sollte es doch möglich sein, hier entsprechende Mehrinformationen abzulegen und wie du diese in eurem Programm nutzt ist ja dann erstmal egal.

Die andere Frage ist, kann das Programm, das die Auftragsnummern generiert das? Oder wählt man dieses Verfahren der Weitergabe von Infos über die Auftragsnnummer, weil das Programm keine anderen Möglichkeiten bietet Mehrinformationen zu kodieren?


Grüße, Frederic

[V08523]

Hallo Frederic,

Zitat:

Zitat von fkerber

Die Frage, die sich mir stellt, wenn euer Programm nur die Auftragsnummer bekommt, dann müssen ja alle Informationen, die direkt den Auftrag betreffen irgendwo (DB vermutlich) abgelegt sein.

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

[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:

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:

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:

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:

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:

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:

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.