AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Cross-Platform-Entwicklung Gemeinsame Codebasis für Desktop und Mobile???

Gemeinsame Codebasis für Desktop und Mobile???

Ein Thema von BlackGuest · begonnen am 21. Dez 2013 · letzter Beitrag vom 29. Jan 2014
Antwort Antwort
Seite 3 von 3     123
Benutzerbild von Mavarik
Mavarik

Registriert seit: 9. Feb 2006
Ort: Stolberg (Rhld)
4.126 Beiträge
 
Delphi 10.3 Rio
 
#21

AW: Software Architektur

  Alt 27. Dez 2013, 12:43
Es ist nun einmal so, das ordentliche (Unit-Tests) 40-60% des gesamten Codes ausmachen.
Echt?

Wir hatten diese Thema auch auf unserem letzten Delphi-Frühstück.

Auch da lasse ich mich gerne eines besseren belehren, aber wir waren zu 70:30 der Meinung, dass wenn ich in der Lage bin die richtige Testroutine zu schreiben, kann ich auch den "richtigen" Code schreiben.
Bzw. die Fehler, die heute in "unseren" Programmen auftreten sind genau die, die eine Testroutine auch nicht gefunden hätte.

Vielleicht sieht es anders aus, wenn man bei einem neuen Projekt vom ersten Tag an die Tests mit programmiert, aber was ist mit unzähligen Routinen die man immer verwendet?

Bist Du der Meinung es loht sich im nachhinein dafür Testroutinen zu schreiben?

Mavarik
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
17.169 Beiträge
 
Delphi 10.4 Sydney
 
#22

AW: Software Architektur

  Alt 27. Dez 2013, 12:50
Auch da lasse ich mich gerne eines besseren belehren, aber wir waren zu 70:30 der Meinung, dass wenn ich in der Lage bin die richtige Testroutine zu schreiben, kann ich auch den "richtigen" Code schreiben.
Bzw. die Fehler, die heute in "unseren" Programmen auftreten sind genau die, die eine Testroutine auch nicht gefunden hätte.
Das Testroutinen auch nur Quellcode ist, ist er nicht perfekt. Wenn ein Fehler auftritt kann man ja auch die Testroutinen ergänzen das er in Zukunft auch geprüft wird.

Vielleicht sieht es anders aus, wenn man bei einem neuen Projekt vom ersten Tag an die Tests mit programmiert, aber was ist mit unzähligen Routinen die man immer verwendet?
Bist Du der Meinung es loht sich im nachhinein dafür Testroutinen zu schreiben?
Wenn das Programm noch nicht sein EOL erreicht hat ja. Denn dann lebt ja der Code noch und wird in den nächsten Jahren u.U. auch verändert. Dann ist es gut wenn man Testroutinen hat die die Funktionsfähigkeit nach der Änderung einfach überprüfen kann.
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
Benutzerbild von Sir Rufo
Sir Rufo

Registriert seit: 5. Jan 2005
Ort: Stadthagen
9.454 Beiträge
 
Delphi 10 Seattle Enterprise
 
#23

AW: Gemeinsame Codebasis für Desktop und Mobile???

  Alt 27. Dez 2013, 13:51
Nehmen wir mal an es gibt eine sehr komplexe Berechnungsformel, die unter bestimmten Umständen versagt.
Beim Entwickeln war einem dieser Umstand nicht bekannt und darum ist dort jetzt ein Fehler.

Kunde A beschwert sich und bevor man sich an den Code macht, erweitert man den Test um diese Konstellation und fängt an den Code zu prüfen und zu fixen.

Wann ist der Fix fertig? Wenn alle anderen und der neue Test fehlerfrei durchlaufen.

Ein wenig später kommt die Erkenntnis, dass man alles viel einfacher umsetzen/berechnen könnte.
Also einfach die neue Berechnungsformel implementieren.

Wann ist man fertig? Wenn alle Tests fehlerfrei durchlaufen.

Ein Test ist nur so gut wie die Testbedingungen, aber die sind nicht in Stein gemeißelt, sondern dynamisch und wachsen eben mit. Dadurch vermeidet man aber auf jeden Fall Fehler aus der Vergangenheit nochmals zu begehen.

BTW Tests mit Idealbedingungen zeigen nur, ob der Code im Idealfall funktioniert. Robusten Code testet man aber mit Bedingungen die zwar abwegig, aber möglich sind (werden Exceptions richtig geworfen, etc.)

EDIT
Dazu fällt mir gerade folgendes noch ein (reallifeexperince, allerdings kein Delphi aber egal)

