WTF pro Stunde

Die Seele des Dichters konnte die Dunkelheit nicht ertragen und er teilt großzügig seine hohen Ideen. (c) anonym

Vor einiger Zeit habe ich drei Artikel "Architekturlösungen für ein Handyspiel" geschrieben, die sich mit der Architektur meiner Träume befassen:
• Teil 1: Modell
• Teil 2: Befehl und ihre Warteschlangen
• Teil 3: Blick auf den Strahlantrieb

Ich habe sogar darüber nachgedacht, dieses Produkt zu einem Aktivposten zu machen, aber bei der Abstimmung stellte sich heraus, dass Ideen und Diskussionen für die Menschen viel wichtiger waren als der fertige Code. Seitdem habe ich in zwei Spielbüros gearbeitet, eines war beschäftigt und eines ist immer noch mit Desktop-Spielen beschäftigt, aber die Idee, die Benutzeroberfläche durch Reaktivität in beiden Fällen zu organisieren, war sehr praktisch, beschleunigte einige der Arbeiten an komplexen Schnittstellen mehrmals und ermöglichte die Implementierung von Schnittstellen das schien vorher zu kompliziert. All dies hat gezeigt, dass selbst die Phase der ersten geschlossenen Beta-Tests nicht zu spät ist, um das Projekt noch besser zu machen.

Ich habe mir verschiedene Youtube-Programmberichte angesehen und dabei eine gewisse Gemeinsamkeit festgestellt: Ideen, auch wenn sie völlig richtig sind, gehen denjenigen, die sie am dringendsten brauchen, schlecht in den Kopf und werden manchmal missverstanden, weil die Geschichten nur wenig Code enthalten. Der Programmierer, der aus einem solchen Bericht hervorgegangen ist, kann sich nur hinsetzen und mit dem Schreiben beginnen, wenn das, was ihm bereits gesagt wurde, für ihn fast verständlich ist. Er hatte einfach keine Zeit, es selbst zu erraten. Am anderen Ende des Tutorials von Hallo Welt. Traurigkeit im Allgemeinen.

Es gibt so ein Konzept wie „Zone der proximalen Entwicklung“: Es wird durch den Inhalt dieser Aufgaben bestimmt, die eine Person immer noch nicht alleine lösen kann, die sie jedoch in gemeinsamer Aktivität mit jemandem lösen kann, der diese Barriere bereits überwunden hat. Das, was einer Person zunächst unter Beteiligung anderer zugänglich ist, wird dann zu ihrem eigenen Besitz (Fähigkeiten, Fertigkeiten). Daher ist es natürlich am nützlichsten, mit einem starken Leiter an einem interessanten Projekt zusammenzuarbeiten. Aber wo finde ich alle Projekte und noch mehr.

Im Allgemeinen wollte ich über all das nachdenken und versuchen, Menschen in einem anderen Format davon zu überzeugen: Ich werde einen Stream für die Codeüberprüfung zusammenstellen, meinen Code für die Reaktivität zeigen und die darin enthaltenen Ideen erläutern und erklären, warum sie so geschrieben sind und nicht ansonsten. Der Stream wird genau eine Stunde dauern. Hier im Artikel beschreibe ich kurz, worüber ich sprechen möchte, und füge dann das Timing und die Probleme hinzu, die ich besprochen habe und ab welcher Minute.

Dabei können und sollten Sie Fragen stellen, da die Qualität des Codes anhand der Menge an WTF pro Zeiteinheit für die Überprüfung gemessen wird. Genauere Fragen können hier in den Kommentaren gestellt werden, und ich werde versuchen, sie während des Streams zu beantworten, wenn ein für die Antwort geeigneter Code auftaucht.

Dabei können und sollten Sie mich korrigieren und auf Fehler hinweisen. Da es sicherlich jemanden geben wird, der im Besonderen oder im Allgemeinen schlauer ist, und auch, wenn eine Person auf ihren eigenen Code schaut, scheint sie keinen Teil davon zu sehen, hat das Gehirn bereits eine Meinung, die in solchen „blinden Flecken“ geschrieben ist und nicht lies sie noch einmal. Viele, wie ich dieses Gefühl kenne, wenn Sie zwei weitere Augen auf Ihren Code richten und plötzlich ein Außenstehender einen offensichtlichen Fehler an der sichtbarsten Stelle bemerkt, die Sie nicht gesehen haben. Für verschiedene Menschen fallen "blinde Flecken" auf unterschiedliche Weise auf den gleichen Code.

Der Stream beginnt am Mittwoch um 22:30 Uhr (dies ist leider meine Freizeit :) und ist hier verfügbar:

Nun zum Inhalt des Streams.

Im Allgemeinen ist eine nette Implementierung der Reaktivität in der UniRX-Bibliothek, die ich dringend empfehlen, sich mit vertraut zu machen. Vielleicht nimmst du es buchstäblich für dich selbst, oder wischst nur Ideen von dort. Aber ich werde mein eigenes Fahrrad zeigen, das von Grund auf neu geschrieben wurde. Das liegt nicht nur daran, dass ich Fahrräder liebe. Implementiert in UniRX Standard-Systemschnittstellen. IObserver <in T> und System.IObservable <out T>. Und an vielen Stellen macht ThreadSafe dies (nicht immer korrekt) und intern. Das heißt, die Bibliothek verfügt über viel zusätzlichen Code, und es ist unpraktisch, ihn zu erweitern. In der Realität musste ich mich in drei von drei Fällen erweitern und an die örtlichen Gegebenheiten anpassen.

