Erste Schritte gegen solides Software-Design?

Wie können Sie eine gute Balance zwischen solider Software-Architektur und guten Fortschritten finden, um alles zu erledigen, während wir kaum genug Zeit haben, um die von uns entwickelten Spiele fertigzustellen?

Meine persönliche Herausforderung: Wie wäre es, heute effektiv zu sein und gleichzeitig langfristig zu denken? Während Sie dies tun, möchten Sie vielleicht auch unterwegs neue Dinge lernen, anstatt auf dieselben sich wiederholenden Muster zurückzugreifen, die Sie in den letzten 5 Jahren verwendet haben?

Je weniger Erfahrung Sie haben, desto mehr Zeit verschwenden Sie mit dem Up-Front-Design. Gute Entwürfe zu machen ist etwas, das Sie lernen, indem Sie es tun und dann sehen / bewerten, wie es ausgeht. Einige Entscheidungen haben weitreichende, aber unklare Auswirkungen. Nach einigen Spielen werden Sie wahrscheinlich in der Lage sein, das ursprüngliche Design ziemlich solide zu machen, und es wird sich auszahlen, etwas mehr Zeit in diese Phase zu investieren.

Mein Motto: Erledige die Dinge in erster Linie, aber benutze deinen gesunden Menschenverstand, um zu erkennen, welche Komponenten kritischer sind als andere und entwerfe diese innerhalb deiner Frist ziemlich gut. Wenn beispielsweise die KI für Ihr Spiel von entscheidender Bedeutung ist, stellen Sie sicher, dass Sie sie später problemlos erweitern / ändern können. Oder wenn Sie eine Komponente schreiben, die Sie in jedem Spiel verwenden werden, entwerfen Sie sie für die Wiederverwendbarkeit. Verfolgen Sie Ihre Zeit und machen Sie sich keine Gedanken über das Entwerfen. Setze eine Design-Deadline und beginne danach alles zu hacken, um deine Release-Deadline zu bekommen. Aber stellen Sie sicher, dass Sie notieren, welche Punkte nachträglich überarbeitet / umgestaltet werden müssen, und kalkulieren Sie in einiger Zeit, bevor Sie mit dem nächsten Spiel beginnen, um diese Dinge zu verbessern, damit sie Sie nicht zurückbeißen können!

Ein guter Rat: Wenn Sie zwischen zwei Optionen wählen müssen, sollten Sie nicht zu lange bei Details verweilen. Meistens gibt es kein "gut" oder "schlecht". In einigen Situationen wird A besser sein, in einigen wird B besser sein, und insgesamt ist der Unterschied zwischen beiden möglicherweise nicht immer die Zeit wert.

Es gibt eine Menge Erfahrung beim Entwerfen von Software oder Spielen. Sie sollten also einen Teil Ihrer Zeit für Recherchen aufwenden (z. B. ein Buch über Design lesen, über andere Erfahrungen lesen, mit anderen Programmierern über Ihre Entwürfe sprechen usw.). ).

Die Menschen sind schrecklich bei der Vorhersage der Zukunft. Dies gilt insbesondere für Spiele, bei denen sich die Anforderungen täglich ändern können.

Es gibt ein Prinzip namens YAGNI , auch bekannt als "Sie werden es nicht brauchen", das im Grunde sagt, dass Sie etwas nicht implementieren sollten, bis Sie wissen, dass Sie es brauchen werden.

Ich habe gesehen, dass so viele Systeme mit architektonischer Rigidität überfrachtet sind, die nichts davon nutzten, da die Funktionen, von denen die Leute dachten, sie würden sie brauchen, nie genutzt wurden.

Meine persönliche Philosophie ist, das Einfachste zu tun, was möglicherweise funktionieren könnte . Davon abgesehen gibt es einen Unterschied zwischen Getting It Done und Hacking Shit Together. Das Schreiben von Code mit einem bestimmten Zweck sollte nicht bedeuten, dass Dinge, die einen "Code-Geruch" erzeugen, öffentlich gemacht werden, dass Blob-Klassen alles tun oder eines der Dutzenden anderer Dinge, die "schlechten" Code bedeuten.

Dies wird in meiner heutigen Denkweise als wahr bewertet:

• Pragmatismus über Ideologie
• (1) Lass es funktionieren (2), dann pass auf, wenn du Schritt 2 vergisst
• Lass es los!
• Zu viel Upfront-Design ist Zeitverschwendung
• TDD und Clean Code führen zu einfacheren und stabileren Software-Designs

Ich bin ein Freund von Software Rapid Prototyping. Besonders während der Spieleentwicklung. Es ist gut zum schnellen Lernen, Testen und Verwenden von Dingen. Für mich ist es die beste Methode, in der Nähe der Hardware zu programmieren oder komplizierte Algorithmen zu verwenden.

Theory();
RapidPrototype();
bool bOk = false;
while(!bOk)
{
 Testing();
 LotOfFixing();
 PlayingWith(); 
 bOk= AnalysingResults();
}
FinalFastAndNiceDataStructuresAndCode();

Meine Version von Rapid Prototype muss die richtige Prototypenkruste haben:

• Max freundliche Eingabeschnittstelle zum Konfigurieren von Anweisungen und Einrichten von Variablen oder Daten.
• Stabile Ausnahmen und Fehlerbehandlung.
• Online wie Debugger-Funktion, aber auf Ebene, was Sie brauchen.
• Max freundliche Ausgabe-Schnittstelle zum Anzeigen oder Erfassen von Ergebnissen auf allen möglichen und notwendigen Wegen.

Vorteile:

• Sie können die RapidPrototype-Kruste während der gesamten Entwicklung verbessern.
• Sie können Ihren Code auf viele Arten anzeigen und einrichten.
• Sie können sich nur auf Theorie und Problem konzentrieren, was Sie lösen müssen.
• Sie können schnell neue Teile des Projekts entwickeln und es mit dem Rest der letzten Dinge versuchen.
• Sie können neue Elemente für die Verwendung beim Füllen von Inhalten schneller bereitstellen und später fertigstellen (insbesondere in Sandbox-Fällen).
• Sie können Prinzipien oder Lösungen leicht beschreiben und anderen zeigen. Online.
• Ein funktionsfähiger und transparenter Prototyp ist die beste Informationsquelle für den endgültigen Code (jeder andere kann dies tun).

Wenn Sie es gut machen, können Sie am Ende eine echte Debug- / Lernversion Ihres Produkts haben.
Wir verwenden es in unserem Projekt und sind damit zufrieden.

Schauen Sie sich die agile Softwareentwicklung an . Obwohl es kein Wundermittel ist, zielt es darauf ab, beides zu tun (erledigen Sie es und verfügen Sie über ein solides Software-Design).