AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Programmieren allgemein Argumente für oder gegen Programmieraufgabe

Argumente für oder gegen Programmieraufgabe

Ein Thema von V08523 · begonnen am 14. Nov 2009 · letzter Beitrag vom 16. Nov 2009
Antwort Antwort
Seite 1 von 2  1 2   
V08523

Registriert seit: 24. Jul 2009
13 Beiträge
 
#1

Argumente für oder gegen Programmieraufgabe

  Alt 14. Nov 2009, 09:19
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 ?
Delphi 7, Delphi 2005, Delphi 2007
Das Leben der Programmierer wäre ohne die Anwender sehr viel leichter.
  Mit Zitat antworten Zitat
Benutzerbild von Mithrandir
Mithrandir
(CodeLib-Manager)

Registriert seit: 27. Nov 2008
Ort: Delmenhorst
2.379 Beiträge
 
#2

Re: Argumente für oder gegen Programmieraufgabe

  Alt 14. Nov 2009, 09:33
Wenn das Programm OOP-konform geschrieben wurde, lassen sich solche Änderungen eigentlich recht flink umsetzen.
米斯蘭迪爾
"In einer Zeit universellen Betruges wird das Aussprechen der Wahrheit zu einem revolutionären Akt." -- 1984, George Orwell
  Mit Zitat antworten Zitat
mjustin

Registriert seit: 14. Apr 2008
3.003 Beiträge
 
Delphi 2009 Professional
 
#3

Re: Argumente für oder gegen Programmieraufgabe

  Alt 14. Nov 2009, 09:52
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.
Michael Justin
habarisoft.com
  Mit Zitat antworten Zitat
alzaimar
(Moderator)

Registriert seit: 6. Mai 2005
Ort: Berlin
4.956 Beiträge
 
Delphi 2007 Enterprise
 
#4

Re: Argumente für oder gegen Programmieraufgabe

  Alt 14. Nov 2009, 09:53
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
"Wenn ist das Nunstruck git und Slotermeyer? Ja! Beiherhund das Oder die Flipperwaldt gersput!"
(Monty Python "Joke Warefare")
  Mit Zitat antworten Zitat
V08523

Registriert seit: 24. Jul 2009
13 Beiträge
 
#5

Re: Argumente für oder gegen Programmieraufgabe

  Alt 14. Nov 2009, 09:54
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.
Delphi 7, Delphi 2005, Delphi 2007
Das Leben der Programmierer wäre ohne die Anwender sehr viel leichter.
  Mit Zitat antworten Zitat
Benutzerbild von Mithrandir
Mithrandir
(CodeLib-Manager)

Registriert seit: 27. Nov 2008
Ort: Delmenhorst
2.379 Beiträge
 
#6

Re: Argumente für oder gegen Programmieraufgabe

  Alt 14. Nov 2009, 09:59
Zitat von V08523:
OOP ?
In dem Programm ist das ein Fremdwort.
Aii... Ok, dann würde ich mich auch dagegen sträuben...
米斯蘭迪爾
"In einer Zeit universellen Betruges wird das Aussprechen der Wahrheit zu einem revolutionären Akt." -- 1984, George Orwell
  Mit Zitat antworten Zitat
V08523

Registriert seit: 24. Jul 2009
13 Beiträge
 
#7

Re: Argumente für oder gegen Programmieraufgabe

  Alt 14. Nov 2009, 10:09
Das sind ja für einen Samstag morgen schon viele Antworten. Ich bin überrascht.
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.
Delphi 7, Delphi 2005, Delphi 2007
Das Leben der Programmierer wäre ohne die Anwender sehr viel leichter.
  Mit Zitat antworten Zitat
V08523

Registriert seit: 24. Jul 2009
13 Beiträge
 
#8

Re: Argumente für oder gegen Programmieraufgabe

  Alt 14. Nov 2009, 10:18
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 von alzaimar:
Delphi-Quellcode:
DerAuftrag.Option['IstRabattierfähig'] := 1;
DerAuftrag.Option['Zuschlag'] := 'teilweise';
Kannst Du das noch etwas mehr erkären ?
Delphi 7, Delphi 2005, Delphi 2007
Das Leben der Programmierer wäre ohne die Anwender sehr viel leichter.
  Mit Zitat antworten Zitat
Benutzerbild von fkerber
fkerber
(CodeLib-Manager)

Registriert seit: 9. Jul 2003
Ort: Ensdorf
6.723 Beiträge
 
Delphi XE Professional
 
#9

Re: Argumente für oder gegen Programmieraufgabe

  Alt 14. Nov 2009, 10:40
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
Frederic Kerber
  Mit Zitat antworten Zitat
V08523

Registriert seit: 24. Jul 2009
13 Beiträge
 
#10

Re: Argumente für oder gegen Programmieraufgabe

  Alt 14. Nov 2009, 10:50
Hallo Frederic,
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
Delphi 7, Delphi 2005, Delphi 2007
Das Leben der Programmierer wäre ohne die Anwender sehr viel leichter.
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 1 von 2  1 2   

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 09:00 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz