Programação para as massas

Compreender até o básico da programação pode simplificar as atividades humanas. Além das coisas óbvias, como o desenvolvimento do pensamento abstrato ou a capacidade de dividir a tarefa em partes menores, proponho ir ainda mais longe e usar as abordagens básicas do desenvolvimento. Usando o exemplo da criação de um jogo lógico clássico, traçando uma analogia entre a programação visual e a tradicional, quero mostrar como as habilidades de desenvolvimento podem ajudar na resolução de um problema aplicado. Aqueles que desejam debater sobre o assunto ou jogar "Touros e Vacas" e ganhar um prêmio - um convite para felinos.



Meu nome é Zhenya e sou desenvolvedor de back-end na ManyChat. Há algum tempo, a equipe de RH me abordou com uma solicitação para implementar o jogo “Touros e Vacas”, familiar a muitos desde a infância, com base em nosso produto. Deixe-me adicionar um pouco de contexto. ManyChat é uma ferramenta para automatizar a interação entre empresas e seus clientes, permitindo responder perguntas comuns via Facebook e, mais recentemente, SMS e E-mail. “Touros e Vacas” é um jogo lógico, durante o qual, por várias tentativas, é necessário adivinhar o número adivinhado. Muitos podem conhecê-lo no jogo Fallout, onde você precisa invadir um terminal de computador. Mais detalhes sobre as regras podem ser encontrados no final do artigo.

Visualização


O que fazemos antes de escrever o código para uma tarefa complexa? Vamos ao quadro negro com um marcador ou pegamos um lápis e papel e desenhamos um diagrama de blocos ou diagrama UML, porque a visualização é a maneira mais natural de as pessoas apresentarem e perceberem informações. O Flow Builder é o coração do nosso sistema, com base em vários objetos, elementos gráficos e nas regras pelas quais eles interagem. Eu diria que essa é uma continuação lógica da programação orientada a objetos. Então, descartei as ferramentas usuais e imediatamente comecei a projetar a lógica da comunicação entre o bot e o jogador.

Fluxo do jogo Touros e Vacas

Isso é muito conveniente, pois o diagrama UML e o Flow Builder são quase idênticos. Nesta etapa, design e programação já estão combinados. Para várias iterações, joguei o fluxo e designei os locais de interação com o usuário e com a API. O resultado obtido foi um pouco diferente da representação original em minha cabeça - a visualização proporcionou uma oportunidade de analisar a tarefa de uma perspectiva diferente. Isso é bom, pois as alterações no diagrama são mais fáceis e baratas do que no código. Parece-me que o significado dessa abordagem está enraizado no provérbio "meça sete vezes, corte uma". Os engenheiros devem ser especialmente familiares e compreensíveis.

Divisão de responsabilidade


O que deve ser implementado no lado do ManyChat e o que no lado do código? A resposta para essa pergunta a princípio não me pareceu óbvia. Existem duas ferramentas para interação em nossa plataforma: Dynamic Block e External Request. Eles são quase idênticos, exceto que o primeiro executa a solicitação ao servidor remoto e passa para a próxima instrução, e o segundo permite comparar primeiro os dados de resposta com as variáveis ​​bot. Em uma das primeiras versões, usei o bloco Dinâmico e implementei o envio das classificações do método API diretamente para o Facebook. Parece que não há nada de errado com essa abordagem. Mas se você olhar um pouco mais longe e supor que o jogador deseja jogar usando o SMS, o código precisará descobrir o canal de comunicação de um jogador específico. Não parece necessário. Na próxima versão, troquei o fluxo para trabalhar com Solicitação Externa,adicionou um registro de resposta às variáveis ​​do usuário e removeu qualquer menção do canal do código. Agora, o código do jogo pode ser usado em outro aplicativo e implementar qualquer interface de interação desejada: do console ao aplicativo móvel. Seja separando a visualização da lógica de controle de acordo com o padrão MVC ou destacando os contextos limitados de acordo com a abordagem DDD - decida por si mesmo. O principal aqui é que, apesar da falta de requisitos, no nível subconsciente, identifiquei um gargalo potencial no sistema que poderia criar problemas no futuro.Seja separando a visualização da lógica de controle de acordo com o padrão MVC ou destacando os contextos limitados de acordo com a abordagem DDD - decida por si mesmo. O principal aqui é que, apesar da falta de requisitos, no nível subconsciente, identifiquei um gargalo potencial no sistema que poderia criar problemas no futuro.Seja separando a visualização da lógica de controle de acordo com o padrão MVC ou destacando os contextos limitados de acordo com a abordagem DDD - decida por si mesmo. O principal aqui é que, apesar da falta de requisitos, no nível subconsciente, identifiquei um gargalo potencial no sistema que poderia criar problemas no futuro.

