(Ich verwende das Wort "Workflow" - nicht im Sinne von asynchronen Workflows - sondern eher im Sinne von "git workflow", dh wie Sie es als Teil Ihrer Entwicklung verwenden)
Nachdem ich eine Weile mit F # herumgespielt habe, habe ich angefangen, meine erste F # -App zu entwickeln. Ich komme aus c # / vb. Nachdem ich verschiedene Demos / Gespräche gesehen habe - zu Recht oder zu Unrecht - habe ich angefangen, fsi als Hauptentwicklungs- "Engine" zu verwenden und Sachen in diesem Bereich aufzurollen. Wenn ich auf ein Problem stoße, das ich debuggen muss, tendiere ich dazu, die problematische Funktion in kleinere Bits aufzuteilen und diese zu überprüfen, um das Problem zu debuggen.
Um jedoch die Menge an Code in fsi zu verwalten, sobald ich mit dem, was ich getan habe, glücklich bin, verschiebe ich es in eine .fs und lade die .fs zurück in fsi. Wenn die App größer wird, kann das etwas klobig werden, da ich, wenn ich umstrukturieren muss, am Ende den Inhalt aus der fs-Datei zurückholen muss, um etwas wieder in Gang zu setzen, bevor der Code wieder rausgeschoben wird in die .fs-Datei. Außerdem ist dieser Stil nicht wirklich ein Test-First-Approach, und so bekomme ich nicht den Vorteil, eine Reihe von Tests zu erstellen. (Ich vermisse auch die Fähigkeit, Breakpoints zu setzen / den Code zu verschieben, der in bestimmten Situationen zB Rekursion ist, kann schneller Fehler diagnostizieren als Teile einer Funktion ausbrechen - obwohl das vielleicht in VS11 verfügbar ist und ich nicht eingerichtet bin richtig) .. also denke ich, dass ich Dinge nicht optimal mache oder auch nicht richtig über Dinge nachdenke.
Ich habe mich gefragt, ob andere anbieten könnten, wie sie Apps entwickeln. Verwenden Sie hauptsächlich fsi oder starten Sie mit tdd. Sollte der tdd-Ansatz das primäre Entwicklungsvehikel sein und FSI selektiver eingesetzt werden, um beispielsweise die Implementierung komplexerer Algorithmen, Datenexploration usw. zu unterstützen?
Ich habe diese Frage angeschaut und offensichtlich hilft es hilfreich zu verschiedenen tdd-Frameworks für F #, aber ich wäre immer noch daran interessiert, den Workflow von erfahrenen F # -Entwicklern herauszufinden.
Viele thx
S
Ich denke, Sie sind auf dem richtigen Weg.
Entwicklungsprozess ist Geschmackssache. Ich werde meinen Ansatz trotzdem teilen.
fs -Dateien. Jede Datei repräsentiert ein Modul, das aus einer Gruppe von eng miteinander verwandten Funktionen besteht. Es muss nicht von Anfang an präzise sein; Du bewegst oft Sachen zwischen Modulen. fsx -Dateien zum schnellen Testen, sobald das Skelett der Module fertig ist. fsx scripting korrekte Ergebnisse liefert, verschieben Sie sie in Testfälle. Mach das wiederholt.
Program.fs in das Hauptprojekt ein und kompilieren Sie es in eine ausführbare Datei, um bei Bedarf zu debuggen. Im Allgemeinen ist F # REPL die Hauptentwicklungsmaschine. Es gibt mir sofortige Rückmeldungen und erlaubt inkrementelle Änderungen, die beim Prototyping sehr hilfreich sind. In F # ist TDD weniger kritisch, da die Fehlerrate viel niedriger ist als in anderen Sprachen. Und ich teste nicht alles, sondern konzentriere mich auf die Hauptfunktionalitäten und sorge für eine hohe Testabdeckung. Verwenden Sie testdriven.net Add-In oder Visual Studio 2012 Premium und Ultimate kann Ihnen nützliche Statistiken zur Testabdeckung geben.
Mit F # REPL und TDD muss ich fast nie Debuggen verwenden. Wann immer es ein falsches Verhalten gibt, höre ich auf und denke nach. Da Ihre Codes keine Nebenwirkungen haben, können Sie leicht darauf reagieren. In vielen Fällen kann mir die Argumentation und ein paar Druckbefehle die richtige Antwort geben.
Sie können TDD in F # REPL mit Unquote und FsCheck . Ersteres bietet Tests mit Zitaten, was ziemlich beeindruckend ist. Letzteres verwendet einen zufälligen Testansatz, der bei der Behandlung von Eckfällen Ihrer Codes attraktiv ist. Ich finde es sehr nützlich, wenn Ihre Programme bestimmte Eigenschaften erfüllen müssen. Es kann jedoch einige Zeit dauern, diese Frameworks richtig zu verwenden.
pad gab eine großartige Antwort, die sehr praktisch und nützlich für eine Person ist, die F # neu ist. Ich werde ein anderes Mittel geben, so dass andere nicht glauben, dass es nur einen Weg gibt, wie F # es tun.
Hinweis: Wenn Sie mit der Programmierung noch nicht vertraut sind, dann bleiben Sie bei der Antwort des Pads, es ist viel besser für einen neuen Programmierer.
In der objektorientierten Welt denkt man mit Objekten und in solchen Sprachen würde ich mit dem Schreiben von Objekten beginnen Arbeiten und Arbeiten mit verschiedenen Diagrammen wie use-case , Zustandsübergang , Sequenzdiagramm , usw., bis ich das Gefühl hatte, genug zu haben fange an, Objekte in C # cs - Dateien zu erstellen, indem du die Objekte mit Methoden, Eigenschaften, Ereignissen etc. ausführst.
In der funktionalen Welt beginne ich typischerweise mit abstrakten Konzepten und konvertiere sie in diskriminierte Gewerkschaften ( DU) in einer F # fs-Datei und überspringt die Verwendung einer REPL , zB F # Interactive , und fange dann an, ein paar Funktionen hinzuzufügen. Nachdem ich einige Funktionen erfüllt habe, habe ich ein Testprojekt mit NUnit und FsUnit über NuGet . Da die DUs abstrakt sind, sind die Testfälle in der Regel schwieriger zu schreiben, daher erstelle ich Drucker für die DU und füge sie dann in den Testfall ein, wo ich die Ergebnisausgabe vom Drucker im NUnit - Werkzeug abschneide und wieder einfüge Testfall, bei Bedarf Änderungen vornehmen. Beispiele hierfür finden Sie Parser und hübsche Drucker .
Der Hauptpunkt, den ich versuche zu machen, ist, dass ich mich nicht auf die Werkzeuge konzentriere, die ich benutze, sondern auf das abstrakte Konzept des Problems und die Werkzeuge bei Bedarf einbringe.
Ich werde feststellen, dass ich auch in PROLOG programmiere und dort beginne ich mit der REPL und verschiebe den Code zu a Speichern, sobald die Logik funktioniert. Ich bin also nicht dagegen, eine REPL zu verwenden, es ist nur eine andere Art, das Problem anzugehen.
BEARBEITEN
Pro Anfrage von Ken für ein Beispiel.
Siehe: Diskriminierte Gewerkschaften (F #) und suchen Sie nach dem Abschnitt
Using Discriminated Unions Instead of Object Hierarchies
Also würde anstelle eines Basistyps der Form mit vererbten Typen von Circle, EquilateralTriangle, Square und Rectangle eine diskriminierte Union wie angegeben erzeugt:
%Vor%Da Ihre Frage zu einer viel besseren unabhängigen Frage führen würde und Antworten mit viel mehr Details erhalten würde, als ich geben kann, würde ich vorschlagen, dass Sie das fragen.
Auch wenn Sie hier nach Informationen suchen, suchen Sie auch mit den folgenden Ersetzungen für diskriminierte Union (DU):