WTF por hora

A alma do poeta não podia suportar a obscuridade, e ele compartilha generosamente suas idéias sublimes. (c) anônimo

Há algum tempo, escrevi três artigos “Soluções arquitetônicas para jogos para dispositivos móveis” dedicados à arquitetura dos meus sonhos:
• Parte 1: Modelo
• Parte 2: comando e suas filas
• Parte 3: Visão sobre a propulsão a jato

Eu até pensei em transformar este produto em um ativo, mas durante a votação descobriu-se que idéias e discussões eram muito mais importantes para as pessoas do que o código final. Desde então, trabalhei em dois escritórios de jogos, um estava envolvido e outro ainda em jogos para desktop, mas a ideia de organizar a interface do usuário por meio da reatividade nos dois casos foi muito útil, várias vezes acelerou parte do trabalho em interfaces complexas e tornou possível a implementação de interfaces isso antes parecia muito complicado. Tudo isso mostrou que mesmo a fase dos primeiros testes beta fechados não é tarde demais para melhorar o projeto.

Eu olhei para vários relatórios de programação do youtube e notei uma certa semelhança entre eles: as idéias, mesmo as completamente corretas, entram mal no cérebro daqueles que mais precisam deles e às vezes são mal compreendidas porque há pouco código nas histórias. O programador que saiu desse relatório pode sentar-se e começar a escrever apenas se o que já lhe estava sendo dito for quase compreensível para ele, ele simplesmente não tiver tempo para adivinhar. No outro extremo do tutorial, por hello world. Tristeza, em geral.

Existe um conceito como “Zona de desenvolvimento proximal”: é determinado pelo conteúdo dessas tarefas que uma pessoa ainda não pode resolver por conta própria, mas é capaz de resolver em atividade conjunta com alguém que já ultrapassou essa barreira. Aquilo que é inicialmente acessível a uma pessoa com a participação de outras pessoas torna-se sua própria posse (habilidades, habilidades). Portanto, é mais útil, é claro, trabalhar em conjunto com um líder forte em um projeto interessante. Mas onde posso encontrar todos os projetos, e mais ainda.

Em geral, pensando em tudo isso, eu queria tentar compartilhar com as pessoas em um formato diferente: organizarei um fluxo dedicado à Revisão de Código, mostrarei meu código dedicado à reatividade e explicarei as idéias estabelecidas nele e por que está escrito dessa maneira e não caso contrário. O fluxo durará exatamente uma hora. Aqui no artigo, descreverei brevemente o que quero falar e, depois do fato, acrescentarei o tempo e os problemas que consegui discutir e a que minuto.

No processo, você pode e deve fazer perguntas, porque elas dizem que a qualidade do código é medida pela quantidade de WTF por unidade de tempo de revisão. Quaisquer perguntas mais detalhadas podem ser feitas aqui nos comentários, e tentarei respondê-las durante o fluxo, se um código adequado para a resposta aparecer.

No processo, você pode e deve me corrigir e apontar erros. Como certamente haverá alguém mais inteligente em particular ou em geral, e também porque, quando uma pessoa olha para seu próprio código, ele não parece ver parte dele, o cérebro já tem uma opinião escrita nesses "pontos cegos" e não releia-os. Muitos, como eu conheço esse sentimento, quando você chama mais dois olhos para o seu código, e de repente um estranho percebe um erro óbvio no lugar mais visível que você não viu. Para pessoas diferentes, os "pontos cegos" caem de maneiras diferentes, no mesmo código.

O stream começará na quarta-feira às 22:30 (este é o meu tempo livre, infelizmente. :) e estará disponível aqui:

Agora, sobre o conteúdo do fluxo.

Em geral, uma boa implementação de reatividade está na biblioteca UniRX, que eu recomendo fortemente que me familiarize. Talvez você literalmente leve para si mesmo, ou talvez apenas limpe as idéias a partir daí. Mas vou mostrar minha própria bicicleta, escrita do zero. Isto não é apenas porque eu amo bicicletas. No UniRX, implementa interfaces de sistema padrão. IObserver <em T> e System.IObservable <fora T>. E em muitos lugares o ThreadSafe faz isso (nem sempre corretamente) e é interno. Ou seja, a biblioteca possui muito código extra e é inconveniente expandi-lo. Na realidade, eu precisava expandir e me adaptar às condições locais em três casos em três.