Nomenclatura variável


A nomeação variável é um dos dois principais problemas de programação. Além das variáveis, a nomeação de blocos é igualmente importante. Muitos usuários não dão importância a isso, não têm tempo para olhar em volta, pois o fluxo se transforma em um conjunto de Cópia 1, Cópia 2 e assim por diante. Isso complica muito o entendimento. Tudo é como uma classe ruim - é impossível descobrir o que ele está fazendo sem entrar. Mais detalhadamente, esse pensamento foi revelado pelo meu colega. Se você estiver interessado, sugiro que você leia o post dele .

Steve McConnell, em seu livro "Perfect Code", escreveu que o nome deve descrever de maneira completa e precisa a entidade representada. Eu acho que é difícil argumentar com isso. Por exemplo, para variáveis ​​booleanas, prefiro usar o prefixo is. Nesse caso, o leitor já pode entender com o que está lidando nas duas primeiras letras. Quanto ao comprimento, é desejável que não exceda 20 caracteres (Gorla, Benander e Benander, 1990). Quanto menor o escopo de uma variável, menor o seu nome. Mas como todas as variáveis ​​no ManyChat têm um escopo global, vale a pena usar o espaço para nome. Para touros e vacas, usei o segmento inicial na forma de duas letras maiúsculas BC derivadas de touros e vacas. Dado o exposto, recebi o nome da variável BC Is Victory - bastante único e abrangente, na minha opinião.

DRY, KISS


O jogo funciona e, ao que parece, você pode expirar com uma sensação de realização. Mas sabemos que o próximo passo é a auto-revisão e refatoração. Com uma análise mais detalhada, você pode ver como parar o processamento de palavras e a vitória levar a bloqueios semelhantes - o jogador pede algumas ações. Ao mesmo tempo, a perda, por algum motivo desconhecido, vive sua própria vida. A combinação desses locais em um só parece ser uma etapa lógica para evitar duplicação, o que, por sua vez, leva a uma maior consistência de comportamento e facilidade de manutenção. Agora, se as alterações forem necessárias, você precisará transformá-las na única unidade do sistema sem alterações em outras, o que indica que o princípio Não se repita é aplicado com sucesso.


Fluir com DRY

No entanto, não pare por aí. Soluções complexas são difíceis de manter. Quando ocorre um erro, não será fácil localizá-lo, principalmente após um período em que você fica fora de contexto. Uma nova pessoa precisará de muita energia para descobrir o que é o quê. E você terá que se familiarizar com cada nó, para não perder nada de importante. Portanto, vale a pena usar o princípio de Manter simples, estúpido e espalhar todas as ações possíveis em locais separados. Após a decomposição, obtive 5 bastante fáceis de entender o fluxo. Como um bônus agradável, essa refatoração satisfez a responsabilidade únicaprincípio. Cada fluxo tem uma responsabilidade e essa responsabilidade é completamente encapsulada nele. O apelo é à la Black Box e, pela natureza do problema, pode ser localizado mais rapidamente.


Fluxo compatível com KISS

YAGNI


Em uma das primeiras versões da automação, houve conquistas no envio de lembretes de um jogo abandonado e instruções para o recebimento de presentes pelos vencedores. A implementação da primeira ideia foi complicada por restrições por parte do Facebook - recentemente, as condições para o envio de mensagens pela janela às 24 horas tornaram-se mais difíceis. O segundo acabou por ser insuficientemente trivial para a implementação pelo código. Ambos os problemas foram resolvidos, mas a quantidade de esforço necessária não foi justificada pelas necessidades de uma campanha única. Além disso, as tarefas de sprint pisaram nos calcanhares, por isso foi decidido não implementar essa funcionalidade. E aqui veio em socorro Você não vai precisar dissoum princípio cujo objetivo é abster-se de funcionalidade excessiva. Essa é uma situação normal quando as condições mudam e acabam, mais peças desnecessárias aparecem no produto. A remoção dos blocos correspondentes facilitou a compreensão do objetivo do fluxo e mais uma vez lembrou a importância da recusa oportuna de adicionar nova funcionalidade, o que não é diretamente necessário.

