Ist RemObjects die Zukunft von Delphi?

[Phoenix]

Zitat:

Zitat von Furtbichler (Beitrag 1250888)

Zitat:

Zitat von p80286 (Beitrag 1250887)

Zunächst muß der Code funktionieren, dann sollte er wartbar und verständlich sein!

Falsch. Zunächst sollte der Code verständlich und wartbar sein.

Falsch. Die Reihenfolge ist: Make it work, make it right, make it fast.

Hier nur einmal drei gute von mehreren hundert Artikeln zu dem Thema:
http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast
http://cbednarski.com/articles/make-...-make-it-fast/
http://agileinaflash.blogspot.de/200...e-it-fast.html

Und das hat nichts mit mangelndem Qualitätsbewusstsein zu tun.
Zuerst muss ein Problem erstmal grundsätzlich gelöst sein, bevor man sich auf schöne/richtige Lösungen konzentriert.

Es bringt Dir nämlich genau nichts, wenn Du das Problem erst 'schön' angehst, und dann Deinen schönen, lesbaren, wartbaren Code Stundenlang weiterhin schön les- und wartbar herumschubbst, und es am Ende des Tages immer noch nicht funktioniert.

Wenn es funktioniert, dann ist der Code in aller Regel auch ziemlich schnell aufgeräumt. Wenn er dann aufgeräumt ist kann man noch anfangen, ihn zu optimieren ohne ihn wieder kaputt zu machen.

[Sherlock]

Zitat:

Zitat von Phoenix (Beitrag 1250895)

Und das hat nichts mit mangelndem Qualitätsbewusstsein zu tun.
Zuerst muss ein Problem erstmal grundsätzlich gelöst sein, bevor man sich auf schöne/richtige Lösungen konzentriert.

Es bringt Dir nämlich genau nichts, wenn Du das Problem erst 'schön' angehst, und dann Deinen schönen, lesbaren, wartbaren Code Stundenlang weiterhin schön les- und wartbar herumschubbst, und es am Ende des Tages immer noch nicht funktioniert.

Wenn es funktioniert, dann ist der Code in aller Regel auch ziemlich schnell aufgeräumt. Wenn er dann aufgeräumt ist kann man noch anfangen, ihn zu optimieren ohne ihn wieder kaputt zu machen.

Nein. In einer Firma, deren Geschäftsführung schnelle Lösungen erwartet, und auch noch viele Produkte oder Probleme vor sich her wälzt. Ist nach der erfolgreichen Implementierung keine Zeit mehr es dann richtig zu machen. Darum sollte man es im wirklichen Leben lieber gleich richtig machen, sonst schiebt man die garstigen, unkommentierten, un-ge-unit-testeten Tricksereien bis zum Sankt Nimmerleins Tag vor sich her. Und das kann doch keiner wollen.

Sherlock

[jensw_2000]

Trifft doch alles irgendwie zu. Und ich unterstelle mal, dass wir alle schon ein paar Spaghetti-Code Projekte geschrieben haben. :duck:

Das Ansatz - erst funktionell, dann gut - ist ein Kernprinzip beim Testdriven-Development.
Wer nicht testet, muss halt von vornherein so strukturiert und übersichtlich programmieren, dass er selbst jederzeit alles überblicken kann. Sonst besteht eben die Gefahr, dass man Schwachstellen ausliefert oder große Teile des Codes übersichtlicher neu schreiben muss.

[sh17]

Zitat:

Zitat von Sherlock (Beitrag 1250892)

Oh, wie ich mir wünsche, Beiträge bewerten zu dürfen!

Ich auch

[Lemmy]

Zitat:

Zitat von Sherlock (Beitrag 1250896)

Nein. In einer Firma, deren Geschäftsführung schnelle Lösungen erwartet, und auch noch viele Produkte oder Probleme vor sich her wälzt.

Gibt es auch andere Firmen/Geschäftsführer? Die mal ausgenommen, die kurz vor der Insolvenz stehen bzw sich darin befinden?

Zitat:

Zitat von Sherlock (Beitrag 1250896)

Ist nach der erfolgreichen Implementierung keine Zeit mehr es dann richtig zu machen.

das ist eine Definitionsfrage. Eine erfolgreiche Implementierung ist eben NICHT erreicht, wenn das Programm kompiliert und ein manueller Kurztest des Entwicklers die neue Funktion nicht zum abschmieren bringt.

[jensw_2000]

Zitat:

Zitat von sh17 (Beitrag 1250899)

Zitat:

Zitat von Sherlock (Beitrag 1250892)

Oh, wie ich mir wünsche, Beiträge bewerten zu dürfen!

Ich auch

So daneben fand' ich meinen Post eigentlich nicht. :duck:
Ok, dann bin ich eben der Einzige, der schon einmal ein Update auf eine "stark überarbeitete Version 2.0" verkauft hat, und dabei eigentlich "nur" den Spaghetticode entwirrt hat. Friede!

[p80286]

[QUOTE=jensw_2000;1250905]

Zitat:

Zitat von sh17 (Beitrag 1250899)

Zitat:

Zitat von Sherlock (Beitrag 1250892)

Oh, wie ich mir wünsche, Beiträge bewerten zu dürfen!

Ich auch

Ich würde auch gerne bewerten!

Zitat:

Zitat von jensw_2000 (Beitrag 1250905)

Ok, dann bin ich eben der Einzige, der schon einmal ein Update auf eine "stark überarbeitete Version 2.0" verkauft hat, und dabei eigentlich "nur" den Spaghetticode entwirrt hat. Friede!

Nö bist Du nicht. Sobald wieder einmal ein wenig Pflege ansteht, wird auch aufgehübscht. Mit etwas (zeitlichem) Abstand fällt dann auch die eine oder andere nicht so optimale Stelle auf.

Gruß
K-H

[jaenicke]

Zitat:

Zitat von Furtbichler (Beitrag 1250882)

Dies nun als Argument anzuführen, das Linq/Delphi/You name schlecht ist, ist schlecht.

Dass es schlecht sei, habe ich ja auch nicht geschrieben. Ich nutze es ja selbst ganz gerne mal (wohldosiert...).

Ich meinte damit nur, dass es damit einfacher ist schlecht lesbaren und dafür kompakten Code zu erzeugen als ohne. Das hat aber nichts damit zu tun, dass es schlecht wäre oder nicht, das war einfach nur eine ungewertete Feststellung.

[Sherlock]

Dann sind wir ja alle wieder auf einer Linie :D

:dp:

Sherlock

[jensw_2000]

Um nochmal etwas Fachliches, bezogen auf die ursprüngliche Frage, zu sagen ...

Für mich ist RemObjects nicht die Zukunft von Delphi.
Die wollen das Produkt auch nicht mal geschenkt haben. ( Bewundert ruhig mein 6 monatiges DDR Schulenglisch. Iss mir nicht peinlich :) )
Allerdings sind Oxygene und C# für mich der Schritt nach Delphi. Ich migriere lebende Projekte momentan zu .Net und fange auch keine neuen Sachen mehr mit Delphi an. Cross Plattform kann RemObjects ganz klar besser als EMBT und an .Net gewöhne ich mich auch schon langsam. Am schwersten finde ich dabei, mir das "alles neu erfinden" abzutrainieren und stattdessen die passenden gemanagten Klassen von .Net zu finden.