KISS-Prinzip in der Entwicklung

    Der nächste Bericht mit Pixonic DevGAMM Talks, den wir entschlüsselt haben, ist etwas philosophisch - dies ist eine Rede von Konstantin Gladyshev. Er leitete den Game Programmer in den 1C Game Studios und sprach über das Prinzip, die Komplexität der Entwicklung im Kontext des gesamten Produkts zu steuern, und nicht über einzelne Funktionen. Und er zeigte mit Beispielen, warum es in der Entwicklung am wichtigsten ist, zu bestimmen, was nicht zu tun ist. Weitere Berichte finden Sie in den Links am Ende des Artikels.


    Ich wollte Ihnen etwas über den Norden erzählen, beschloss jedoch, einen philosophischen Bericht darüber zu erstellen, was einfacher zu tun ist. Ich arbeitete an Postal III, Indestructible, War Robots und jetzt mache ich Calibre - einen Session-Online-Shooter von 1C und Wargaming.



    Warum haben wir uns entschlossen, über KISS zu sprechen (Behalte es einfach, dumm)? Denn auch Senioren mit 20-jähriger Erfahrung oder CTO formen und formen oft weiter. Und Sie müssen es einfacher machen. Tatsächlich gibt es mehr über YAGNI (Sie werden es nicht brauchen) und ein bisschen Philosophie.

    Ich stelle sofort fest, dass wir nicht von völlig idiotischen Lösungen wie „find x“ sprechen, sondern von mehr oder weniger einfachen 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 plötzlich verwandelt sich unser Shooter in eine Farm? Oder "Ich mache beim nächsten Mal genau einen anderen Shooter." Es ist unwahrscheinlich, höchstwahrscheinlich wird es sich mit Ihnen ändern.
    • Zukunftssicher . Praktisch das Gleiche sind nicht vorhandene Probleme. "Und wenn ich eine Million Benutzer gleichzeitig habe, muss ich 22 Zwischenserver ertragen?" Um zu verdienen, reicht ein Server für alles.
    • Mit den falschen Werkzeugen . Wenn Sie Werkzeuge verwenden, die nicht in ihre Täuschung passen und bestehen bleiben.
    • Und die bekannte vorzeitige Optimierung .

    Wir hatten ein Beispiel, als Kaliber hergestellt wurde. Die Jungs, die uns geholfen haben, beschlossen, im letzten C ++ sofort einen Superserializer zu machen.

    Als Ergebnis arbeitete er nicht so, wie er wollte, es war unpraktisch, einen Teilstatus zu senden, da die Vorlagen nicht wirklich wissen, wo es notwendig ist und wo es nicht ist, oder Sie machen Flags. Im Laufe der Zeit hat selbst der Autor die Fehler in diesem Vorlagencode nicht verstanden.



    Dann schrieb einer der Programmierer in zwei Stunden buchstäblich all dieses Zeug in eine Seite mit C-Code um, was nur das tat, was wir gerade brauchten. Und es hat wunderbar funktioniert.

    Noch ein Beispiel. Wir hatten Postal III und es wurde auf der Source-Engine erstellt. Es gibt so eine offene Welt, man kann zwischen Karten laufen, eine Third-Person-Kamera, viele einstöckige Häuser im amerikanischen Stil mit Fenstern, Bots können herumlaufen und Türen in Panik öffnen. Infolgedessen funktionierte die gesamte BSP nicht. Es wurde sehr lange in Betracht gezogen, eine Million Sektoren wurden aus den Fenstern geholt und machten immer noch nichts. Es hat viel Speicher benötigt und wurde lange geladen.



    Half-Life, für die der Motor hergestellt wurde, ist ein Ego-Shooter, und ab dem dritten war es unbequem, einige Dinge zu tun. Alles Nützliche aus Half-Life hat uns überhaupt nicht gefallen. Es wurde auch eine große Anzahl von Animationen angenommen, denn von der dritten Person muss man klettern usw. Es war notwendig, den Motor zu wechseln, aber dann gab es keine Option.

    Was tun, wenn alles schlecht und schwierig ist und wir getrieben werden? Erstens: Führen Sie die Funktionen in der richtigen Reihenfolge aus, da die Optimierung im Voraus ein Problem ist. Einige beginnen, Straziki zu kleben, bevor sie ein Kleid nähen, und können dann nicht nähen, weil Straziki stört.

    Machen Sie zunächst das einfachste Stück so, dass es funktioniert, stabilisieren Sie es und optimieren Sie es anschließend. In dieser Reihenfolge ist alles andere falsch.



    Mit Visualisierung meinen wir, dass es minimal funktioniert, d. H. MVP (Mindestprodukt).



    Weiter schätzen Sie sein Potenzial. Nehmen wir an, Spieledesigner kommen mit Funktionen, der Programmierer greift zu und sagt: "Ich werde es gut machen, ich werde es nicht schlecht machen, also zeichnen Sie das lustige Spieldesign sofort". Aber woher weiß er das? Er hat nicht gespielt, weiß nicht, gut oder schlecht. Daher machen Sie im Idealfall eine Funktion, Sie spielen, wenn es normal ist, machen Sie es weiter. Nicht normal - rausgeworfen, nicht traurig.

    Vor tausend Jahren sagte Sun Tzu, dass es nicht die Spitze ist, in 100 Schlachten zu gewinnen, die Spitze ist, ohne Kampf zu gewinnen. Ie mach nicht was du nicht kannst.

    Stabilisierung. Sie haben die Features erstellt und stabilisieren sie ohne unnötige Ergänzungen. Brauchen Sie ein Rad an einem Baum, an einem Seil? Es hängt Sonst nichts.



    Wenn Sie plötzlich (ohne Zukunftssicherheit) feststellen, dass sich die Funktion ändern sollte, beginnen Sie von vorn. Machen Sie einfach einen Prototyp, stabilisieren Sie sich und versuchen Sie nicht, vorauszusehen. Auf jeden Fall werden Sie nicht raten.

    Nun, vorzeitige Optimierung. Es ist immer schlecht. Sie müssen ganz am Ende optimieren, wenn Sie sicher sind, dass diese Funktion wichtig ist. Sie sollte optimiert werden und wird sich in naher Zukunft nicht grundlegend ändern.



    Weil Optimierung eine Reihe von Sonderfällen ist. Die Lesbarkeit des Codes verschlechtert sich, die Abstraktionen werden gebrochen und die Portabilität wird in der Regel auch stark beeinträchtigt.



    Dies ist ein provokativer Abriss, da Krücken tatsächlich schlecht sind. Aber hier zeigt sich die Situation, wenn es eine Menge langweiliger Züge und Prototypen gibt, alles schlecht ist und alles zusammenbricht. Aber das ist nicht so. Schauen Sie - es ist eine Schalung, Beton wird hineingegossen und die "Krücken" werden beim Trocknen gestützt. Ie Die Situation ist absolut normal, die „Krücken“ werden dann entfernt, aber nicht sofort ohne Panik.

    Kurz über Philosophie. Es gibt keine allgemeingültigen Lösungen. Versuchen Sie nicht, den Rahmen 100 Jahre oder für alle Gelegenheiten zu schaffen.



    Besser viele kleine Stücke machen, die ihre Arbeit gut machen. Nicht so schnell wie möglich wegwerfen, versuchen Sie es nicht. Und wenn Sie Code schreiben, machen Sie das explizit. Manchmal ist es besser, expliziten Code zu schreiben, den Sie mit Ihren Händen anstelle von Reflex oder etwas anderem serialisieren. Die Verwendung der Abhängigkeitsaktion, wenn Sie sie nicht benötigen, ist ebenfalls eine schlechte Idee. Es ist sehr schwer zu lesen, die Hälfte der Laufzeitfehler. Explicit ist besser als implizit. Und machen Sie es so einfach wie möglich, Fehler zu vermeiden, wenn jemand etwas nicht verstanden hat oder es ganz vergessen hat.

    Wie Bruce Lee sagte, ist Einfachheit das höchste Maß an Kunst. Eines Tages fragte ihn der Schauspieler, den er seinem Jeet Kune-Do lehrte: "Was ist das Wesentliche an Ihrer Kampfkunst, Jeet Kune-Do?". In diesem Moment ließ Bruce Lee die Brieftasche fallen, der Schauspieler hob auf und Bruce Lee sagte: "Sie haben sich gerade gebückt und die Brieftasche aufgenommen, und wenn Sie in der Position des Reiters standen, haben Sie katy gemacht - Sie würden sie niemals aufheben."

    Fragen aus dem Publikum


    - Sie sagten, eine vorzeitige Optimierung sei böse. Lohnt es sich, vorzeitige Tests zu schreiben, wenn das Projekt gerade erst beginnt?

    - Nach meinem Verständnis ist im Allgemeinen alles Frühgeborene schädlich. In Tests bin ich nicht sehr stark, weil in Spielentwicklern (in vielen Fällen) Tests dem Ende der Entwicklung näher kommen. Zunächst ändert sich alles so schnell, dass der Game Designer alles ändert, während Sie einen Test schreiben. Ich glaube, dass es schlecht ist, Energie auf die Probe zu stellen, was sich in zwei Stunden ändern wird. Dies sollte in der Stabilisierungsphase erfolgen. Aber nicht im Prototypstadium. Aber wenn ein Team schnell Tests schreiben kann, ist dies wahrscheinlich gut. Wenn nicht, dann nein.

    - Sie haben erwähnt, dass die Krücken entfernt werden, aber es gibt eine wunderbare These - es gibt nichts Beständigeres als vorübergehend. Wir arbeiten alle in Game-Entwicklern, haben Termine, Produzenten, dann eine neue Funktion und so weiter. Wie oft haben Sie eine Situation gesehen, als Sie die Krücken gereinigt haben? Und haben sie sie auf Null gesetzt?

    - Bei Null wahrscheinlich nicht. Wenn das Projekt noch am Leben ist, haben Sie immer ein paar Krücken. Es funktioniert alles, wenn sie systematisch gereinigt werden. Ie Du hast ein Feature gemacht - sofort behoben.

    - also Soll ein Prozess in einem Unternehmen aufgebaut werden? Art der Krücken offizielle Reinigungsphase?

    - Ja, ich denke, dass dies in die Aufgabe einbezogen werden sollte. Ie Wenn Sie im Prozess der Aufgabe umgestalten müssen, werden Sie umgestalten. Grob gesagt ist selbst das Wort Refactoring nicht - es liegt innerhalb der Aufgabe.

    - Kann man das in der Praxis machen? Sie kommen zum Produzenten und sprechen über die Planung einer neuen Iteration, die wir zwei Wochen brauchen, um aufzuräumen, umzuformen, usw. Und er sagt, dass der Geschäftswert gleich Null ist, jetzt machen wir das Feature x und dies wird später eine Nacht nach der Arbeit gereinigt. Wie kann man in dieser Situation sein?

    - Wir haben Erfolg. Dem Produzenten ist bekannt, dass es einige Schulden gibt, die Sie jedoch rechtzeitig korrigieren. Nicht, dass Sie eine neue Version haben, es gibt nicht eine einzige neue Funktion, aber hier ist eine Art Refactoring. Wählen Sie einfach den richtigen Produzenten.

    - Mit Erfahrung kommt Verständnis, je einfacher - desto besser. Anfänger versuchen jedoch, komplexe, gruselige, große und riesige Systeme zu schaffen. Frage: Wie kann man sie davon abhalten, abgesehen von einem harten "Nein"?

    - Ich denke, das ist ein Lernproblem. Es ist notwendig, so schnell wie möglich aufzuzeigen, welche Lösungen funktionieren, welche nicht und warum. Wenn Sie Erfahrung haben und erklären können, warum dies nicht erforderlich ist, können Sie einfach viele Beispiele geben und es funktioniert gut. Zeigen Sie Ihr Beispiel und sorgen Sie ständig dafür, dass alles einfach ist. Legen Sie Prototypen an, damit sie öfter neu geschrieben werden - wenn Sie häufig umschreiben, möchten Sie nicht viel schreiben und schreiben einfacher und einfacher.

    - Wenn in einigen Projekten bereits etwas sehr Kompliziertes verwendet wird und diese Komplexität nicht mehr hilft, sondern eher verhindert - wie können einfacher zu einfachen Lösungen übergegangen werden?

    - Meine Meinung, fang einfach wieder an. Im Idealfall ein separates Team, direkt von vorne. Wahrscheinlich werden Sie 80% der Funktionalität sehr schnell wiederherstellen. In einer neuen und sauberen Bibliothek. Und dann wirst du aufholen.

    - Zum Beispiel gibt es einen mächtigen Serializer und einen Spieleditor, der veraltet ist ...

    - Dies sind die unpraktischsten Werkzeuge. Mach es dir bequem. Einheit zum Beispiel.

    - Sag mir, was ist deine Planung im Code, wie detailliert ist das? Der Hauptprogrammierer löst alle kleinen Fragen, alle Probleme?

    - Wir haben eine solche Anarchie, eine ziemlich flache Struktur, nicht sehr viele Leute. Wir vertrauen allen und verteilen einfach, wer den Prototyp nimmt und wer nicht. Dies kann eine beliebige Person sein.

    Weitere Berichte aus den Pixonic DevGAMM Talks



    Jetzt auch beliebt: