Verwendung von Qt
-
Qt fährt seit einiger Zeit die kommerziellen Geschütze auf. Ich würde mir das gut überlegen, auf welches Pferd ich setze, erst recht wenn ich nur GUI brauche.
-
Zweifler schrieb:
Qt fährt seit einiger Zeit die kommerziellen Geschütze auf. Ich würde mir das gut überlegen, auf welches Pferd ich setze, erst recht wenn ich nur GUI brauche.
Quellen?
Ansonsten pure Behauptung ohne relevanz
-
Nach sehr schlechter Erfahrung mit mehreren "historisch gewachsenen" Anwendungen, die nur mit viel Mühe umstellbar sind, würde ich persönlich immer wenn eine lange Produktpflege geplant ist (Bei kurzlebigen Projekten eher nicht) eine saubere Schichtentrennung nutzen, und Bibliotheken jenseits von std/boost nur in solchen Schichten nutzen, die diese auch wirklich benötigen.
Ja, auch mit sauberer Schichtentrennung ist ein umschreiben auf andere Bibliotheken noch viel Aufwand, aber mit Sicherheit immer noch leichter als den Code als ganzes Umstellen zu müssen.
-
Wo gibt es denn bitte keine historisch gewachsene Software? Niemand kann irgendwas groß voraus und vor allem nicht für lange Zeit planen. Also planen kann man schon, aber genau wie im Leben wird dies mit ziemlich hoher Wahrscheinlichkeit nicht so wie geplant eintreffen. Sein Leben kann man ja auch nicht planen, obwohl es immer wieder Menschen versuchen. Das ist genauso unsinnig, wie für die Rente zu leben, die man vielleicht nie erreicht oder wo man gar keinen Bock mehr hat die verpassten Dinge nachzuholen. Man ist nur einmal 20, 30, 40, 50 usw. Mit der Rente fängt auch so langsam des rechts einordnen an, wo es dann zur Ausfahrt vom Leben geht.
Ein wenig planen ist ok, aber verplant euch nicht. Ihr lebt im Jetzt und Hier und danach sollte man auch handeln.
-
Verplant schrieb:
Wo gibt es denn bitte keine historisch gewachsene Software?
Es gibt viele Firmen, die nicht Produkt, sondern Projektentwicklung machen. Bei letzterer mag man auch mit solchen Anwendungen konfrontiert werden, muss sich aber nicht um deren Zukunft Gedanken machen.
Verplant schrieb:
Niemand kann irgendwas groß voraus und vor allem nicht für lange Zeit planen.
Wenn man Produktentwicklung betreibt (wie z.B. in meiner jetzigen und letzten Firma der Fall), kann man so etwas durchaus zu gewissen Grad planen. Es geht auch nicht darum jede Eventualität zu berücksichtigen, wohl aber sollte man die Software wartbar halten. Und da kommt durchaus eine Schichtentrennung entgegen, bei der man auch von vorne herein bestimmte Frameworks in einzelnen Schichten ausschließen kann - auch wenn dies eine Konvertierung an den Schnittstellen der Schichten bedeutet.
Leider wird häufig, gerade bei kleineren Firmen, nicht einmal eine rudimentäre Schichtentrennung gemacht, falls auch nur ein Framework ausfällt ist der Aufwand der Umstellung häufig enorm. Dabei ist eine solche Trennung nicht zwangsweise mehr Arbeit (vom Anfang einmal abgesehen), da man durch die Trennung den Code auch häufig verständlicher hält und eher mal weitere Funktionalitäten hinzufügen kann, die vorher nicht geplant waren - und selbst wenn man die Software gänzlich portieren muss, ist es leichter mit solchen Trennungen.
Und in beiden Firmen gab es einen solch harten Bruch (Wegfall bestimmter Frameworks etc.). Teilweise wurde einfach das Framework trotz eingestellter Wartung noch viele Jahre verwendet (Es läuft ja) und wenn es dann aber mit einem OS-Wechsel nicht mehr läuft kann dies von heute auf morgen das aus einer Firma bedeuten. Nichts planen ist halt auch keine Lösung, und umso mehr Abhängigkeiten man ungekapselt verwendet, bzw. nicht zumindest auf einzelne Schichten begrenzt, umso schlimmer können die Auswirkungen sein.
Als Entwickler kann mir das zwar eigentlich egal sein (Notfalls halt die Stelle wechseln), ich identifiziere mich aber zu einem gewissen Teil mit der Firma in der ich arbeite.
Verplant schrieb:
Ein wenig planen ist ok, aber verplant euch nicht. Ihr lebt im Jetzt und Hier und danach sollte man auch handeln.
Und wo verplant man sich wenn man Abhängigkeiten auf Codebereiche begrenzt?
-
OMG Schichtentrennung und das noch mit Frameworks die eh schon über-generalisiert sind. Wenn das nicht alles 1a dokumentiert ist, dann kann solchen eine übertriebene Generalisierung kräftig nach hinten losgehen. Das ist dann kein von Menschen mehr lesbarer Code, da kann man kaum noch den Programmfluss nachvollziehen was schon bei zu stark verdesignpatternder Software der Fall ist.
Man kann doch nicht mal planen ob eine Software-Bude die nächsten fünf Jahre überleben wird, oder wie viele Leute kommen und gehen in der Entwicklungsabteilung.
Es mag so sein, dass dies alles in deiner Firma klappt, für die Regel halte ich solche Firmen und somit solche große Planungsoptimismus nicht. Linux ist ein gutes Beispiel wie ohne viel Planung ein großartiges Stück Software über Jahre wachsen kann. Ich glaube dass ist sogar eines der größten und meist frequentiertesten Software-Projekte überhaupt.
Große Software braucht keine große Planung.
-
Verplanter schrieb:
OMG Schichtentrennung und das noch mit Frameworks die eh schon über-generalisiert sind. Wenn das nicht alles 1a dokumentiert ist, dann kann solchen eine übertriebene Generalisierung kräftig nach hinten losgehen. Das ist dann kein von Menschen mehr lesbarer Code, da kann man kaum noch den Programmfluss nachvollziehen was schon bei zu stark verdesignpatternder Software der Fall ist.
Was hat "verdesignpatternder" Software oder schlecht lesbarer Code mit Schichtentrennung zu tun? Hast du überhaupt schon einmal eine saubere Schichtentrennung erlebt?
Verplanter schrieb:
Man kann doch nicht mal planen ob eine Software-Bude die nächsten fünf Jahre überleben wird, oder wie viele Leute kommen und gehen in der Entwicklungsabteilung.
Ach, dann lieber "und nach mir die Sintflut"? Schöne Taktik. Ich habe erlebt was durch eine solche Herangehensweise passiert, gerade weil man meinte das Schichtentrennung so aufwändig wäre. Wenn man diese von vorne herein vorsieht, ist es aber nur initial etwas mehr Planungsaufwand, und richtig gemacht führt es jedenfalls nicht zu schlechter lesbaren Code.
-
asc schrieb:
Verplanter schrieb:
OMG Schichtentrennung und das noch mit Frameworks die eh schon über-generalisiert sind. Wenn das nicht alles 1a dokumentiert ist, dann kann solchen eine übertriebene Generalisierung kräftig nach hinten losgehen. Das ist dann kein von Menschen mehr lesbarer Code, da kann man kaum noch den Programmfluss nachvollziehen was schon bei zu stark verdesignpatternder Software der Fall ist.
Was hat "verdesignpatternder" Software oder schlecht lesbarer Code mit Schichtentrennung zu tun? Hast du überhaupt schon einmal eine saubere Schichtentrennung erlebt?
Don't feed the trolls
Schichtentrennung und/oder Modularisierung erzeugt - wenn sie richtig gemacht ist, d.h. die Interfaces der Schichten/Module klar, einfach und erweiterbar sind - meiner Erfahrung nach durch ihre bloße Anwesenheit schon lesbareren Code. Einfach weil Aufrufe in andere Schichten/Module sofort als solche zu erkennen sind. Da die Änderung von Modulinterfaces recht "teuer" ist, überlegt man sich 2x ob man diese für jede Kleinigkeit gleich ändern muss bzw investiert Zeit, die Interfaces gescheit zu machen - ein disziplinarischer Effekt stellt sich bei den Entwicklern ein.
Ansonsten bin ich auch ein Verfechter der Meinung, dass Bibliotheken in Schichten oder Modulen, in denen man sie nicht unbedingt braucht, nichts zu suchen haben.
Aber keine Regel ohne Ausnahme: Wenn eine Anwendung zu 90% aus GUI besteht, würde ich auch im traurigen Rest der Einfachheit halber z.B. auf Qt setzen. Sicherlich aber nicht im umgekehrten Fall.
-
Abgesehen davon, dass es wahrscheinlich ein Troll ist, kommt die Meinung, Schichtentrennung, Design Patterns usw. würden zu schlechter lesbarem Code führen fast daher, dass man keine Ahnung hat. Natürlich kann es schon mal passieren, dass man nicht sofort sieht, wie der Code funktioniert. Ja und? Nicht alles ist trivial, wenn die Software umfangreicher ist, dann muss man sich einigen Stellen reindenken. Die "Alternative", also falls man wirklich überall sofort sehen würde, was passiert, wäre, dass man auch an jeder Stelle das komplette Wissen über jedes Detail zigfach dupliziert und überhaupt nicht kapselt oder generalisiert. Aber ob man dann wirklich irgendwas besser sieht oder versteht wag ich sehr stark zu bezweifeln.
Wir hatten in der Firma auch so einen Bruch und haben ein Framework durch Qt ausgetauscht. War sehr viel Arbeit und hat noch Jahre gedauert, bis jedes Feature wieder funktioniert hat. Das war schon sehr hart. Da kann man sich durchaus schon mal im voraus überlegen, ob sich sowas lohnt.
Bei Qt ist die Gefahr aber denke ich geringer. Das andere war ein kommerzielles Framework, das kaum jemand verwendet hat (weiß gar nicht, wie das hieß), das auch nicht so gut war und irgendwann eingestampft wurde. Qt ist zumindest Open Source und viel bekannter und wird von vielen verwendet. Da ist die Wahrscheinlichkeit, dass es aufgegeben wird viel geringer.
-
Mechanics schrieb:
Bei Qt ist die Gefahr aber denke ich geringer. Das andere war ein kommerzielles Framework, das kaum jemand verwendet hat (weiß gar nicht, wie das hieß), das auch nicht so gut war und irgendwann eingestampft wurde. Qt ist zumindest Open Source und viel bekannter und wird von vielen verwendet. Da ist die Wahrscheinlichkeit, dass es aufgegeben wird viel geringer.
Ich würde jetzt gar nicht mal nur die Gefahr sehen, dass ein Framework eingestampft wird. Eine in den letzten Jahre vermehrt auftretende Anforderung dürfte z.B. sein, seine Programme mobil verfügbar zu machen.
Hat man große Teile seiner Codebasis plattform- und frameworkunabhängig gehalten, dürften einem solche Fälle viel leichter fallen.
-
Morle schrieb:
Ich würde jetzt gar nicht mal nur die Gefahr sehen, dass ein Framework eingestampft wird. Eine in den letzten Jahre vermehrt auftretende Anforderung dürfte z.B. sein, seine Programme mobil verfügbar zu machen.
Hat man große Teile seiner Codebasis plattform- und frameworkunabhängig gehalten, dürften einem solche Fälle viel leichter fallen.ganz im gegenteil ...
qt bietet mobile protierung ...
qt unterstützt z.b android ...
wird dort auch zur entwicklung genutzt soweit ich weiß ...