Eine Funktion zum Ermitteln des Brutto-Preises:
Delphi-Quellcode:
function GetBrutto( Preis : currency; MwSt : currency ) : currency;
begin
  Result := ( Preis * ( 100 + 19 ) ) / 100; // ja, war hardcoded!
end;
Tja, und wer jetzt die Tests nur mit 19% macht fällt hier auf die Nase.

Vor allem, wenn sich dieser Fehler nach 2 Releases wieder ins Programm schleicht (ein VCS kannten die nicht)
Und vorsorglich haben die gar keine Tests drin gehabt, sondern die Funktion mit einem Artikel getestet.

So würde ich diese Funktion testen
Delphi-Quellcode:
// Idealbedingung
CheckEquals( 119, GetBrutto( 100, 19 ) );

// Variationen
CheckEquals( 100, GetBrutto( 100, 0 ) );
CheckEquals( 107, GetBrutto( 100, 7 ) );

// Abwegig, aber möglich
CheckEquals( 110.5, GetBrutto( 100, 10.5 ) );
CheckEquals( 90, GetBrutto( 100, -10 ) );

// Weitere Variationen
CheckEquals( 1190, GetBrutto( 1000, 19 ) );

// Fehler von Kunden gemeldet (bei Bedarf erweitern)

CheckEquals( 0, GetBrutto( 0, 19 ), 'case 0815');
Kaum macht man's richtig - schon funktioniert's
Zertifikat: Sir Rufo (Fingerprint: ‎ea 0a 4c 14 0d b6 3a a4 c1 c5 b9 dc 90 9d f0 e9 de 13 da 60)

Geändert von Sir Rufo (27. Dez 2013 um 14:36 Uhr)
  Mit Zitat antworten Zitat
Furtbichler
(Gast)

n/a Beiträge
 
#24

AW: Gemeinsame Codebasis für Desktop und Mobile???

  Alt 27. Dez 2013, 14:54
Da sollte man beinahe einen eigenen Thread für aufmachen.

...wenn ich in der Lage bin die richtige Testroutine zu schreiben, kann ich auch den "richtigen" Code schreiben....Bzw. die Fehler, die heute in "unseren" Programmen auftreten sind genau die, die eine Testroutine auch nicht gefunden hätte.
Die Unittests dienen dazu, die Funktion des zu testenden Objekts (bzw. die eine Methode) sicherzustellen. Du nimmst Dir die Spezifikation der Methode ('Was soll die eigentlich machen?') Und schreibst Tests dafür, und zwar für jeden Anwendungsfall (=Kombination der Parameteräquivalenzklassen*) einen eigenen Test. In deiner Testroutine kommt kein einziges IF vor, keine Schleife. Daher sind die Testroutinen auch viel einfacher zu schreiben, als der zu testende Code.
(* Bei der Funktion 'Schuhe ab Größe 45 sind kosten 5 Euro mehr') haben wir einen Parameter (Schuhgröße) mit zwei Äquivalenzklassen: Größen bis 45 und Größen ab 45. Man testet dann mit einem Wert aus jeder Klasse, sowie 1-2 Werten aus den Grenzen zwischen den Klassen, also: 30, 44,45,46, 50. Genauergenommen haben wir hier 5 Tests!)

So, nun hast Du also Code, der deinen eigentlichen Code testet, bzw. eine Aussage treffen kann, ob der Code das macht, was er machen soll. Super und ziemlich banal das Ganze.

Nun kommt eine Änderung rein, oder eine Optimierung, ein Refactoring o.ä. Mit deinen Testroutinen kannst du munter drauflosoptimieren, redigieren, verändern usw. Solange dein Test 'grün' ist, ist die Welt in Ordnung. Zum Schluß noch eine Verifikation am lebenden Objekt und Du kannst dir nun ziemlich sicher sein, das der Kunde nicht gleich anruft und sich beschwert.

Findet der Kunde einen Bug, ist klar, das Du keine 100% Codeabdeckung hast, und dieser blöde Käfer durch die (Test-) Maschen geflutscht ist. Aber weil Du schon Tests geschrieben hast, schreibst Du halt noch einen Test, der den Bug prüft (so ein Bug ist ja i.a. nur fehlerhaftes Verhalten bei bestimmten Eingabeparametern). DIESER Bug wird nie wieder auftreten, egal an welchen Schrauben Du in Zukunft noch drehen wirst.

Zitat:
aber was ist mit unzähligen Routinen die man immer verwendet?
Gerade die sind es wert, mit Unittests in Stein gemeißelt zu werden. Der älteste Bug, den ich in meiner Library entdeckt habe, schlummerte 10(!) Jahre im Code.

