WTF por hora

El alma del poeta no podía soportar la oscuridad, y comparte generosamente sus nobles ideas. (c) anónimo

Hace algún tiempo escribí tres artículos "Soluciones arquitectónicas para un juego móvil" dedicadas a la arquitectura de mis sueños:
• Parte 1: Modelo
• Parte 2: Comando y sus colas
• Parte 3: Ver en propulsión a chorro

Incluso pensé en hacer de este producto un activo, pero durante la votación resultó que las ideas y las discusiones eran mucho más importantes para las personas que el código terminado. Desde entonces, he trabajado en dos oficinas de juegos, una estaba comprometida y la otra sigue jugando juegos de escritorio, pero la idea de organizar la interfaz de usuario a través de la reactividad en ambos casos fue muy útil, a veces aceleró parte del trabajo en interfaces complejas e hizo posible implementar interfaces eso antes parecía demasiado complicado. Todo esto demostró que incluso la etapa de las primeras pruebas beta cerradas no es demasiado tarde para mejorar el proyecto.

Miré varios informes de programación de YouTube, y noté una cierta similitud entre ellos: las ideas, incluso las completamente correctas, van mal en los cerebros de quienes más las necesitan y, a veces, se malinterpretan porque hay poco código en las historias. El programador que salió de tal informe puede sentarse y comenzar a escribir solo si lo que ya se le dijo es casi entendible para él, simplemente no tuvo tiempo de adivinar por sí mismo. En el otro extremo del tutorial, por hello world. Tristeza, en general.

Existe un concepto como “Zona de desarrollo próximo”: está determinado por el contenido de esas tareas que una persona aún no puede resolver por sí solo, pero puede resolver en una actividad conjunta con alguien que ya ha tomado esta barrera. Lo que inicialmente es accesible para una persona con la participación de otros luego se convierte en su propia posesión (habilidades, habilidades). Por lo tanto, es más útil, por supuesto, trabajar junto con un líder fuerte en un proyecto interesante. Pero, ¿dónde puedo encontrar todos los proyectos, y aún más?

En general, pensando en todo esto, quería tratar de compartir con las personas en un formato diferente: haré una transmisión dedicada a la Revisión de Código, mostraré mi código dedicado a la reactividad y explicaré las ideas que se establecen en él y por qué está escrito de esa manera y no de lo contrario La transmisión durará exactamente una hora. Aquí, en el artículo, describiré brevemente de qué quiero hablar, y luego, después del hecho, agregaré el momento y los temas que pude discutir y a partir de qué minuto.

En el proceso, puede y debe hacer preguntas, porque dicen que la calidad del código se mide por la cantidad de WTF por unidad de tiempo de revisión. Se pueden hacer preguntas más detalladas aquí en los comentarios, e intentaré responderlas durante la transmisión, si aparece un código adecuado para la respuesta.

En el proceso, puedes y debes corregirme y señalar errores. Porque seguramente habrá alguien que sea más inteligente en detalles o en general, y también porque cuando una persona mira su propio código, no parece ver parte de él, el cerebro ya tiene una opinión escrita en tales "puntos ciegos" y no vuelve a leerlos. Muchos, como sé este sentimiento, cuando llamas dos ojos más a tu código, y de repente un extraño nota un error obvio en el lugar más visible que no has visto. Para diferentes personas, los "puntos ciegos" caen de diferentes maneras, en el mismo código.

La transmisión comenzará el miércoles a las 22:30 (este es mi tiempo libre, por desgracia :) y estará disponible aquí:

Ahora sobre el contenido de la transmisión.

En general, una buena implementación de reactividad está en la biblioteca UniRX, que recomiendo conocer. Tal vez literalmente lo tomará usted mismo, o tal vez simplemente borre las ideas a partir de ahí. Pero mostraré mi propia bicicleta, escrita desde cero. Esto no es solo porque amo las bicicletas. En UniRX, implementa interfaces de sistema estándar. IObserver <en T> y System.IObservable <fuera T>. Y en muchos lugares ThreadSafe hace esto (no siempre correctamente) e internamente. Es decir, la biblioteca tiene mucho código adicional y es inconveniente expandirlo. En realidad, necesitaba expandirme y adaptarme a las condiciones locales en tres de cada tres casos.