Além disso, como disse o diretor técnico da Assetstore, isso aumentará o tempo, mas não o cérebro. Se você pegar algo de lá que não conseguiu escrever, mais cedo ou mais tarde tomará um gole deste código.
É verdade que não mostrarei o código do aplicativo que realmente funciona no jogo, mas minha versão inicial. Primeiro, é impossível e, segundo, mais importante, tenho uma versão mais funcional em casa.

A multithreading, neste local, é completamente supérflua se usarmos a reatividade para a interface. Tudo o que queremos fazer é acabar no UnityThred para mover os componentes da tela. Em segundo lugar, escrevi threads para a mesma coisa e, em um caso mais difícil, no trabalho, e isso leva cinco vezes mais tempo, embora em alguns lugares eu use inteligentemente os recursos do nosso mecanismo de servidor extremamente assíncrono. Fazer o código implementar todo o contrato sem indulgência levaria ainda mais.

Além disso, o IObserver em si é um problema. Em primeiro lugar, ele tem para o meu gosto um método OnError (Exceção e) completamente supérfluo. Quando você tem multithreading, isso tem um significado profundo, consistindo em despejar essa ação no UnityThread e não passa despercebida. E, originalmente, essa interface foi inventada para funcionar com arquivos que geralmente caem com erros. Mas no modo de thread único e quando você trabalha com o modelo de aplicativo, é uma hemorragia extra inesperada, prefiro o código para acionar o alarme exatamente no local em que ele morreu.

O segundo problema com o IObserver é que quero uma mudança transacional. Imagine que List vem de uma fonte e, de outro fluxo, obtemos o índice do elemento, que precisamos remover da planilha e transmitir adiante. E aqui o índice aponta para o último elemento, e aqui um elemento é excluído, e o índice diminui em 1. No final, tudo ficará bem e o resultado da operação não será alterado, mas se recebermos uma mensagem sobre a alteração da Lista e somente então uma mensagem sobre a alteração do índice, nossa o código capturará um IndexOutOfRangeException. De fato, o mesmo problema com a ordem em que as mudanças são aplicadas pode se manifestar de dezenas de outras maneiras, isso é simplesmente o mais óbvio.

Portanto, quero minha interface, por um lado, sem arrastar OnError, mas por outro lado, contendo .OnTransaction (ITransaction t)

Algo que eu sinto muito profundo. Falar sobre isso durante um fluxo com código na tela será claramente mais rápido e muito mais compreensível. Mais adiante sobre os topos:

• Minhas interfaces são IActive e IReactive. Como são mais bonitas do que qualquer evento e como é o resultado final de seu uso.
• ActiveProperty <T>. Qual é a diferença do Active.Proxy <T>, como o valor inicial de uma variável é transmitido e como é processado.
• Como verifico tudo isso com testes e por que é muito conveniente. De fato, não daria certo escrever uma coisa dessas sem testes.
• Estratégia de limpeza IDisposible. Mecanismo duplo que suporta OnComplete e ICollection <IDisposible>
• Como fazer facilmente extensões de kit de ferramentas de streaming e ler os exemplos mais úteis.
• Ferramentas de depuração para toda essa bagunça. Antes de mais, .Log (), e chegaremos ao CalculationTree na próxima vez.
• Leitura cuidadosa do código Active.Proxy <T>, por que não há eventos ocultos, mas uma lista duplamente vinculada.
• IActiveList e IActiveDictionary, primeiro as idéias mais comuns.
• Como dividir em ViewModel, Controller e View. Como não fazer loop em seus fluxos.
• O processo de descartar variáveis ​​da reatividade para um modelo.
• ActiveList e ActiveDictionary com delta mínimo. Diferentemente da implementação frontal do DeltaDictionary em geral e do UniRX em particular.
• A estratégia geral para corrigir erros no código, porque não existe esse assunto nas universidades, mas deveria existir.

De fato, já existem várias horas de histórias e programas de código, então vamos começar a partir da primeira hora e depois como pisar.

PS Este será meu primeiro stream, portanto, não julgue estritamente se há algum problema técnico.