Desenvolvedores experientes sabem que qualquer recurso precisa de suporte constante, desde a refatoração de código até a atualização da documentação e o trabalho com o feedback do usuário. Portanto, a adição de novas funcionalidades deve sempre ser vista com desconfiança, fazendo a pergunta, é realmente necessário? Por fim, nesse estágio, você pode economizar muitos recursos.

vamos jogar


Os estágios da auto-revisão e refatoração são aprovados, não há funcionalidade desnecessária e o significado de todo o fluxo é transparente para a compreensão. Isso significa que o jogo está pronto e é hora de competir por prêmios. De acordo com os termos da competição, os 10 melhores jogadores que marcarem mais pontos antes de 22 de maio de 2020 receberão prêmios da equipe ManyChat.

Um pouco sobre as regras. Em nossa implementação, o jogo foi projetado para uma pessoa. O bot faz uma sequência de 4 dígitos com números não repetidos. O jogador tenta adivinhar o número. O bot relata em resposta a quantos números foram adivinhados sem coincidência com suas posições, ou seja, o número de vacas e quantos foram adivinhados até a posição, ou seja, o número de touros. Como resultado, o cenário do jogo pode se parecer com o seguinte:

O número 1234 é adivinhado O
participante faz a primeira suposição: 4321
Obtém a resposta: 0 touros e vacas 4. O
participante faz a segunda suposição: 1678
E recebe a resposta: 1 touro e 0 vacas.

Para tentar, siga o link e siga as instruções. Deixe-me lembrá-lo de que o jogo passa pelo Facebook Messenger. Oferecemos 2 níveis de dificuldade: um jogo para um número limitado e ilimitado de movimentos. Ganhar em uma difícil lhe trará 3 pontos, em uma simples - 2. Perder, independentemente do nível, terá 1 ponto.

O jogo foi implementado em uma pilha de tecnologia padrão: Nginx 1.17, PHP 7.4, PostgreSQL 12.1. Se desejar, você pode clonar o repositório no seu servidor, instalar o modelo na sua página ManyChat e organizar seu próprio torneio.

achados


"Todos neste país precisam aprender a programar em um computador, porque isso ensina você a pensar." Penso que a relevância desta declaração há muito tempo ultrapassa as fronteiras de apenas um país. A programação não é um personagem secreto no terminal, difícil para uma pessoa não iniciada, e um programador não é eleito. Primeiro de tudo, é uma maneira de pensar e um conjunto de habilidades para resolver problemas.

Passando para o título do artigo e o slogan original, quero reformulá-lo: “A programação pertence ao povo. Ele deve ter suas raízes mais profundas nas profundezas das grandes massas trabalhadoras. Deve ser entendido por essas massas e amado por elas. ”

Eu nunca teria pensado que em um artigo citaria Steve Jobs e Lenin.

Estou certo de que os pensamentos apresentados aqui vieram à minha mente não apenas para mim. Alguns até os consideram capitães. Mas sei por mim mesmo que às vezes você precisa ouvir as mesmas informações várias vezes para começar a usá-las. O princípio banal é simplificar as coisas da maneira mais simples que parecem. Todo programador sabe que o código do projeto rapidamente e facilmente fica fora de controle se não receber a devida atenção. Mas, às vezes, você precisa se lembrar disso novamente.

Algo não estava aceso. Por exemplo, técnicas extremas de programação, como programação em pares, pequenos lançamentos frequentes e o jogo do agendamento não foram abordados neste artigo. Embora as metodologias flexíveis tenham raízes comuns nos sistemas de organização da produção física offline, elas ainda são frequentemente usadas para o desenvolvimento de software. Embora seu potencial não se limite à indústria.

Provavelmente há algo em que nunca pensei. Cada um de nós tem sua própria experiência e visão. Portanto, peço que você compartilhe seus pensamentos sobre esse assunto nos comentários.

All Articles