Wie wird das bei großen Projekten mit Branches gemacht?
-
Xin schrieb:
Brancher schrieb:
Ich frage mich oft, wie es bei größeren Projekten gehandhabt wird, dass sie für mehrere Plattformen verfügbar sind.
Erstens kapselt man Dinge. Bekannt ist dabei das MVC-Pattern. Das M (Model) beschreibt die Daten, das C (Controller) die Algorithmen, was mit den Daten passieren soll und das V (View). View könnte hier Plattformabhängig sein - hier kann ein Fenster über MFC oder Qt geöffnet werden, die Eingaben werden entsprechend des OS abgefragt und in einem programminternen Standard an den Controller übergeben.
Man kann die View auch plattformunabhängig halten. Ich würde sogar sagen man sollte. Hat viele Vorteile. Kann man mit Libraries wie Qt oder wxWidgets auch super machen.
Xin schrieb:
Eine VM wie Java oder C# ist quasi eine View. Hier wird die Plattform einfach auf verschiedene Betriebssysteme zwischengeschaltet.
Nö, eine VM "ist" keine "View". Das ist einfach nur Unsinn, sorry. Eine VM ist eine VM.
Xin schrieb:
Ein Betriebsystem ist sogesehen auch nichts anderes als ein View.
.NET ist eine VM - quasi ein Windows-Programm.Der selbe Unsinn.
Xin schrieb:
Brancher schrieb:
Worauf ich hinaus will ist, dass ich gerne wüsste, wie solche Projekte im Entwicklungsprozess aussehen. Gibt es da gemeinsamen Basiscode (z. B. der Kernel bei Windows) und darauf wird dann alles aufgebaut und neu geschrieben, was plattformabhängig ist? Was ist, wenn es einen Bugfix gibt, der alle Systeme betrifft? Der muss ja dann überall eingespielt und getestet werden.
Richtig.
Ja ne, eigentlich isses eher genau umgekehrt.
Das Low-Level Zeugs ist plattformabhängig, und daraf baut man dann plattformunabhängigen Code auf.ps: Bist du zufällig Student?
-
danke, ich fühle mich in meiner theorie über quasianer bestätigt!
-
hustbaer schrieb:
Man kann die View auch plattformunabhängig halten. Ich würde sogar sagen man sollte. Hat viele Vorteile
Gefaellt mir persoenlich eher weniger.
Unter OS X mag ich ein anderes Feeling fuer die Anwendung haben als unter Windows. Und unter iOS soll das ganze sowieso komplett anders aussehen und Android hat auch wieder seine eigenheiten.
zB ist OpenOffice unter OS X einfach nicht verwendbar. Oder auch das neue MS Office mit der identischen Codebase Windows/OS X ist Interface technisch einfach strange.
Aber ansonsten full ack.
-
@Shade Of Mine:
Ich denke kleinere Anpassungen an die Zielplattform sind OK, bzw. sollten einfach gemacht werden. z.B. Standard Key-Bindings wie F5 für Refresh/Reload und F3 für Weitersuchen unter Windows. Mittlerweile (nach 12 Jahren) hab' ich mich an F9 = Refresh und F5 = Lock Session bei Lotus Notes gewöhnt, aber anfangs war das schon ordentlich nervig.
Auch andere Dinge, wie z.B. dass man die "nativen" Open-File Dialoge etc. verwendet. Einige GUI Toolkits schaffen es ja immer noch das nicht zu schaffen, und präsentieren mir einen Open-File Dialog der zwar fast so aussieht wie der vom System, sich aber nicht genau so verhält. Sowas nervt natürlich.An bestimmten Stellen wir man auch nicht auskommen. Speziell je mehr man sich "dem System" nähert. Ein Programm das irgendwelche System-Internas umstellen kann wird ein paar Dialoge haben die je nach System anders aussehen.
Diese "angepassten Stellen" werden dann notwendigerweise plattformabhängig sein. Der Rest kann aber mMn. plattformunabhängig bleiben.
Für ganz kleine Projekte mag es auch Sinn machen alles perfekt auf die Zielplattform anzupassen.
Grundsätzlich finde ich es aber eher gut, wenn die Anwendung überall ziemlich genau gleich aussieht und funktioniert. Speziell bei grösseren Anwendungen. Wenn man da zu viel unterschiedlich macht, hat man bald zwei oder drei unterschiedliche Anwendungen, die unterschiedliche Beschreibungen/Tutorials/... erfordern usw. Das hilft kaum jemandem.
Stell dir mal vor Photoshop, 3D Studio Max oder auch MS Word/Excel würden unter OS X komplett anders aussehen und zu bedienen sein als unter Windows. Fändest du das wirklich gut? Ich nicht.
Und letztendlich spart es auch eine Menge Entwicklungszeit.
-
hustbaer schrieb:
Stell dir mal vor Photoshop, 3D Studio Max oder auch MS Word/Excel würden unter OS X komplett anders aussehen und zu bedienen sein als unter Windows. Fändest du das wirklich gut? Ich nicht.
Naja, aber das ist ja zB schon ein guter Punkt. Photoshop mit den vielen individuellen Fenstern ist auf Windows zB ungewohnt. Sie haben mit CS4 oder CS5 jetzt so einen unified Mode eingefuehrt - damit es unter Windows besser wirkt. Dieser Unified Mode ist aber unter OS X eine Katastrophe
Oder unter OS X mit MS Office ist es so, dass teilweise Funktionalitaet ueber das Menu (was unter Windows entfernt wurde, technisch bedingt aber unter OS X nicht entfernbar ist) und Ribbons erreichbar und teilweise nur ueber eins von beiden - da eine 1:1 Umsetzung nicht moeglich war.
Natuerlich funktioniert es - aber zB SDI <-> MDI ist halt doch ein Unterschied. Und auf Tablets ist platzbedingt sowieso alles anders.
-
Ja, auf Tablets ist alles anders.
Shade Of Mine schrieb:
Naja, aber das ist ja zB schon ein guter Punkt. Photoshop mit den vielen individuellen Fenstern ist auf Windows zB ungewohnt. Sie haben mit CS4 oder CS5 jetzt so einen unified Mode eingefuehrt - damit es unter Windows besser wirkt. Dieser Unified Mode ist aber unter OS X eine Katastrophe
Wieso ist der unter OS X eine Katastrophe? Nur weil man es unter OS X gewöhnt ist dass Programme 1000 kleine Fenster aufmachen? Verstehe ich nicht so ganz...
Davon abgesehen: solche Anpassungen ist eh OK, vor allem wenn man beide Optionen auf beiden Plattformen verwenden kann. Ist dann aber auch wieder plattformunabhängiger Code, weil ja eben beide Programm-Versionen beide Optionen anbieten.Oder unter OS X mit MS Office ist es so, dass teilweise Funktionalitaet ueber das Menu (was unter Windows entfernt wurde, technisch bedingt aber unter OS X nicht entfernbar ist) und Ribbons erreichbar und teilweise nur ueber eins von beiden - da eine 1:1 Umsetzung nicht moeglich war.
Naja, die Ribbons hätte man ja gleich lassen können. Dann wäre der einzige Unterschied dass die OS X Version zusätzlich ein Menu hat. Wobei man das Menu bis auf die Standard-Einträge (wie zum Programm beenden etc.) ja auch hätte leer lassen können.
Ich sehe da jetzt kein echtes Problem.Natuerlich funktioniert es - aber zB SDI <-> MDI ist halt doch ein Unterschied.
Öh. SDI <-> MDI gibt doch das Programm vor, und nicht die Plattform
Und auf Tablets ist platzbedingt sowieso alles anders.
Ja, nicht nur platzbedingt. Auch Touchscreen ohne Tasten statt Keyboard + Maus machen nen riesigen Unterschied.
Wenn man eine GUI soweit anpasst dass sie auf Tablets gut bedienbar ist, dann ist das für mich eine komplett neue GUI. D.h. zwei verschiedene Projekte - bzw. ein kompletter Fork des GUI Teils.
Dass man da dann kaum noch gemeinsamen Code im GUI Teil hat, sollte klar sein.
-
hustbaer schrieb:
Stell dir mal vor Photoshop, 3D Studio Max oder auch MS Word/Excel würden unter OS X komplett anders aussehen und zu bedienen sein als unter Windows. Fändest du das wirklich gut? Ich nicht.
Wieviele Nutzer wechseln zwischen diesen Plattformen hin und her? Wohl eher sehr sehr sehr wenige.
Ich würde auch empfehlen, unterschiedliche Views für die Plattformen zu verwenden, damit sich die Views jeweils gut in die Plattform integrieren. Die meisten Benutzer bleiben bei ihrer Plattform und sind daher daran interessiert, dass sich die View gut in ihre Plattform integriert und die bekannten Konzepte von dort verwendet.
Plattformunabhängige GUI Bibliotheken haben oft das Problem, dass sie auf einen Nenner reduzieren. Das Hinzufügen von Funktionalität für eine einzige Plattform führt meistens eher zu Problemen.
Aus Sicht der Usability würde ich daher sagen, sollte man für jede Plattform eine eigene View entwickeln. Das mag aufwendiger sein, aber der Aufwand spielt aus Sicht der Usability keine Rolle.
Was dann der Chef entscheidet, ist allerdings eine ganz andere Sache
Grüssli
-
Wieviele Nutzer wechseln zwischen diesen Plattformen hin und her? Wohl eher sehr sehr sehr wenige.
Wie viele User wechseln mal den Job? Dabei kann es vorkommen dass die alte Firma Windows verwendet hat, und die neue Mac. Muss dann für den Grafiker Photoshop und 3DS Max komplett anders sein, nur weil es jetzt auf Mac läuft? Sehe ich nicht ein.
Genau so muss für die Tippse Office nicht anders sein, nur weil es jetzt auf Mac läuft.mMn. muss man hier auch zwischen kleinen Tools wie einem Text-Editor ala Notepad, einen Zip-Programm etc. und wirklich grossen Programmen unterscheiden. Bei den kleinen Tools macht es Sinn dass das Ding sich gut ins OS integriert, das Look & Feel genau passt etc.
Bei wirklich grossen Programmen ist mMn. der Aufwand das Programm zu beherrschen grösser als der Aufwand soweit mit dem OS umgehen zu können dass man das Programm starten und verwenden kann.Die wenigsten Benutzer von grossen Programmen oder Programmpaketen sind OS-Experten die "ihr" OS in- und auswendig kennen. Die sind Programm-Experten die halt Photoshop, 3DS-Max, Excel, Access, SAP etc. können. Macht auch Sinn. Sie arbeiten nämlich nicht mit dem OS, sondern mit dem Programm.
Dravere schrieb:
Ich würde auch empfehlen, unterschiedliche Views für die Plattformen zu verwenden, damit sich die Views jeweils gut in die Plattform integrieren. Die meisten Benutzer bleiben bei ihrer Plattform und sind daher daran interessiert, dass sich die View gut in ihre Plattform integriert und die bekannten Konzepte von dort verwendet.
Bei kleineren Tools: ja. Bei grossen Programmen? mMn. klar nein. Warum siehe oben: der Aufwand Programm X zu lernen ist sowieso grösser als der Aufwand OS Y zu lernen.
Dravere schrieb:
Plattformunabhängige GUI Bibliotheken haben oft das Problem, dass sie auf einen Nenner reduzieren. Das Hinzufügen von Funktionalität für eine einzige Plattform führt meistens eher zu Problemen.
Hm. Hast du mal ein paar Beispiele?
Dravere schrieb:
Aus Sicht der Usability würde ich daher sagen, sollte man für jede Plattform eine eigene View entwickeln. Das mag aufwendiger sein, aber der Aufwand spielt aus Sicht der Usability keine Rolle.
Halte ich wie schon gesagt für nicht unbedingt wünschenswert. Und ist mMn. auch reichlich realitätsfremdes Wunschdenken.
Und: aus Sicht der Usability spielt es eine Rolle wie gut das Ding funktioniert, wie gut es bedienbar ist, wie viele (wenige) Bugs es hat etc. Und mit der selben Manpower hat man da wohl bessere Chancen was gut verwendbares hinzubekommen wenn man nur eine GUI baut die zum grossteil plattformunabhängig ist, als wenn man zwei oder drei komplett verschiedene GUIs baut.Und nochmal: ich meine nicht Unterschiede wie Desktop vs. Tablet vs. Smart-Phone. Dabei sind die Unterschied viel zu gross, da muss man eigene GUIs bauen damit was sinnvolles rauskommt. Ich meine Windows Desktop vs. OS X Desktop vs. Linux Desktop.
-
hustbaer schrieb:
Wieso ist der unter OS X eine Katastrophe?
Weil es ein fremdes Konzept ist.
Setz mal Grafiker vor den Unified Mode. Die sind verloren.Natuerlich ist es billiger ueberall die selbe GUI zu haben - aber wirklich gute Software passt sich der Platform an.
OpenOffice zB ist auf OS X Schrott. Dadurch dass alle Anwendungen (Writer, Calc, Presenter,...) Teil einer fetten Anwendung (OOo) sind - ist es nicht moeglich csv Dateien per Drag&Drop auf das Dock Icon zu oeffnen.
Oder NetBeans (prinzipiell die meisten Java Anwendungen) nach dem Windows 7 Release haben immer ein 2. Icon in der Taskleiste erstellt wenn man sie gestartet hat (da das Taskleisten Icon nur eine andere Anwendung gestartet hat).
Oder fangen wir mit so simplen Sachen an wie die Menue Struktur. Unter Windows hast du den About Dialog unter Hilfe waehrend er unter OS X unter <AppName> ist. Das MenueElement Datei heisst unter OS X zB auch Ablage.
Es gibt millionen so feiner Unterschiede. Und die Anwender wechseln oefters Anwendung innerhalb einer Plattform aber selten Plattform mit der Anwendung. Deshalb ist es wichtig dass die Software sich in die Plattform integriert.
-
hustbaer schrieb:
Die wenigsten Benutzer von grossen Programmen oder Programmpaketen sind OS-Experten die "ihr" OS in- und auswendig kennen. Die sind Programm-Experten die halt Photoshop, 3DS-Max, Excel, Access, SAP etc. können. Macht auch Sinn. Sie arbeiten nämlich nicht mit dem OS, sondern mit dem Programm.
Das ist leider falsch.
Der Anwender hat Erwartungen an eine Anwendung. Wenn ich OS X verwende, dann habe ich andere Erwartungen an die Anwendung als wenn ich Windows verwende.
Der Anwender will naemlich nicht lernen. Er benutzt Muster nach denen er vorgeht. Und diese Muster sind definiert durch die Plattform die er benutzt. Denn die Anwendungen dort haben ihm ein gewisses Verhalten angelernt.
Deshalb sind solche Aenderungen wie Microsoft mit den Ribbons eingefuehrt hat auch prinzipiell problematisch. Natuerlich lernt der Anwender irgendwann die neuen Muster - aber wenn laengere Zeit engeren Kontakt mit normalen Usern hast, wirst du schnell merken welche Anwendungen sie als komisch oder verwirrend empfinden. Naemlich genau die Anwendungen die mit den angelernten Mustern brechen.
Wir haben in der Firma zB eine Anwendung die auf allen Plattformen laeuft und durchaus seine eigene interne Logik gut umsetzt. Aber es haelt sich eben nicht an die Plattform Standards und deshalb kann diese Software niemand leiden. Viele kommen damit irgendwie klar, aber beliebt ist sie nicht.
-
hustbaer schrieb:
Wie viele User wechseln mal den Job? Dabei kann es vorkommen dass die alte Firma Windows verwendet hat, und die neue Mac. Muss dann für den Grafiker Photoshop und 3DS Max komplett anders sein, nur weil es jetzt auf Mac läuft? Sehe ich nicht ein.
Genau so muss für die Tippse Office nicht anders sein, nur weil es jetzt auf Mac läuft.Halte ich immer noch für sehr sehr sehr unwahrscheinlich. Das wird seltener passieren, als dass du Applikationen wechselt. Die meisten Benutzer wechseln das OS kein einziges Mal im Leben. Ein paar vielleicht ein zwei Mal. Applikationen wechseln sie dabei aber fast jährlich, wenn nicht noch mehr.
hustbaer schrieb:
mMn. muss man hier auch zwischen kleinen Tools wie einem Text-Editor ala Notepad, einen Zip-Programm etc. und wirklich grossen Programmen unterscheiden. Bei den kleinen Tools macht es Sinn dass das Ding sich gut ins OS integriert, das Look & Feel genau passt etc.
Sehe ich ehrlich gesagt genau umgekehrt. Gerade kleine Tools, welche einen kleineren Funktionsumfang haben, können auch mal etwas exotischer sein. Wegen des kleineren Funktionsumfanges findet man sich trotzdem schnell zurecht.
hustbaer schrieb:
Bei wirklich grossen Programmen ist mMn. der Aufwand das Programm zu beherrschen grösser als der Aufwand soweit mit dem OS umgehen zu können dass man das Programm starten und verwenden kann.
Die wenigsten Benutzer von grossen Programmen oder Programmpaketen sind OS-Experten die "ihr" OS in- und auswendig kennen. Die sind Programm-Experten die halt Photoshop, 3DS-Max, Excel, Access, SAP etc. können. Macht auch Sinn. Sie arbeiten nämlich nicht mit dem OS, sondern mit dem Programm.
Das siehst du meiner Meinung nach falsch. Es geht nicht darum, das OS zu beherrschen, sondern gewissen Standards eines OS zu folgen. Diese Dinge werden von den Benutzer völlig intuitiv gelernt mit der Verwendung eines OS. Es gibt einfach gewisse Abläufe, welche du auf Windows vorfinden wirst und andere auf OS X. Ein Programm soll sich dem OS anpassen.
Einfaches Beispiel um etwas konkreter zu werden. Bei den bereits erwähnten Shortcuts. Wie ging das nochmals mit Copy&Paste per Tastatur unter Mac OS X und Windows? Die OS X Nutzer würden dich wahrscheinlich steinigen, wenn du Control+X/C/V verwenden würdest
Und die Tippse, welche nun schon seit 10 Jahren auf Mac OS X arbeitet, sich aber mit Computer eigentlich nie richtig auseinander gesetzt hat, weiss ganz genau, wie sie Text von A nach B kriegt. Und das wird plötzlich nicht funktionieren ...hustbaer schrieb:
Bei kleineren Tools: ja. Bei grossen Programmen? mMn. klar nein. Warum siehe oben: der Aufwand Programm X zu lernen ist sowieso grösser als der Aufwand OS Y zu lernen.
Ein OS lernen die Leute intuitiv über die Zeit der Nutzung mit allen möglichen Programmen, welche sich darauf befinden. Wenn du damit brichst, wird sich das Programm in diesem OS immer als fremd anfühlen. Die Benutzer sind keine Experten, die meistens sind Laien! Du gehst davon aus, dass alle Benutzer irgendwelche hoch ausgebildete Fachkräfte bei einem Programm sind. Das sind sie aber meistens überhaupt nicht. Geh mal die Leute im Business fragen, was sie von Excel oder Word wissen und können. Meistens kennen sie die einfachsten Shortcuts nicht. Diese Leute arbeiten dafür seit Jahren auf einem OS und kennen sich mit dem OS etwas aus, bzw. kennen die Standards auf diesem OS. Daher ist es sehr empfehlenswert, wenn man diese Standards übernimmt.
Wenn du ein neues Programm bringst, kennen sich die Leute dank diesen Standards bereits etwas aus.
hustbaer schrieb:
Dravere schrieb:
Plattformunabhängige GUI Bibliotheken haben oft das Problem, dass sie auf einen Nenner reduzieren. Das Hinzufügen von Funktionalität für eine einzige Plattform führt meistens eher zu Problemen.
Hm. Hast du mal ein paar Beispiele?
Ist mehr eine persönliche Erfahrung. Die Bibliotheken emulieren zum Teil Dinge auf anderen Systemen, das wirkt oftmals fremdartig auf diesen. Spezifische Dinge eines OS werden nicht implementiert. wxWidgets bietet z.B. nichts an, um die Taskbar Extensions in Aero zu verwenden. Heisst man muss hier selber Code einfügen, welcher man dann wieder mit Preprocessor Anweisungen nur an Windows binden muss. Über die Zeit kann das recht mühsam werden und die Strukturen passen nicht auf das jeweilige OS. Man hat mehr und mehr das Gefühl, dass man die Dinge irgendwie zusammenklebt, statt das Programm richtig zusammenzuschrauben.
hustbaer schrieb:
Und: aus Sicht der Usability spielt es eine Rolle wie gut das Ding funktioniert, wie gut es bedienbar ist, wie viele (wenige) Bugs es hat etc.
Dann haben wir eindeutig eine unterschiedliche Definition von Usability. Wie gut das Programm bedienbar ist, spielt bei der Benutzungsfreundlichkeit keine Rolle? Wie um alles in der Welt definierst du Usability?
hustbaer schrieb:
Und mit der selben Manpower hat man da wohl bessere Chancen was gut verwendbares hinzubekommen wenn man nur eine GUI baut die zum grossteil plattformunabhängig ist, als wenn man zwei oder drei komplett verschiedene GUIs baut.
Dieses Argument gilt im Bereich der Usability nicht. Aus Sicht der Usability kannst du nicht Dinge verwerfen, nur weil es mehr Aufwand bedeutet. Wenn du genügend Zeit investierst, kommen da auch bessere GUIs raus. Aus der Sicht der Techniker gilt das Argument, weil diese faul sind. Zudem gilt das Argument auch aus der Sicht des Chefs, weil dieser das womöglich nicht finanzieren will. Durch die Techniker und den Chef leidet allerdings die Usability des Programmes.
Grüssli
