Compiler



  • @Tyrdal sagte in Compiler:

    @DocShoe Wie kann denn Qt zu teuer sein bei den Kosten und Zuständen, die du schilderst? Das versteh ich jetzt gar nicht.

    Ist ja nicht so, dass man heute teure Lizenzen (Qt) kauft, und die angemerkten Kosten und Zustände sind dann morgen weg ...



  • Stimmt, aber durch immer gleich weitermacxhen ändert sich erst recht nichts. Und man kann ja richtigrum anfangen, also zuerst Logik von Gui trennen. Dann wird es einfacher den Rest Schrittweise zu machen.



  • Wir haben unsere Software auch vor Jahren schon vom BCB auf Qt umgestellt. Das lief aber prinzipiell auf neu schreiben hinaus. Das ist schon ein ziemlicher Aufwand, der sich aber lohnt. Das lief dann ungefähr so, dass Einer aus dem Team den Support für den Borland / Embarcadero Kram übernommen hat (meist ich) und die Anderen das Neu schreiben. Als das dann lief bin ich auch auf Qt umgestiegen. Wir hatten aber immer schon recht wenig reine Delphi Anteile. Das meiste war schon in C++.



  • @Braunstein sagte in Compiler:

    Wir haben unsere Software auch vor Jahren schon vom BCB auf Qt umgestellt. Das lief aber prinzipiell auf neu schreiben hinaus.

    Neu schreiben ist extrem gefährlich, insbesondere bei großen Projekten. Neu geschrieben => neue Bugs. Außerdem sind alle Entwickler, die "neu schreiben", dann die ganze Zeit nicht dabei, neue Features für das Produkt zu entwickeln. Irgendwann ist dann Zeit für ein neues Release, das z.B. 1 oder 2 Jahre später rauskommt und für den Kunden keinen Mehrwert bietet, aber dafür möglicherweise neue Bugs enthält oder auch alte Bugs, die schon lange gefixt waren, wieder enthält (weil z.B. für diesen Fall nie ein Test exisitert hat).

    Ich möchte also generell davor warnen, das auf die leichte Schulter zu nehmen.

    Natürlich ist oft irgendwo ein Refactoring oder gar neu schreiben nötig, aber bitte nicht gleich alles auf einmal. Das geht schief.



  • @wob sagte in Compiler:

    Neu schreiben ist extrem gefährlich, insbesondere bei großen Projekten. Neu geschrieben => neue Bugs

    Da wir im letzten Jahr fast so was gemacht haben, kann ich das nur bestätigen. Ein Jahr kaum neue Features und hinterher ein paar unschöne Bugs, die es vorher nicht gab.

    Dafür sind wir aber jetzt schneller: Schneller beim implementieren neuer Features, schneller bei Anpassungen von altem Code und frei irgendwann mal eine neue GUI drauf zu setzen (wir machen noch klassisch Desktop, aber ein Webinterface soll auch irgendwann mal her).

    In der Summe war es bei uns nötig um die alte Basis wartbar und Teile testbarer zu machen.

    Ich kann vollkommen verstehen, wenn irgendwann der Schmerz so groß ist, dass man so ein Projekt angeht und es kann sich lohnen.



  • Wer seine Projekte nicht in kurzen Zyklen an neue Entwicklungen (Compiler, Bibliotheken etc. und nicht zuletzt neuen Erkenntnissen) anpasst hat natürlich nach einigen Jahrzehnten mit einem erheblichen Reparatur- und Erweiterungsstau zu kämpfen.
    Nicht nur, dass es sich die Lieferanten von Tools gerne bezahlen lassen, wenn ein Kunde einfach nicht auf den alten Plunder verzichten kann (man erinnere sich an die jahrelange weiter Nutzung und Wartung von Windows XP in den Behörden, hat Millionen verschlungen), sondern es gehen bisweilen auch gute Entwickler von der Fahne, da sie ihre persönliche Weiterentwicklung durch Nicht Einsatz von neuen Werkzeugen eingeschränkt sehen.
    Es hat sich in einigen Unternehmen bewährt, durch permanente (in kurzen Zeitabständen) Modernisierung seiner Projekte einerseits seine Mannschaft zu motivieren, sondern auch so etwas wie „Wir müssen alles ganz schnell umstellen, ab Zeitpunkt X läuft unsere Anwendung nicht mehr mit Y“ zu vermeiden.
    Umso länger man eine Modernisierung aufschiebt, umso teurer wird diese. Irgendwann ist es dann gar nicht mehr möglich und man wird von anderen überholt.
    <Klugscheiß ende>
    @Traugott Mein Tipp an Dich, halt Dich nicht mit dem alten Kram auf. Nutze ein modernes Betriebssystem und einen aktuellen Compiler.



  • @wob sagte in Compiler:

    Neu schreiben ist extrem gefährlich, insbesondere bei großen Projekten. Neu geschrieben => neue Bugs.

    Natürlich ist oft irgendwo ein Refactoring oder gar neu schreiben nötig, aber bitte nicht gleich alles auf einmal. Das geht schief.

    Wenn man das GUI Framework wechselt muss man viel neu schreiben. Außerdem ist das eine gute Möglichkeit Code zu entschlacken. Wenn man viele Jahre an einen Programm schreibt neigt der Code manchmal dazu unübersichtlich zu werden. Besonders wenn die Entwickler wechseln.
    Klar erzeugt man neue Bugs. Das passiert beim Einbau neuer Features in Bestandssoftware aber auch.
    Wir habens gemacht und es hat funktioniert.



  • @Tyrdal sagte in Compiler:

    @DocShoe Wie kann denn Qt zu teuer sein bei den Kosten und Zuständen, die du schilderst? Das versteh ich jetzt gar nicht.

    Naja, im Moment haben wir keine laufenden Kosten, es funktioniert ja alles mehr oder weniger.
    Mit der Debuggerschwäche kommen wir halbwegs klar. Und ich denke, dass auch das VS Studio und Qt ihre Macken haben.



  • Wenn grad alles so ruhig läuft, ist das ja die Gelegenheit ein Reengineering der angesprochenen Anwendung vorzunehmen.
    Wenn Ihr Eure Anwendung noch nicht aufgegeben habt, also diese noch weitere Jahre verkaufen wollt, müsst Ihr da sowieso mal ran.



  • @DocShoe sagte in Compiler:

    Mit der Debuggerschwäche kommen wir halbwegs klar. Und ich denke, dass auch das VS Studio und Qt ihre Macken haben.

    Aber nicht so heftige wie du sie oben beschrieben hast. Im Großen und Ganzen funktionieren die beiden schon gut.



  • Ich verwende zum Programmieren in Qt lieber den Creator. Ich finde ihn besser benutzbar als das Visual Studio. Außerdem ist man dann auch nicht mehr an das OS gebunden. Ich selber arbeite auf Windows. Meine Kollegen auf Linux. Alles am gleichen Projekt ohne größere Probleme.


Anmelden zum Antworten