- GUI Programmierung im allgemeinen, Erfahrungsaustausch -

[Timo_R]

Hallo,

eine grundsätzliche Frage:
Sollte Ihres Erachtens die GUI Programmierung vor, während oder nach der eigentlichen Programmieraufgabe erfolgen?
Das heißt:
Stellt es einen höheren Programmieraufwand im allgemeinen dar, eine GUI auf ein
bestehendes Programm aufzusetzen, oder ist dies gleich zu Beginn der Programmierung zu
berücksichtigen?

Ein kleiner Erfahrungsaustausch...

Beste Grüße

[5cript]

Eine eigenartige Frage.

Wenn man dafür bezahlt wird gilt folgendes nicht:
Wenn es ein privates Projekt ist würde ich sagen: beides gleichzeitig. Aus Motivationsgründen. Einzelheiten und Perfektionismus nach hinten verschieben und erstmal die Kerndinge grundlegend anpacken und Hürden abbauen.
Nach diesem Aspekt sehe ich die Gefahr, dass man das Projekt liegen lässt wenn man eine der Hälften (GUI / Backend oder Kern) einzeln macht.

Die Funktionalität des Programms reift und wächst meist mit den Ansprüchen durch die Bedienung.
Und sonstiger Aufwand zum verheiraten einer GUI mit Funktionalität sollte so trivial sein wie holzkleber und 2 Planken.
Sonst hat man einen eigenartien Programmierstil. Wobei es darauf ankommt WIE man die GUI macht

Wenn man ein Framework benutzt wie Qt, dann kann einem Qt vieles abnehmen, was man sonst zu fuß gemacht hätte.
Qt hat viele nützliche Zusatzfeatures, die einen bei Benutzung aber immer mehr an Qt binden, weil es wie eine Wurzel durch das Programm wächst.

Wenn es ein Web frontend ist, dann muss das Backend freundlich als API verpackbar sein und die Anforderungen sind oft anders. Zum Beispiel Skalierbarkeit durch sharding und statemanagement durch Datenbanksynchronisierung.
Wenn man sonst überall Programmstate rumfliegen hat ist das nachträglich anstrengend auszumisten, wenn man nicht immer auf dem gleichen Server verbunden ist.

[Schlangenmensch]

Hm, schwer zu sagen. Ich würde für mich die GUI am liebsten zum Schluss machen, wenn ich weiß welche Eingaben ich wirklich brauche. Kurz zur einordnung, ich arbeite viel mit Chemieingenieuren oder Chemikern zusammen, denen sind manchmal Dinge klar, die sie dann nicht mehr formulieren und mir erst später auffallen .
Ich würde GUI entwicklung ganz gerne auch schon mal auslagern, weil mir das am wenigsten Spaß macht, dafür sollten aber die Anforderungen klarer sein, als sie bei uns manchmal sind.

Generell: manche Sachen probieren sich besser mit GUI aus, da bastelt man die dann doch direkt mit, oder man will schon mal Teile präsentieren, dass geht auch besser, wenn es schon GUI gibt, oder man weiß aus Erfahrung, dass sich grade Anforderungen an die GUI noch deutlich ändern, wenn die Kollegen die ersten Versionen davon sehen, dann fängt man am besten mit der GUI an.

[Mechanics]

Das kommt sehr stark drauf an, was man macht, und wie die Anforderungen aussehen. Eigentlich ist die Antwort wertlos, weil völlig offensichtlich.

[Helmut.Jakoby]

Kommt darauf an, wer das Projekt treibt und wie groß es ist.

Grundsätzlich plädiere ich für eine Trennung von GUI und „logischen Businessteil“. Damit ist bei einer neuen Wahl des GUI nur dieses neu zu implementieren. Fehler im „logischen Businessteil“ können ggf. ohne Änderung der Oberfläche behoben werden.

Wenn der „Kunde“ gerne über Oberflächen seine Wünsche formuliert, kann man diese als „Prototyp“ bauen (mocken der Funktionalität) und abnehmen lassen und dann die Funktionalität nachziehen. Kommt dem Agilen entgegen.

Möchte der Kunde z.B. Geschäftsprozesse abwickeln lassen und braucht eine Oberfläche nur für die Unterstützung, bzw. Ansicht von Zuständen des Geschäftsprozesses, geht es halt andersrum.

Da es einen Trend zum „Agilen Vorgehensmodell“ gibt, hat sich bei uns ein schneller Wechsel zwischen API- und GUI-Programmierung ergeben (btw. sehe ich keinen qualitativen Unterschied zwischen GUI Programmierung und eigentlichen Programmieraufgaben).

Das oben Geschriebene bezieht sich auf größere Projekte.