Wir haben vorher so gesagt.
Fassen Sie das große Modul.
Teilen Sie es in konkrete Bereiche (Klassen) auf.
Definieren Sie in diesen Bereichen die tatsächlichen Aktionen (Methoden).
Diese Methode ist offensichtlich effektiv.
Dennoch können Leser so fühlen.
"Aber... es ist immer noch schwierig und belastend."
"Ich weiß immer noch nicht, wie ich das Ganze umsetzen soll."
"Ich weiß nicht, wie ich die einzelnen Funktionen aufteilen soll."
Das ist normal.
Weil Module-Klasse-Methode
"Denkweise zur Strukturierung" ist,
Was jetzt benötigt wird, ist
"Denken, um die tatsächliche Implementierung innerhalb dieser Struktur zu beginnen".
Hier treten zwei Konzepte auf.
Pseudocode
TDD (Test Driven Development)
Diese beiden reduzieren die Belastung beim Entwickeln dramatisch.
1) Pseudocode - Schreiben Sie zuerst Ihre Gedanken auf, ohne zu coden
Pseudocode ist buchstäblich
"Text, der wie Code aussieht, aber kein echter Code ist".
Anstatt sofort funktionierenden Code zu schreiben,
schreiben wir zuerst so.
Wenn Sie beispielsweise die "Anmeldefunktion erstellen" möchten:
Der Benutzer gibt E-Mail und Passwort ein.
Suchen Sie den Benutzer mit dieser E-Mail in der DB.
Überprüfen Sie, ob das Passwort übereinstimmt.
Wenn ja, erstellen Sie den Anmeldestatus.
Wenn nicht, zeigen Sie eine Fehlermeldung an.
Das ist weder Ruby noch Python.
Es ist einfach ein "Denkfluss".
Aber jede dieser Zeilen
wird bald zu einer Methode,
wird zu einer Klasse,
wird in die Modulstruktur aufgenommen.
Wenn Sie einfach die kleinen Aktionen in Reihenfolge aufschreiben, ist die Hälfte des Problems bereits gelöst.
Das ist die Kraft des Pseudocodes.
Der größte Vorteil von Pseudocode
Sie können Funktionen entwerfen, ohne den Code zu kennen.
Sie können komplexe Funktionen in einfache Sätze aufteilen.
Die Unsicherheit darüber, "wo man anfangen soll", verschwindet.
Fehler beim Schreiben des tatsächlichen Codes werden reduziert.
Ein guter Programmierer ist
nicht jemand, der guten Code schreibt,
sondern jemand, der das Problem klar beschreiben kann, bevor er Code schreibt.
2) TDD (Test Driven Development) - Schreiben Sie zuerst Tests und füllen Sie dann den Code aus
So beginnt TDD.
"Definieren Sie zuerst die gewünschte Funktionalität schriftlich
und erstellen Sie den Code, der diese Funktionalität später durchläuft."
Es kehrt die Reihenfolge um.
Wenn Sie beispielsweise eine "Funktion zum Hinzufügen von zwei Zahlen" erstellen möchten,
schreiben Sie zuerst den Test so.
expect(add(2, 3)).to eq(5)
Dieser Satz sagt Folgendes aus.
"Es sollte eine Funktion namens add geben."
"Wenn Sie 2 und 3 eingeben,"
"sollte das Ergebnis 5 sein."
Dieser Test scheitert natürlich anfangs.
Warum? Weil die add-Funktion nicht existiert.
Dann fügen Sie jetzt, um dieses Scheitern zu beheben,
den minimalen Code hinzu.
def add(a, b)
a + b
end
Und der Test wird grün (erfolgreich).
Dieser Prozess hat den Effekt,
das "Entwickeln, indem man Funktionen in kleine Einheiten aufteilt",
natürlich im Gehirn zu verankern.
Die starke Wirkung von TDD
Sie müssen nicht sofort eine riesige Funktion erstellen.
Sie müssen nur in kleinen Funktionsblöcken (Methodenebene) denken.
Der Denkfluss wird klarer, was zu dramatisch weniger Fehlern führt.
Es überprüft wie ein automatisches Fahrassistenzsystem, ob Sie es gut machen.
Je komplexer die Funktion wird, desto größer ist der Nutzen.
Mit anderen Worten, TDD ist
der effektivste Weg, ein großes Problem in kleine Blöcke zu zerlegen.
Pseudocode + TDD = Denkweise zum Entwickeln wie das Zusammenbauen von Legosteinen
Wenn Sie diese beiden zusammen verwenden,
wird das Problem exponentiell einfacher.
1. Schreiben Sie den Gesamtfluss mit Pseudocode auf
→ Denken Sie daran, dass Sie eine Lego-Bauanleitung erstellen.
2. Implementieren Sie es schrittweise mit TDD
→ Denken Sie daran, dass Sie Lego-Steine eins nach dem anderen einsetzen.
Dieser Ansatz ist
der stabilste Workflow, um die Struktur von Modul → Klasse → Methode
zu implementieren.
Das Codieren ist nicht beängstigend.
Weil jedes Problem
in kleine Stücke zerlegt wird
wenn Sie jedes Stück erfolgreich machen
wird das Ganze natürlich erstellt.
Der Leser gewinnt hier Einsicht
"Oh... Ich habe mich also schwergetan, weil ich versucht habe, alles auf einmal fertig zu stellen."
"Wenn ich zuerst den Pseudocode beschreibe und dann mit TDD Stück für Stück erfolgreich mache,
wird am Ende auch eine komplexe Funktion fertiggestellt.""Wenn es wie das Zusammenbauen von Legosteinen ist...
kann auch ich große Projekte erstellen!"
Wenn diese Erkenntnis aufkommt,
beginnt der Leser nicht mehr aus Angst heraus mit der Entwicklung.
Stattdessen entwickelt er eine "Denkweise des Zerlegens und Zusammenstellens".