WTF par heure

L'âme du poète ne pouvait pas supporter l'obscurité et il partage généreusement ses idées nobles. (c) anonyme

Il y a quelque temps, j'ai écrit trois articles «Solutions architecturales pour un jeu mobile» dédiés à l'architecture de mes rêves:
• Partie 1: Modèle
• Partie 2: commande et leurs files d'attente
• Partie 3: Vue sur la propulsion par jet

J'ai même pensé à faire de ce produit un atout, mais lors du vote, il s'est avéré que les idées et les discussions étaient beaucoup plus importantes pour les gens que le code fini. Depuis lors, j'ai travaillé dans deux bureaux de jeux, l'un était engagé et l'autre est toujours engagé dans les jeux de bureau, mais l'idée d'organiser l'interface utilisateur par la réactivité dans les deux cas est très pratique, a accéléré plusieurs fois certains travaux sur des interfaces complexes et a permis de mettre en œuvre des interfaces cela semblait auparavant trop compliqué. Tout cela a montré que même l'étape des premiers tests bêta fermés n'est pas trop tard pour améliorer le projet.

J'ai regardé divers rapports de programmation YouTube et j'ai remarqué une certaine similitude entre eux: les idées, même complètement correctes, entrent mal dans la tête de ceux qui en ont le plus besoin et sont parfois mal comprises car il y a peu de code dans les histoires. Le programmeur qui est sorti d'un tel rapport ne peut s'asseoir et commencer à écrire que si ce qui lui a déjà été dit lui est presque compréhensible, il n'a tout simplement pas eu le temps de deviner par lui-même. À l'autre bout du tutoriel, par hello world. Tristesse, en général.

Il existe un concept tel que «Zone de développement proximal»: il est déterminé par le contenu de ces tâches qu'une personne ne peut toujours pas résoudre seule, mais est capable de résoudre en activité conjointe avec quelqu'un qui a déjà franchi cette barrière. Ce qui est initialement accessible à une personne avec la participation d'autrui devient alors sa propre possession (compétences, capacités). Par conséquent, il est très utile, bien sûr, de travailler avec un leader fort sur un projet intéressant. Mais où puis-je trouver tous les projets, et plus encore.

En général, en pensant à tout cela, je voulais essayer de partager avec les gens dans un format différent: j'organiserai un flux dédié à la révision du code, je montrerai mon code dédié à la réactivité et expliquerai les idées qui y sont énoncées et pourquoi il est écrit de cette façon et non sinon. Le flux durera exactement une heure. Ici, dans l'article, je décrirai brièvement de quoi je veux parler, puis après le fait, j'ajouterai le calendrier et les problèmes que j'ai réussi à discuter et à partir de quelle minute.

Dans le processus, vous pouvez et devez poser des questions, car ils disent que la qualité du code est mesurée par la quantité de WTF par unité de temps de révision. Toutes les questions plus détaillées peuvent être posées ici dans les commentaires, et j'essaierai d'y répondre au cours du flux, si un morceau de code adapté à la réponse apparaît.

Dans le processus, vous pouvez et devez me corriger et signaler les erreurs. Parce qu'il y aura sûrement quelqu'un qui est plus intelligent en particulier ou en général, et aussi parce que quand une personne regarde son propre code, elle ne semble pas en voir une partie, le cerveau a déjà une opinion qui est écrite dans de tels «angles morts» et ne les relire. Beaucoup, comme je connais ce sentiment, lorsque vous appelez deux yeux de plus à votre code, et tout à coup, un étranger remarque une erreur évidente à l'endroit le plus visible que vous n'avez pas vu. Pour différentes personnes, les «angles morts» relèvent de différentes manières, sur le même code.