Zitat:
Bist Du der Meinung es loht sich im nachhinein dafür Testroutinen zu schreiben?
Es ist nie zu spät. Einziger Nachteil: Man gerät in Versuchung, sich den Code anzuschauen, um dann einen Test zu schreiben. Damit testet man dann nicht mehr 'was soll der Code machen?' sondern 'was macht der Code zur Zeit?'. Das ist ok, wenn der Code korrekt ist, aber ein wenig problematisch, weil man im schlimmsten Fall Tests für Bugs mit implementiert. Aber es ist immer noch 10000x besser als gar nichts.

TDD (Test Driven Development) ist ja so, das zuerst Testcode für eine zu implementierende Funktionalität geschrieben wird und danach erst die Funktionalität selbst. Ich mag das nicht, weil man den eigentlichen Code zu sehr an den Testcode anlehnt. Man schreibt also nicht guten Code der auch gut testbar ist, sondern in erster Linie einfach testbaren Code. Da leidet die Lesbarkeit ein wenig. Muss aber jeder selbst herausfinden.

Wir machen das so, das wir eine Businessoperation implementieren und gleich dazu die Tests für Validierung und Persitierung. Danach das Viewmodel und Kommandos und gleich die Tests dafür. Ich habe Basiskommandos durchgesetzt, wobei die Grundlogik in der abstrakten Klasse umgesetzt ist (sowas Banales wie: 'Es sind ungespeicherte Änderungen. Speichern? [Ja] [Nein] [Abbrechen]'). Dieses Verhalten wird einmal getestet und alle abgeleiteten Kommandos teste ich nur noch, ob sie vom Basiskommando ableiten und dann noch, ob die überschriebene Methode das macht, was sie machen soll.

Anfangs ging das etwas ruckelig mit den Tests und einige der Programmierer wissen immer noch nicht, was sie eigentlich testen sollen, aber mit der Zeit gewöhnt man sich daran. Ich schreibe mittlerweile das Formular zum Schluss, sozusagen als Sahnehäubchen. Denn ich weiß ja, das Operation, Viewmodel etc. super funktionieren. Das ist das komplette Gegenteil von RAD, aber auch nicht schlecht. Man muss eben mehr planen und mit Wireframes arbeiten.

Vielleicht sollt aber der "arme SW-Entwickler" einfach seine Aufwandsabschätzungen immer nur incl. Test und Dokumentation abgeben und diesen Punkt nicht extra ausweisen?
Das Problem an der Sache ist ja, das die Konkurrenz so schlampig ist, und ohne Unittests programmiert. Die sind vom Aufwand her eben um 40-60% günstiger.

Gottseidank macht sich Qualitätsbewustsein langsam bei den Kunden bemerkbar: Eine Anforderung eines großen deutschen Krankenkasse (SOAP-Anbindung) musste inklusive Architektur und Unittests umgesetzt werden (Vorgabe der IT-Abteilung). Klasse.

Ich merke gerade: Ich hab Ferien und sülze hier rum...

Geändert von Furtbichler (27. Dez 2013 um 14:57 Uhr)
  Mit Zitat antworten Zitat
Benutzerbild von Bernhard Geyer
Bernhard Geyer

Registriert seit: 13. Aug 2002
17.169 Beiträge
 
Delphi 10.4 Sydney
 
#25

AW: Gemeinsame Codebasis für Desktop und Mobile???

  Alt 27. Dez 2013, 16:03
Vielleicht sollt aber der "arme SW-Entwickler" einfach seine Aufwandsabschätzungen immer nur incl. Test und Dokumentation abgeben und diesen Punkt nicht extra ausweisen?
Das Problem an der Sache ist ja, das die Konkurrenz so schlampig ist, und ohne Unittests programmiert. Die sind vom Aufwand her eben um 40-60% günstiger.
Nur wegen der Tests werden sie nicht 40-60% günstiger sein. Da müssen Sie wohl noch andere Sachen wie Dokumentation oder ähnliches weglassen.
Oder das als Einstiegspreise ansetzen und den Gewinn dann über Customizing im eingeführten Programm wieder reinholen.
Windows Vista - Eine neue Erfahrung in Fehlern.
  Mit Zitat antworten Zitat
Benutzerbild von Harry Stahl
Harry Stahl

Registriert seit: 2. Apr 2004
Ort: Bonn
2.477 Beiträge
 
Delphi 11 Alexandria
 
#26

AW: Gemeinsame Codebasis für Desktop und Mobile???

  Alt 27. Dez 2013, 16:56
