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