Wie unser technischer Direktor von AssetStore sagte, wird dies zwar die Zeit verkürzen, aber nicht den Verstand steigern. Wenn Sie von dort etwas nehmen, das Sie selbst nicht schreiben konnten, werden Sie früher oder später einen Schluck mit diesem Code nehmen.
Es stimmt, ich werde nicht den Anwendungscode anzeigen, der wirklich im Spiel funktioniert, sondern meine Home-Version davon. Erstens ist es unmöglich, und zweitens habe ich zu Hause eine funktionsfähigere Version.

Multithreading ist an dieser Stelle völlig überflüssig, wenn wir die Reaktivität für die Schnittstelle verwenden. Alles, was wir tun möchten, ist, in UnityThred zu landen, um die Bildschirmkomponenten zu verschieben. Zweitens habe ich Threads für dasselbe und in einem schwierigeren Fall für die Arbeit geschrieben, und es dauert fünfmal länger, obwohl ich an einigen Stellen die Funktionen unserer extrem asynchronen Server-Engine geschickt nutze. Es würde noch mehr kosten, den gesamten Vertrag ohne Nachsicht umzusetzen.

Darüber hinaus ist IObserver selbst ein Problem. Erstens hat es für meinen Geschmack eine völlig überflüssige OnError (Exception e) -Methode. Wenn Sie über Multithreading verfügen, hat dies eine tiefgreifende Bedeutung: Diese Aktion wird in UnityThread gespeichert und bleibt nicht unbemerkt. Ursprünglich wurde diese Schnittstelle entwickelt, um mit Dateien zu arbeiten, die häufig mit Fehlern behaftet sind. Aber im Singlethread-Modus und wenn Sie mit dem Anwendungsmodell arbeiten, ist dies eine zusätzliche Blutung aus heiterem Himmel. Ich bevorzuge den Code, um den Alarm genau an der Stelle auszulösen, an der er abgestorben ist.

Das zweite Problem mit IObserver ist, dass ich eine Transaktionsänderung möchte. Stellen Sie sich vor, List kommt aus einer Quelle und aus einem anderen Stream erhalten wir den Index des Elements, das wir aus dem Sheet entfernen und weitergeben müssen. Und hier zeigt der Index auf das letzte Element, und hier wird ein Element gelöscht, und der Index wird um 1 verringert. Am Ende wird alles in Ordnung sein und das Ergebnis der Operation wird sich nicht ändern, aber wenn wir eine Nachricht über die Änderung der Liste und nur dann eine Nachricht über die Änderung des Index erhalten, wird unser Der Code fängt eine IndexOutOfRangeException ab. Tatsächlich kann sich das gleiche Problem mit der Reihenfolge, in der Änderungen angewendet werden, auf Dutzende andere Arten manifestieren. Dies ist einfach das offensichtlichste.

Daher möchte ich mein Interface einerseits ohne OnError ziehen, andererseits aber mit .OnTransaction (ITransaction t)

Etwas, das mir zu tief ist. Wenn Sie während eines Streams mit Code auf dem Bildschirm darüber sprechen, wird dies deutlich schneller und verständlicher. Weiter über die Tops:

• Meine Schnittstellen sind IActive und IReactive. Wie sie schöner sind als irgendwelche Ereignisse und wie das Endergebnis ihrer Verwendung aussieht.
• ActiveProperty <T>. Was ist der Unterschied zu Active.Proxy <T>, wie wird der Anfangswert einer Variablen übertragen und wie wird er verarbeitet?
• Wie überprüfe ich das alles mit Tests und warum ist es sehr bequem. Tatsächlich wäre es überhaupt nicht möglich, so etwas ohne Tests zu schreiben.
• Reinigungsstrategie IDisposible. Dualer Mechanismus, der sowohl OnComplete als auch ICollection <IDisposible> unterstützt
• So können Sie einfach Streaming-Toolkit-Erweiterungen durchführen und die nützlichsten Beispiele lesen.
• Debugging-Tools für all das Durcheinander. Zuallererst .Log (), und wir werden beim nächsten Mal zu CalculationTree gelangen.
• Sorgfältiges Lesen des Active.Proxy <T> -Codes, warum gibt es keine Ereignisse unter der Haube, sondern eine doppelt verknüpfte Liste.
• IActiveList und IActiveDictionary, zuerst die häufigsten Ideen.
• Aufteilen in ViewModel, Controller und View. So schleifen Sie Ihre Streams nicht.
• Das Löschen von Variablen aus der Reaktivität in ein Modell.
• ActiveList und ActiveDictionary mit minimalem Delta. Im Gegensatz zur frontalen Implementierung von DeltaDictionary im Allgemeinen und in UniRX im Besonderen.
• Die allgemeine Strategie zur Korrektur von Fehlern im Code, da es kein solches Fach an den Universitäten gibt, sollte es aber sein.

Tatsächlich gibt es bereits mehrere Stunden Geschichten und Code-Shows. Beginnen wir also mit der ersten Stunde und lernen Sie, wie Sie mit Füßen treten.

PS Dies wird mein erster Stream sein, also urteile nicht streng, ob es irgendwelche technischen Probleme gibt.