Ist RemObjects die Zukunft von Delphi?

[Phoenix]

Zitat von Furtbichler:

Zitat von p80286:

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 von Phoenix:

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.

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.

[Lemmy]

Zitat von Sherlock:

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 von Sherlock:

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.

[Furtbichler]

Zitat von Phoenix:

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

Das ist eine Betrachtungsweise. Eine andere ist: Worauf kommt es bei der (Software)Entwicklung vorangig an?
Ich kann ein Problem übrigens grundsätzlich lösen, ohne Code produziert zu haben. Das ist eigentlich meistens so. Und das hat was mit Qualitätsbewusstsein zu tun.

Zitat:

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.

Das geht nur, wenn man (halbwegs) guten Code geschrieben hat. Und das geht nur, wenn man wartbaren Code geschrieben hat. Und das geht nur, wenn man testbaren Code geschrieben hat. Und nur(!) wenn man testbaren Code geschrieben hat, kann man ihn in Ruhe optimieren und aufräumen. Wo fängt es also an? Bei gutem Code und Qualitätsbewustsein? Oder beim 'Hauptsache et läuft'. Schrottcode wird nie guter Code. Nie. Aber guter Code wird sehr schnell funktionieren.

Ich muss dir das alles nicht erklären und die agile Softwareproduktion will ja den Theorieschnulzen endlich das Handwerk legen und das ist auch gut so. Apropos Handwerk: Erst mit einem gewissen Maß an handwerklichem Können wird das 'Make it work, make it right, make it fast' überhaupt machbar. Ein Haus aus Pappkarton, das den ersten Regen abhält, wird niemals ein Haus aus Stein mit negativer Energiebilanz. Aber ein halbwegs gut gebautes Haus kann nachträglich problemlos optimiert werden. Allerdings muss das Fundament und die Mauern stimmen.

Du gehst davon aus, das man automatisch halbwegs knetbaren (=optimierbaren) Code schreibt. Davon kannst Du aber nicht ausgehen, weil das Quatsch ist. Leider. Code ist -ohne das man mit der Peitsche hinter den Programmierern steht- fast immer Müll. Leider meine Erfahrung. Natürlich, wenn man handverlesene Spezialisten hat, die gut geschult sind und sich weiterbilden, dann... klar. Aber nicht bei einem durschnittlichen Frickelverein oder gar einer IT-Abteilung eines Piepenbrinkbetriebes.

[Jens01]

Da muß ich mal kurz eingreifen!

Zitat:

Ein Haus aus Pappkarton, das den ersten Regen abhält, wird niemals ein Haus aus Stein mit negativer Energiebilanz.

Also ein Haus mit Steinen kann man nicht mit negativer Energiebilanz bauen(das gibt es übrigens eigentlich gar nicht). Das geht nur mit Häusern mit Wänden aus Holz.

Zitat:

Aber ein halbwegs gut gebautes Haus kann nachträglich problemlos optimiert werden. Allerdings muss das Fundament und die Mauern stimmen.

Das würde ich erst einmal bezweifeln. Der Aufwand ist meist so hoch, dass Du auch neu bauen kannst. Geht nicht so einfach wie mit Quellcode.

[Furtbichler]

Zitat von Jens01:

Da muß ich mal kurz eingreifen!

Und? Was hast Du jetzt davon? Irgendwelche Erkenntisse oder weiterführende Argumente?

[Insider2004]

Managed Sprachen sind absolut tabu! Wer will schon, dass die Konkurrenz den Sourcecode einsehen kann?

[Union]

Die meisten Entwickler scheinen ja ihren eigenen Code bereits nach wenigen Tagen nicht mehr zu verstehen. Ansonsten muß man das eben verschleiern so gut es geht.

[Medium]

Zitat von Insider2004:

Managed Sprachen sind absolut tabu! Wer will schon, dass die Konkurrenz den Sourcecode einsehen kann?

Der Kerl schon wieder Wie gehts dir da hinten im Wald so?