Le stream commencera mercredi à 22h30 (c'est mon temps libre, hélas. :) et sera disponible ici:

Maintenant sur le contenu du flux.

En général, une belle implémentation de réactivité se trouve dans la bibliothèque UniRX, que je recommande fortement de connaître. Peut-être que vous le prendrez littéralement pour vous-même, ou peut-être essuyez-vous simplement les idées de là. Mais je vais montrer mon propre vélo, écrit à partir de zéro. Ce n'est pas seulement parce que j'aime les vélos. Dans UniRX, implémente des interfaces système standard. IObserver <in T> et System.IObservable <out T>. Et dans de nombreux endroits, ThreadSafe le fait (pas toujours correctement) et en interne. Autrement dit, la bibliothèque a beaucoup de code supplémentaire et il n'est pas pratique de l'étendre. En réalité, je devais m'étendre et m'adapter aux conditions locales dans trois cas sur trois.

De plus, comme l'a dit notre directeur technique Assetstore, cela augmentera le temps, mais pas le cerveau. Si vous en tirez quelque chose que vous ne pourriez pas écrire vous-même, tôt ou tard, vous prendrez une gorgée avec ce code.
Certes, je ne montrerai pas le code d'application qui fonctionne vraiment dans le jeu, mais ma version personnelle. Premièrement, c'est impossible, et deuxièmement, plus important encore, j'ai une version plus fonctionnelle à la maison.

Le multithreading, dans ce lieu, est complètement superflu si l'on utilise la réactivité pour l'interface. Tout ce que nous voulons faire, c'est finalement finir dans UnityThred pour déplacer les composants de l'écran. Deuxièmement, j'ai écrit des threads pour la même chose, et dans un cas plus difficile, au travail, et cela prend cinq fois plus de temps, même si à certains endroits j'utilise intelligemment les fonctionnalités de notre moteur de serveur extrêmement asynchrone. Pour que le code mette en œuvre l'intégralité du contrat sans indulgence, il faudrait encore plus.

De plus, IObserver lui-même est un problème. Premièrement, il a à mon goût une méthode OnError (Exception e) complètement superflue. Lorsque vous avez du multithreading, cela a une signification profonde, consistant à vider cette action dans UnityThread et cela ne passera pas inaperçu. Et à l'origine, cette interface a été inventée pour fonctionner avec des fichiers qui tombent souvent avec des erreurs. Mais en mode mono-thread et lorsque vous travaillez avec le modèle d'application, c'est une merde supplémentaire à l'improviste, je préfère le code pour déclencher l'alarme exactement à l'endroit où il est mort.

Le deuxième problème avec IObserver est que je souhaite un changement transactionnel. Imaginez simplement que List provient d'une source, et d'un autre flux, nous obtenons l'index de l'élément, que nous devons supprimer de la feuille et transmettre. Et ici, l'index pointe vers le dernier élément, et ici un élément est supprimé, et l'index diminue de 1. Au final, tout ira bien et le résultat de l'opération ne changera pas, mais si nous recevons un message sur le changement de List et seulement ensuite un message sur le changement d'index, notre le code interceptera une exception IndexOutOfRangeException. En fait, le même problème avec l'ordre dans lequel les changements sont appliqués peut se manifester de dizaines d'autres façons, c'est tout simplement le plus évident.

Par conséquent, je veux mon interface, d'une part sans faire glisser OnError, mais d'autre part contenant .OnTransaction (ITransaction t)

Quelque chose que je ressens trop profondément. En parler pendant un flux avec du code à l'écran sera clairement plus rapide et beaucoup plus compréhensible. Plus loin sur les hauts:

• Mes interfaces sont IActive et IReactive. Comment ils sont plus beaux que tous les événements et à quoi ressemble le résultat final de leur utilisation.
• ActiveProperty <T>. Quelle est la différence avec Active.Proxy <T>, comment la valeur initiale d'une variable est transmise et comment elle est traitée.
• Comment puis-je vérifier tout cela avec des tests et pourquoi c'est très pratique. En fait, il ne serait pas possible d'écrire une telle chose sans tests du tout.
• Stratégie d'entretien ménager IDisposible. Mécanisme double prenant en charge OnComplete et ICollection <IDisposible>
• Comment faire facilement des extensions de kit d'outils en streaming et lire les exemples les plus utiles.
• Outils de débogage pour tout ce gâchis. Tout d'abord .Log (), et nous arriverons à CalculationTree la prochaine fois.
• Une lecture attentive du code Active.Proxy <T>, pourquoi il n'y a pas d'événements sous le capot, mais une liste doublement liée.
• IActiveList et IActiveDictionary, d'abord les idées les plus courantes.
• Comment diviser en ViewModel, Controller et View. Comment ne pas boucler vos flux.
• Processus consistant à supprimer des variables de la réactivité vers un modèle.
• ActiveList et ActiveDictionary avec un delta minimal. Contrairement à l'implémentation frontale de DeltaDictionary en général et en UniRX en particulier.
• La stratégie générale pour corriger les erreurs dans le code, car il n'y a pas un tel sujet dans les universités, mais devrait l'être.

En fait, il y a déjà plusieurs heures d'histoires et d'émissions de code, alors commençons par la première heure, puis comment piétiner.

PS Ce sera mon premier stream, donc ne jugez pas strictement s'il y a des problèmes techniques.