Ich lehre / helfe einem Schüler zu programmieren.
Ich erinnere mich, dass der folgende Prozess mir immer geholfen hat, als ich anfing; Es sieht ziemlich intuitiv aus und ich frage mich, ob jemand anders einen ähnlichen Ansatz verfolgt hat.
Mit der Zeit und der Übung habe ich anscheinend vergessen, wie schwer es war, von der Problembeschreibung zu einer Kodierungslösung überzugehen, aber mit dieser Methode konnte ich lernen, wie man programmiert.
Also für eine Projektbeschreibung wie:
Ein System muss den Preis eines Artikels basierend auf den folgenden Regeln berechnen (eine Beschreibung der Regeln ... Kunde, Rabatte, Verfügbarkeit usw. .. etc.)
Ich muss zuerst verstehen, was das Problem ist.
Identifizieren Sie dann das Element, die Regeln, die Variablen usw.
Pseudocode etwas wie:
%Vor%Und dann übergeben Sie es an die Programmiersprache ..
%Vor%Hattest du einen ähnlichen Ansatz? Hat jemand dir einen ähnlichen Ansatz beigebracht oder hast du dich selbst entdeckt (wie ich es getan habe :()
Ich habe etwas ähnliches gemacht.
Nach ein paar Monaten wird es nur noch internalisiert. Sie erkennen nicht, dass Sie es tun, bis Sie auf ein komplexes Problem stoßen, bei dem Sie das Problem lösen müssen.
Ich gehe über den testgetriebenen Ansatz.
Das Beispiel mit Nunit und C #.
%Vor%Implementiere das mit:
%Vor%Dann gehe zu den zwei Punkten.
%Vor%Die Implementierung besteht den Test noch immer, also fahren Sie mit dem nächsten Test fort.
Dies garantiert nicht, dass Sie den effizientesten Algorithmus erstellen, aber solange Sie wissen, was getestet werden soll und alles erfolgreich ist, garantiert es, dass Sie die richtigen Antworten erhalten.
der OO-Weg der alten Schule:
[diese Methode geht den CRC-Karten voraus, aber es war so lange (über 20 Jahre), dass ich mich nicht mehr erinnere, wo ich es gelernt habe]
Beim Programmieren denke ich nicht, dass TDD hilfreich ist. TDD ist später gut, wenn Sie ein Konzept haben, um was es beim Programmieren geht, aber für den Anfang ist das Wichtigste, eine Umgebung zu haben, in der Sie Code schreiben und die Ergebnisse in der schnellstmöglichen Zeit sehen.
Ich würde sofort von der Problembeschreibung zum Code wechseln. Hack es herum. Helfen Sie dem Schüler, verschiedene Möglichkeiten zum Erstellen von Software / Strukturierungsalgorithmen zu sehen. Bringen Sie dem Schüler bei, seine Meinung zu ändern und den Code zu überarbeiten. Versuchen Sie, etwas über die Codeästhetik zu lernen.
Sobald sie Code umgehen können .... dann führen Sie die Idee der formellen Umstrukturierung in Bezug auf Refactoring ein. Dann stellen Sie die Idee von TDD als eine Möglichkeit vor, den Prozess etwas robuster zu machen. Aber nur einmal, wenn sie sich wohl fühlen, Code zu manipulieren, um das zu tun, was sie wollen. In der Lage zu sein, Tests zu spezifizieren, ist dann etwas einfacher. Der Grund ist, dass es bei TDD um Design geht. Beim Lernen interessiert dich Design nicht so sehr, sondern was du kannst, mit welchen Spielzeugen musst du spielen, wie funktionieren sie, wie kombinierst du sie miteinander? Sobald Sie ein Gefühl dafür haben, dann wollen Sie über Design nachdenken und das ist, wenn TDD wirklich einsetzt.
Von da an begann ich, Mikromuster einzuführen, die zu Designmustern führen
Ich fange oben an und arbeite mich nach unten. Grundsätzlich beginne ich damit, eine Prozedur auf hoher Ebene zu schreiben, skizziere die Details darin und fange dann an, die Details auszufüllen.
Angenommen, ich hatte dieses Problem (aus dem Projekt euler)
Die Summe der Quadrate des ersten zehn natürliche Zahlen sind 1 ^ 2 + 2 ^ 2 + ... + 10 ^ 2 = 385
Das Quadrat der Summe der ersten zehn natürliche Zahlen sind, (1 + 2 + ... + 10) ^ 2 = 55 ^ 2 = 3025
Daher der Unterschied zwischen der Summe der Quadrate der ersten zehn natürliche Zahlen und das Quadrat des Summe ist 3025 385 = 2640.
Finde den Unterschied zwischen der Summe von die Quadrate der ersten hundert natürliche Zahlen und das Quadrat des Summe.
Also fange ich so an:
%Vor%Nun gibt es in Scheme keine Summe von Quadraten, Quadrat von Summen oder Listenfunktionen. Der nächste Schritt wäre also, jeden davon zu bauen. Beim Aufbau jeder dieser Funktionen muss ich vielleicht mehr abstrahieren. Ich versuche, die Dinge einfach zu halten, so dass jede Funktion nur eine Sache macht. Wenn ich eine funktionsfähige Komponente baue, die testbar ist, schreibe ich einen Komponententest dafür. Wenn ich anfange, eine logische Gruppierung für einige Daten und die Funktionen, die auf sie wirken, zu bemerken, kann ich sie in ein Objekt schieben.
Ich habe TDD schon immer genossen, seit es mir vorgestellt wurde. Hilft mir, meinen Code zu planen, und es bringt mich einfach, alle meine Tests mit "Erfolg" zurückzugeben, jedes Mal, wenn ich meinen Code ändere, lass mich wissen, dass ich heute pünktlich nach Hause gehe!
Wunschdenken ist wahrscheinlich das wichtigste Werkzeug, um komplexe Probleme zu lösen. Nehmen Sie im Zweifelsfall an, dass eine Funktion existiert, um Ihr Problem zu lösen (erstellen Sie zuerst einen Stub). Sie werden später darauf zurückkommen, um es zu erweitern.
Ein gutes Buch für Anfänger, die nach einem Prozess suchen: Test Driven Development: Mit Beispiel
Mein Vater hatte eine Reihe von Flow-Chart-Schablonen, mit denen er mich benutzen konnte, als er mir zum ersten Mal etwas über das Programmieren beibrachte. Bis heute zeichne ich Quadrate und Diamanten, um einen logischen Prozess zur Analyse eines Problems aufzubauen.
Ich denke, es gibt ungefähr ein Dutzend verschiedener Heuristiken, die ich kenne, wenn es um das Programmieren geht, und daher tendiere ich dazu, die Liste mit dem, was ich versuche, zu tun. Am Anfang ist es wichtig zu wissen, was das gewünschte Endergebnis ist und dann versuchen, rückwärts zu arbeiten, um es zu finden.
Ich erinnere mich an eine Algorithmus-Klasse, die einige dieser Möglichkeiten abdeckt:
Organisieren einer Lösung sowie Testen derselben für ungerade Situationen, z.B. Wenn jemand denkt, dass L eine Nummer sein sollte, würde ich normalerweise die Idee im Pseudocode ausprobieren, bevor ich es schreibe.
Entwurfsmuster können ein praktischer Satz von Werkzeugen sein, die für bestimmte Fälle verwendet werden können, z. B. wo ein Adapter benötigt wird oder Dinge in einer Zustands- oder Strategie-Lösung organisiert werden.
Ja .. gut TDD existierte nicht (oder war nicht so populär), als ich anfing. Wäre TDD der Weg von Problembeschreibung zu Code zu gehen? ... Ist das nicht ein bisschen fortgeschritten? Ich meine, wenn ein "zukünftiger" Entwickler kaum versteht, was eine Programmiersprache ist, wäre das nicht kontraproduktiv?
Wie wäre es mit hamcrest den Übergang vom Algorithmus zum Code machen?
Ich denke, es gibt eine bessere Möglichkeit, Ihr Problem zu benennen.
Anstatt es als "ein System" zu definieren, definieren Sie, was in Bezug auf Benutzereingaben und -ausgaben erwartet wird.
"In einem Fenster sollte ein Benutzer ein Element aus einer Liste auswählen und ein Feld sollte ihm anzeigen, wie viel es kostet."
Dann können Sie ihm einige der Faktoren geben, die die Kosten bestimmen, einschließlich der Beispielartikel und was ihre Kosten sein sollten.
(das ist auch sehr viel eine TDD-ähnliche Idee)
Denken Sie daran, wenn Sie 5% Rabatt bekommen, dann weitere 5% Rabatt, erhalten Sie keine 10% Rabatt. Sie zahlen 95% von 95%, also 90,25% oder 9,75%. Also sollten Sie den Prozentsatz nicht hinzufügen.
Tags und Links process