Además, como dijo nuestro director técnico de Assetstore, aumentará el tiempo, pero no aumentará el cerebro. Si toma algo de allí que no podría escribir usted mismo, tarde o temprano tomará un sorbo con este código.
Es cierto que no mostraré el código de la aplicación que realmente funciona en el juego, sino mi versión doméstica. En primer lugar, es imposible, y en segundo lugar, lo que es más importante, tengo una versión más funcional en casa.

Multithreading, en este lugar es completamente superfluo si usamos reactividad para la interfaz. Todo lo que queremos hacer es terminar en UnityThred para mover los componentes de la pantalla. En segundo lugar, escribí hilos para la misma cosa, y en un caso más difícil, en el trabajo, y lleva cinco veces más tiempo, aunque en algunos lugares utilizo inteligentemente las características de nuestro motor de servidor extremadamente asíncrono. Hacer que el código implemente todo el contrato sin indulgencia requeriría aún más.

Además, IObserver en sí es un problema. En primer lugar, tiene para mi gusto un método OnError (Excepción e) completamente superfluo. Cuando tiene subprocesos múltiples, esto tiene un significado profundo, que consiste en volcar esta acción en UnityThread y no pasará desapercibida. Y originalmente, esta interfaz se inventó para trabajar con archivos que a menudo caen con errores. Pero en el modo de subproceso único y cuando trabaja con el modelo de aplicación, esto es una basura extra de la nada, prefiero que el código active la alarma exactamente en el lugar donde murió.

El segundo problema con IObserver es que quiero un cambio transaccional. Solo imagine que List proviene de una fuente, y de otra secuencia obtenemos el índice del elemento, que tenemos que eliminar de la hoja y pasar. Y aquí el índice apunta al último elemento, y aquí se elimina un elemento, y el índice disminuye en 1. Al final, todo estará bien y el resultado de la operación no cambiará, pero si recibimos un mensaje sobre el cambio de Lista y solo entonces un mensaje sobre el cambio de índice, nuestro el código detectará una IndexOutOfRangeException. De hecho, el mismo problema con el orden en que se aplican los cambios puede manifestarse en docenas de otras formas, esta es simplemente la más obvia.

Por lo tanto, quiero mi interfaz, por un lado sin arrastrar OnError, pero por otro lado contiene .OnTransaction (ITransaction t)

Algo que siento demasiado profundo. Hablar de ello durante una transmisión con código en la pantalla será claramente más rápido y mucho más comprensible. Más adelante sobre las tapas:

• Mis interfaces son IActive e IReactive. Cómo son más hermosos que cualquier evento y cómo se ve el resultado final de su uso.
• ActiveProperty <T>. ¿Cuál es la diferencia con Active.Proxy <T>, cómo se transmite el valor inicial de una variable y cómo se procesa?
• ¿Cómo verifico todo esto con pruebas y por qué es muy conveniente? De hecho, no sería posible escribir tal cosa sin pruebas en absoluto.
• Estrategia de limpieza IDisposible. Mecanismo dual que admite OnComplete e ICollection <IDisposible>
• Cómo hacer fácilmente extensiones de kit de herramientas de transmisión y leer los ejemplos más útiles.
• Herramientas de depuración para todo este desastre. Primero que nada .Log (), y llegaremos a CalculationTree en algún momento la próxima vez.
• Lectura cuidadosa del código Active.Proxy <T>, por qué no hay ningún evento oculto, sino una lista doblemente vinculada.
• IActiveList e IActiveDictionary, primero las ideas más comunes.
• Cómo dividir en ViewModel, Controller y View. Cómo no hacer un bucle de tus transmisiones.
• El proceso de descartar variables de reactividad a un modelo.
• ActiveList y ActiveDictionary con un delta mínimo. A diferencia de la implementación frontal de DeltaDictionary en general y en UniRX en particular.
• La estrategia general para corregir errores en el código, porque no existe tal tema en las universidades, pero debería serlo.

De hecho, ya hay varias horas de historias y programas de código, así que comencemos desde la primera hora y luego cómo pisotear.

PD: Esta será mi primera transmisión, así que no juzgues estrictamente si hay algún problema técnico.