Der nächste Bericht von Pixonic DevGAMM Talks, den wir entschlüsselt haben, ist ein wenig philosophisch - dies ist eine Rede von Konstantin Gladyshev. Er war der Lead Game Programmer bei 1C Game Studios und sprach über das Prinzip der Verwaltung der Entwicklungskomplexität im Kontext des gesamten Produkts und nicht über einzelne Funktionen. Und mit Beispielen zeigte er, warum die Hauptsache in der Entwicklung darin besteht, zu bestimmen, was nicht getan werden sollte. Für andere Berichte lesen Sie bitte die Links am Ende des Artikels.
Ich wollte über den Norden sprechen, beschloss aber, einen philosophischen Bericht darüber zu verfassen, was einfacher gemacht werden sollte. Ich habe an Postal III, Indestructible, War Robots gearbeitet und mache derzeit Calibre, einen Online-Session-Shooter von 1C und Wargaming.
Warum haben wir uns entschieden, über KISS zu sprechen (halte es einfach, dumm)? Denn auch Senioren mit 20 Jahren Erfahrung oder CTO formen und erfinden oft weiter. Aber Sie müssen es einfacher machen. Tatsächlich gibt es mehr über YAGNI (du wirst es nicht brauchen) und ein bisschen Philosophie.
Ich muss sofort sagen, dass es sich nicht um völlig idiotische Lösungen wie "find x" handelt, sondern um mehr oder weniger einfache Lösungen.
Warum ist es manchmal zu schwierig? Alles beginnt mit guten Absichten, und sie führen, wie Sie wissen, zur Hölle. Hier ist ein Comic darüber.
Die Gründe dafür sind ungefähr gleich, aber ich habe sie anders genannt:
- Universelle Lösungen . Es gibt eine Art Feature und wir machen sofort eine Bibliothek daraus, eine Million zusätzliche Fälle. Und dann verwandelt sich unser Schütze plötzlich in eine Farm? Oder "das nächste Mal werde ich genau den gleichen Shooter machen." Es ist unwahrscheinlich, dass sich dies höchstwahrscheinlich für Sie ändert.
- Zukunftssicher . Fast das Gleiche - das sind nicht existierende Probleme. "Und wenn ich sofort eine Million Benutzer habe, muss ich 22 Zwischenservern standhalten?" usw. Ein Server reicht aus, um Geld zu verdienen.
- Verwenden Sie die falschen Werkzeuge . Wenn Sie Werkzeuge verwenden, die nicht zu Ihrer Täuschung passen und bestehen bleiben.
- Und jeder kennt vorzeitige Optimierung .
Wir hatten ein Beispiel, als sie Calibre machten. Die Leute, die uns geholfen haben, haben sich dann entschlossen, sofort einen Superserializer in der neuesten C ++ zu machen.
Infolgedessen funktionierte es nicht wie gewünscht, es war unpraktisch, einen Teilstatus zu senden, da die Vorlagen nicht wirklich verstehen, wo es notwendig ist, wo es nicht ist oder ob Sie einige Flags erstellen. Die Fehler, die in diesem Boilerplate-Code enthalten waren, verstand selbst der Autor im Laufe der Zeit nicht.
Dann hat einer der Programmierer in nur zwei Stunden all dieses Zeug auf einer Seite mit C-Code neu geschrieben, was genau das tat, was wir gerade brauchten. Und es hat wunderbar funktioniert.
Ein weiteres Beispiel. Wir hatten Postal III und es wurde auf der Source-Engine gemacht. Es gibt eine so offene Welt, dass man zwischen Karten, einer Kamera für Dritte, vielen einstöckigen Häusern im amerikanischen Stil mit Fenstern, Bots herumlaufen und Türen in Panik geraten kann. Infolgedessen funktionierte das gesamte BSP nicht. Es wurde für eine sehr lange Zeit in Betracht gezogen, wegen der Fenster stellte es sich als eine Million Sektoren heraus und tat immer noch nichts. Es hat viel Speicherplatz beansprucht und lange geladen.
Half-Life, für das der Motor hergestellt wurde, ist ein Ego-Shooter, und ab dem dritten war es unpraktisch, einige Dinge zu tun. Alles Nützliche von Half-Life passte überhaupt nicht zu uns. Außerdem sollte eine große Menge an Animationen gemacht werden, da von einer dritten Person aus geklettert werden muss usw. Es war notwendig, den Motor zu wechseln, aber dann gab es keine Option.
Was tun, wenn alles schlecht und schwierig ist, aber sie uns drängen? Erstens, Funktionen in der richtigen Reihenfolge ausführen, da die Optimierung im Voraus eines der Probleme ist. Einige fangen an, Strassiks zu kleben, bevor sie das Kleid nähen, und dann können sie nicht nähen, weil die Straziks stören.
Machen Sie zuerst den einfachsten Chip, damit er funktioniert, stabilisieren Sie ihn und optimieren Sie ihn dann. In dieser Reihenfolge ist alles andere falsch.
Unter Visualisierung verstehen wir, dass es minimal betriebsbereit ist, d.h. MVP (Minimum Viable Product).
Dann bewerten Sie sein Potenzial. Nehmen wir an, Spieleentwickler entwickeln Funktionen, der Programmierer greift zurück und sagt: "Ich werde es gut machen, ich werde es nicht schlecht machen, also zeichne sofort ein funky Spieldesign." Aber woher weiß er das? Er spielte nicht, wusste nicht, ob es gut oder schlecht war. Daher erstellen Sie im Idealfall ein Feature, spielen es, wenn es normal ist, und machen es dann weiter. Nicht normal - rausgeworfen, nicht schade.
Vor tausend Jahren sagte Sun Tzu, 100 Schlachten zu gewinnen sei nicht der Höhepunkt, sondern ohne Kampf zu gewinnen. Das heißt, Tu nicht was du nicht kannst.
Stabilisierung. Sie haben Funktionen erstellt und diese ohne unnötige Ergänzungen weiter stabilisiert. Benötigen Sie ein Rad an einem Baum, an einem Seil? Es hängt. Nichts mehr.
Wenn also plötzlich festgestellt wurde (ohne zukünftige Beweise), dass sich die Funktion ändern sollte, starten Sie erneut. Einfach prototypisieren, stabilisieren und nicht voraussagen. Du wirst es immer noch nicht erraten.
Nun, vorzeitige Optimierung. Das ist immer schlecht. Sie müssen ganz am Ende optimieren, wenn Sie sicher sind, dass diese Funktion wichtig ist, sollte sie optimiert werden und wird sich in naher Zukunft nicht grundlegend ändern.
Denn Optimierung ist eine Reihe von Sonderfällen. Die Lesbarkeit des Codes verschlechtert sich, Abstraktionen brechen ab und die Portabilität verschlechtert sich in der Regel ebenfalls erheblich.
Dies ist eine provokative Folie, weil Krücken wirklich schlecht sind. Aber hier wird die Situation gezeigt, wenn es eine Reihe langweiliger Features und Prototypen gibt, alles schlecht ist und es scheint, dass alles zusammenbrechen wird. Aber das ist nicht so. Schauen Sie - das ist die Schalung, Beton wird hineingegossen und die „Krücken“ werden beim Trocknen gestützt. Das heißt, Die Situation ist absolut normal. „Krücken“ werden dann entfernt, jedoch nicht sofort, ohne Panik.
Kurz über Philosophie. Es gibt keine allgemein gültigen Lösungen. Versuchen Sie nicht, 100 Jahre im Voraus oder für alle Gelegenheiten einen Rahmen zu schaffen.
Machen Sie besser viele kleine Stücke, die ihre Arbeit gut machen. Werfen Sie das Unnötige so schnell wie möglich weg, versuchen Sie nicht, es zu unterstützen. Und wenn Sie Code schreiben, machen Sie ihn explizit. Manchmal ist es besser, expliziten Code zu schreiben, den Sie mit Ihren Händen serialisieren, anstatt Reflexion oder etwas anderes. Die Verwendung einer Abhängigkeitsaktion, wenn Sie sie nicht benötigen, ist ebenfalls eine schlechte Idee. Es ist sehr schwer zu lesen, die Hälfte der Fehler in der Laufzeit. Explizit ist besser als implizit. Und machen Sie es so einfach wie möglich, Fehler zu vermeiden, wenn jemand etwas nicht versteht oder sogar ganz vergisst.
Wie Bruce Lee sagte, ist Einfachheit das höchste Maß an Kunst. Einmal fragte ihn ein Schauspieler, den er seinem Jeet Kune-Do beigebracht hatte: "Was ist die Essenz Ihrer Kampfkunst Jeet Kune-Do?" In diesem Moment ließ Bruce Lee seine Brieftasche fallen, der Schauspieler hob sie auf und Bruce Lee sagte: "Siehst du, du hast dich nur gebeugt und die Brieftasche aufgehoben, und wenn du in der Pose eines Reiters gestanden hättest, der Kata gemacht hat, hättest du sie nie gehoben."
Fragen aus dem Publikum
"Sie sagten, vorzeitige Optimierung sei böse." Lohnt es sich, vorzeitige Tests zu schreiben, wenn ein Projekt gerade erst beginnt?- Nach meinem Verständnis ist alles, was verfrüht ist, schädlich. In Tests bin ich nicht sehr stark, da in der Spieleentwicklung (in vielen Fällen) die Tests näher am Ende der Entwicklung liegen. Am Anfang ändert sich alles so schnell, dass der Spieledesigner bereits alles ändert, während Sie einen Test schreiben. Ich glaube, es ist schlecht, Energie für das Testen aufzuwenden, was sich in zwei Stunden ändern wird. Dies muss in der Stabilisierungsphase erfolgen. Aber nicht im Prototypenstadium. Aber wenn das Team schnell Tests schreiben kann, ist dies wahrscheinlich gut. Wenn nicht, dann nein.
- Sie haben erwähnt, dass Krücken entfernt werden, aber es gibt eine wunderbare These - es gibt nichts Bleibenderes als nur vorübergehend. Wir arbeiten alle in der Spieleentwicklung, wir haben Fristen, Produzenten, dann ein neues Feature und so weiter. Wie oft haben Sie eine Situation gesehen, in der Sie Krücken gereinigt haben? Und haben sie sie auf Null gebracht?- Wahrscheinlich nicht bei Null. Wenn das Projekt live ist, haben Sie immer einige Krücken. Es funktioniert alles, wenn sie systematisch gereinigt werden. Das heißt, Sie haben eine Funktion erstellt - sofort aufgezeichnet.
- Das heißt. Sollte ein bestimmter Prozess im Unternehmen aufgebaut werden? Art der offiziellen Krückenreinigungsphase?- Ja, ich glaube, dass dies in die Aufgabe aufgenommen werden sollte. Das heißt, Wenn Sie im Prozess der Aufgabe umgestalten müssen, müssen Sie umgestalten. Grob gesagt ist sogar das Wort Refactoring nicht - es ist Teil der Aufgabe.
- Schaffst du das in der Praxis? Sie kommen zum Produzenten und sagen bei der Planung einer neuen Iteration, dass wir zwei Wochen brauchen, um zu reinigen, umzugestalten usw. Und er sagt, dass der Geschäftswert Null ist, jetzt haben wir Feature x, und dann werden Sie es später am Abend nach der Arbeit reinigen. Wie kann man in dieser Situation sein?- Wir haben Erfolg. Dem Hersteller ist bekannt, dass Sie einige Schulden korrigieren, jedoch rechtzeitig. Es ist nicht so, dass Sie eine neue Version haben, es gibt keine einzige neue Funktion, aber hier ist eine Art Refactoring. Wählen Sie einfach den richtigen Produzenten.
"Mit der Erfahrung kommt das Verständnis, je einfacher desto besser." Aber unerfahrene Programmierer versuchen, komplexe, beängstigende, große und gigantische Systeme zu erstellen. Frage: Wie kann man sie davon abhalten, bis auf ein hartes "Nein"?- Ich denke, das ist ein Lernproblem. Es muss so früh wie möglich gezeigt werden, welche Lösungen funktionieren, welche nicht und warum. Wenn Sie Erfahrung haben und erklären können, warum Sie dies nicht tun müssen, können Sie nur viele Beispiele nennen, und es funktioniert bereits gut. Zeigen und ständig mit Ihrem eigenen Beispiel überwachen, damit alles einfach ist. Setzen Sie Prototypen so ein, dass sie häufiger umschreiben. Wenn Sie häufig umschreiben, haben Sie keine Lust, viel zu schreiben, und sie schreiben immer einfacher.
- Wenn es bereits etwas sehr Kompliziertes gibt, das in mehreren Projekten verwendet wird, und diese Komplexität nicht mehr hilft, sondern stört - wie einfach ist es, auf einfache Lösungen umzusteigen?- Meiner Meinung nach fang einfach wieder an. Idealerweise ein separates Team, von Grund auf neu. Höchstwahrscheinlich werden Sie 80% der Funktionalität sehr schnell wiederherstellen. Auf einer neuen und sauberen Bibliothek. Und dann wirst du aufholen.
- Zum Beispiel gibt es einen leistungsstarken Serializer und Editor für Spielelogik, der jetzt ziemlich veraltet ist ...- Dies sind die gleichen unbequemen Werkzeuge. Nehmen Sie es bequem. Einheit zum Beispiel.
- Sag mir, was hast du im Code vor, wie detailliert ist es? Löst der Hauptprogrammierer alle kleineren Probleme, alle Aufgaben?- Wir haben eine solche Anarchie, eine ziemlich flache Struktur, nicht viele Menschen. Wir vertrauen allen und verteilen einfach, wer den Prototyp nimmt und wer nicht. Es kann jede beliebige Person sein.
Weitere Gespräche mit Pixonic DevGAMM Talks