Diskussion zum Artikel "Entwicklung eines MQTT-Clients für Metatrader 5: ein TDD-Ansatz — Teil 6"
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Neuer Artikel Entwicklung eines MQTT-Clients für Metatrader 5: ein TDD-Ansatz — Teil 6 :
Dieser Artikel ist der sechste Teil einer Serie, die unsere Entwicklungsschritte für einen nativen MQL5-Client für das MQTT 5.0-Protokoll beschreibt. In diesem Teil erläutern wir die wichtigsten Änderungen unserer ersten Überarbeitung, wie wir zu einem brauchbaren Entwurf für unsere paketbildenden Klassen gekommen sind, wie wir PUBLISH- und PUBACK-Pakete bilden und die Semantik hinter den PUBACK-Reason-Codes (Begründungscode).
Die Methodik der testgetriebenen Entwicklung bietet viele Vorteile und hat einen großen Nachteil. Zu den Vorteilen gehört, dass wir gut definierte Einheiten und gut benannte Variablen schreiben können, um eine hohe Testabdeckung zu erreichen, die Domäne besser zu verstehen, Over-Engineering zu vermeiden und den Fokus auf die eigentliche Aufgabe zu richten. Der größte Nachteil ist eine unmittelbare Folge dieser engen Fokussierung auf die jeweilige Aufgabe, d. h., um sich nicht von der Gesamtkomplexität des Projekts einschüchtern zu lassen, lösen wir als Entwickler immer nur die kleinstmögliche Herausforderung, und zwar immer nur eine. Wenn das Genie die Person ist, die die Komplexität beseitigt, indem sie sie löst, ist der TDD-Entwickler die Person, die die Komplexität absichtlich ignoriert.
Ja, Sie haben es erfasst: So wie wir Pferde waren, die Scheuklappen trugen, so wie der Esel, der der Karotte folgte.
Aber die Komplexität verschwindet nicht, weil wir sie ignoriert haben. Sie bleibt dort und wartet darauf, dass wir uns ihr stellen. Wenn wir den Wald ignorieren, um das Blatt genau zu betrachten, hinterlassen wir eine technische Schuld. Wir hinterlassen ständig überflüssige Funktionen, doppelte Mitglieder, unbrauchbare Tests, unnötige Klassen, unleserlichen und unzugänglichen Code, Sie wissen schon. Diese technischen Schulden, die sich während der Entwicklung ansammeln, können unserer Produktivität schaden. Das ist der Grund, warum die Überarbeitung ein integraler Bestandteil der TDD-Praxis ist. Das folgende Diagramm zeigt die typischen Schritte einer TDD-Praxis.
Autor: Jocimar Lopes