@Harry Stahl
Ist das hier -->http://www.amazon.de/Cross-Platform-...rds=delphi+xe5 von dir?

Werde ich mir gleich mal holen. Dann muss ich euch auch nicht mit zu vielen (dämlichen) Fragen nerven.
Ja, ist es. Hoffe, es hat Dir zumindest einige Fragen beantwortet. Generell ist anzumerken, dass es "nur" die Plattformen Windows / MAC abdeckt, aber selbst da ist ja schon einiges, was man wissen muss. Für Mobile (Android / IOS) werde ich wohl noch ein eigenständiges Buch machen (eigenständig, weil nicht alle Entwickler wirklich alle Plattformen abdecken wollen, nicht wenige wollen nur Desktop oder nur Mobile). Derzeit bin ich dabei mein PC-Adreßzz! für IOS (pc-adress), welches ich noch mit XE2 gemacht habe, auf XE5 (IOS und Android) zu portieren. Das wird mit XE5 viel besser, schneller und nativer. Bin schon fast fertig, ging einfacher als gedacht, erfreulicherweise konnte ich viel vom XE2-Code weiterverwenden (selbst viele Form-Bestandteile ließen sich per Copy und Paste in XE5-Formulare übernehmen).

Hier war insofern auch schon eine Hilfe, dass die Datenlogik außerhalb der Formulare lag und liegt.

Die Android-Version entsteht dabei quasi nebenbei automatisch (OK, abgesehen von einigen Plattform-Spezifikas). Auf Android freue ich mich wirklich riesig, da hier Vertrieb und Update-Zyklen außerhalb des Google-Play-Stores einfacher zu gestalten sind und für mich daher einen großen Anreiz darstellen.
  Mit Zitat antworten Zitat
BlackGuest

Registriert seit: 30. Jan 2009
52 Beiträge
 
Delphi XE7 Professional
 
#27

AW: Gemeinsame Codebasis für Desktop und Mobile???

  Alt 29. Jan 2014, 11:08
Sorry, dass ich mich erst jetzt wieder zum Thema melde. Ich musste mich zwischenzeitlich um eine andere Geschichte kümmern.

@Harry Stahl
Super Buch. Ich bin zwar noch nicht komplett durch aber es hat mir schon sehr geholfen. Vor allem, wenn man bedenkt, dass meine letzte Version Delphi XE war. Hat sich doch einiges geändert.

Ich denke ich sollte wie folgt vorgehen:

Für den Datenaustausch mit dem Embedded System habe ich bereits eine fertige Komponente, die den Datenverkehr mit dem Endsystem übernimmt.
Aktuell ist das eine Sammlung von Befehlen, mit der ich bestimmte Daten abfragen kann. Die einzelnen Funktionen liefern mir direkt die Daten, die ich haben will.

--> Für eine Plattformübergreifende Anwendung ungeeignet

Also definiere ich mir die Datenfelder als Property dieser Komponente und kann diese dann über die Live-Bindings mit den visuellen Komponenten auf dem UI verknüpfen.

Die Komponente muss ich dann natürlich noch so weit anpassen, dass der Teil, der auf die Schnittstellen zugreift entsprechend der Zielplattform den richtigen Code verwendet. Da muss ich noch einigen Hirnschmalz reinstecken. Aber wenn ich es konsequent für Windows umsetze sollte die Erweiterung auf die anderen Plattformen kein Thema sein.
Ebenfalls in diese Komponente müssen die Timergesteuerten Funktionen wie zyklische Abfragen bestimmter Prozessparameter. Die Implementation ist dann auch wieder Plattformabhängig.

Bei konsequenter Umsetzung kann ich wirklich mit dem reinen UI ohne jede Zeile Code (in diesem) arbeiten und habe damit eine wirklich plattformübergreifende Lösung.

Die Portierung von der Windows Desktop Anwendung auf eine mobile Umgebung ist dann auch recht einfach. Wenn ich nur visuelle Komponenten verwende, die für alle Plattformen verfügbar sind kann ich einfach den Inhalt meiner Form in das Android Projekt kopieren. Design anpassen, compilieren und fertig.

Sollte doch vom Ansatz her so realisierbar sein oder?

Gruß
BlackGuest

PS: Sorry, dass ich mich am Anfang etwas blöde angestellt habe aber Live-Binndings gabe es unter Delphi XE noch nicht. Die Möglichkeiten waren mir von daher noch gar nicht bekannt. Immer gut, wenn man mal über seinen Tellerrand hinausschaut.
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 13:21 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz