Com certeza todos vocês, em diferentes estágios de sua carreira, enfrentaram esse problema: vocês viram a tarefa, parece que é simples e os requisitos são claros, e então descobriram que tiveram que implementá-la de forma diferente. O tempo para implementação foi gasto, o prazo já está se esgotando e a tarefa não está realmente pronta. Temos que reescrever na hora, provavelmente violando o prazo. As horas de trabalho são perdidas e custam dinheiro, e se esse problema não for para um desenvolvedor, mas para toda a empresa, então um monte de tarefas atrasadas aumenta, o custo de desenvolvimento aumenta, a empresa não consegue implementar a estratégia e a empresa sofre perdas.
Qual é o problema?
Esse problema surge devido à imersão insuficiente na tarefa. Pode haver muitos motivos, aqui estão alguns deles:
- falta de documentação atualizada;
- incompreensão do processo de negócios;
- a elaboração dos requisitos não é completa;
- o fator humano (a fonte do conhecimento e o performer falam sobre a mesma coisa, mas entendem de forma diferente);
- descuido pessoal de artistas e clientes;
- e outros (cada um pisou no ancinho à sua maneira).
Como resultado da imersão insuficiente na tarefa, os desenvolvedores fazem a coisa errada ou não completamente, os testadores fazem a coisa errada, os devops fazem a coisa errada e o SRE monitora os parâmetros errados.
Como isso pode ser consertado?
Em locais de trabalho anteriores, vi o seguinte algoritmo de trabalho:
- coleta de informações e formação de requisitos;
- a equipe está preparando e pensando em uma solução comum;
- um executor é nomeado para implementar a tarefa;
- revisão de código;
- Conserta;
- teste;
- mais correções;
...
- mais correções;
- a tão esperada conclusão da tarefa.
, , ?
, , , , . 
A descrição da solução técnica é feita antes mesmo do início do desenvolvimento e posteriormente revisada por toda a equipe. Para maior clareza e melhoria da percepção, decidimos diluir o texto com esquemas gráficos. O objetivo desta ação é identificar armadilhas, escolher as ferramentas certas, interagir corretamente com os outros nós do sistema e ser capaz de mergulhar toda a equipe na solução. O resultado que esperávamos era uma diminuição nos custos de mão de obra e erros nos processos de negócios (olhando para o futuro, direi que os erros na lógica de negócios praticamente desapareceram, muitos erros técnicos foram evitados, as correções foram reduzidas e o tempo médio para concluir uma tarefa diminuiu bastante). Descobriu-se também que é muito mais fácil e rápido fazer edições em uma descrição textual ou diagrama do que em um código já escrito.
Então, o algoritmo de trabalho será o seguinte:
- coleta de informações e formação de um requisito;
- a equipe está preparando e pensando em uma solução;
- um desenvolvedor responsável é nomeado;
- o desenvolvedor descreve a solução técnica ;
- em seguida, essa solução técnica é revisada pela equipe e demais pessoas imersas na área temática ;
- e somente após a solução ter sido acordada, o desenvolvedor escreve o código ;
- revisão de código;
- testando.
Por que é tão importante descrever a solução técnica antes da implementação real:
- a lógica da solução é revisada, os erros são corrigidos na fase de projeto;
- o desenvolvedor se aprofunda no domínio antes da implementação, o que permite pensar sobre a arquitetura com antecedência;
- departamentos adjacentes podem entender imediatamente o que a API será e estão prontos para iniciar o desenvolvimento paralelo;
- esclarece as necessidades dos colegas dependendo de sua implementação;
- ( , , ).
Exness?
Tendo vindo para Exness, queria me acostumar rapidamente com a equipe, estudar a infraestrutura e começar a resolver missões de combate. Na primeira tarefa ampla, decidi usar a experiência acumulada e minimizar o risco de resolver o problema incorretamente. Para descrever a interação de serviços, decidi usar diagramas de sequência, um diagrama de blocos para descrever a operação de algoritmos e diagramas ER para descrever o esquema do banco de dados.
No processo de desenho de um diagrama, aprendi com os colegas quais serviços podem ser necessários para resolver meu problema, verifiquei as solicitações feitas a eles e os dados no banco de dados, então já entendi o que e como funciona. Não demorou muito para desenvolver o diagrama e, ao revisar o diagrama, recebi um feedback útil:
- o desenvolvedor front-end queria saber em quais casos, quais dados e status ele receberia do back-end;
- O controle de qualidade precisa entender de onde vêm os dados no serviço para cobrir o maior número possível de casos.
No diagrama, detalhei as exceções e como elas "saem" e as fontes de dados usadas. Isso tornou possível mostrar visualmente aos colegas como a funcionalidade funciona e o que esperar dela, respectivamente, os colegas poderiam começar a implementar suas partes sem esperar pela minha implementação. O desenvolvedor front-end sabia como o serviço responderia e poderia começar a escrever integrações, o QA tinha informações sobre como o serviço responde a diferentes situações e como reproduzir essas situações. Como resultado, o desenvolvimento e imersão na tarefa acabou sendo bastante rápido, e o diagrama desenhado complementou a documentação do serviço que estava sendo desenvolvido.
Exemplo
O exemplo descrito abaixo é uma composição de várias situações.
O novo desenvolvedor recebeu uma tarefa com o texto " Escreva um novo microsserviço para rejeitar aplicativos vencidos. Notifique os clientes sobre a mudança de status. "
Depois de esclarecer os detalhes técnicos, você pode entender o problema assim:
- construir um microsserviço, fazer um POST nele - um método de API chamado rejeitar_old_requests;
- neste método API, você precisa obter dados do banco de dados, especificar filtros por usuário, status e data na solicitação;
- para cada solicitação, altere o status no serviço que gerencia as solicitações;
- em seguida, envie uma solicitação ao serviço de notificação para notificar os usuários sobre a mudança no status do aplicativo.
O diagrama de sequência para esta tarefa pode ser assim:
e quais erros você pode encontrar:
- sob o novo microsserviço, o analista pode significar o método API usual no microsserviço para trabalhar com solicitações, mas é difícil reconhecer tal cenário (na minha prática, houve um caso em que o analista entendeu o método API usual como um microsserviço, pelo que sei que o analista não se adaptou à terminologia correta);
- é possível que o aplicativo tenha subaplicativos ou aplicativos relacionados, cuja existência o novo desenvolvedor pode não saber, e o analista pode se esquecer de relatar e esperar que o próprio desenvolvedor obtenha as informações;
- Talvez haja muitos aplicativos e sua rejeição na venda levará muito tempo. Neste caso, seria melhor deitar e permitir rejeitar em segundo plano;
- — , . , .
No total, verifica-se que tal solução terá que ser reescrita do zero, uma vez que a presença de tais erros pode tornar a implementação inviável.
Se você escrever uma solução técnica antes do desenvolvimento e usar um diagrama de sequência para maior clareza, durante sua revisão, colegas mais imersos na área de assunto poderão ver os erros e apontá-los. E provavelmente o próprio desenvolvedor será capaz de ver alguns problemas e corrigi-los antes da revisão.
Garanto a vocês, apenas falar a solução de um problema não significa resolver o problema corretamente, um não vai expressá-lo corretamente e o outro não entenderá corretamente e a tarefa não será implementada corretamente. O diagrama de sequência não é uma solução mágica, mas em muitos casos ajudará a esclarecer alguns detalhes.
Qual seria a aparência do diagrama após as correções:
Qual é o uso de gráficos?
Nem todas as pessoas conseguem transferir bem um pensamento para o papel, por isso às vezes é melhor diluir o texto com uma descrição gráfica. Uma descrição mais clara da tarefa será útil não apenas para desenvolvedores, mas também para testadores, pois eles enfrentam o mesmo problema de imersão que os desenvolvedores. Os testadores precisam não apenas verificar os resultados positivos, mas também se certificar de que o sistema responde de maneira correta e previsível em qualquer situação; para emular tais casos, é necessário entender bem o que mudou no sistema. Para a equipe como um todo, pode ser mais conveniente armazenar a documentação na forma de diagramas ou esquemas diversos, já que são lacônicos, com grandes mudanças demoram menos para editar do que uma descrição textual. Em uma grande refatoração, os gráficos são indispensáveis porque permitem que você entenda rapidamente quem e como está trabalhando com um nó específico no sistema.Para líderes de equipe, a coisa será útil porque você pode reduzir seu tempo e o tempo de seus colegas juniores para imersão e, consequentemente, planejar tarefas com mais precisão. Na transferência de casos de um desenvolvedor para outro, os custos de tempo são reduzidos, respectivamente, a situação com o fator de barramento melhora.
Que conclusões podem ser tiradas?
Os diagramas de sequência são uma ferramenta muito poderosa e útil que economiza o tempo de você e de seus colegas. A descrição visual simplifica a percepção e permite que você se concentre na solução em si, sem se aprofundar na implementação técnica. Mas em nenhum caso diga que tal descrição visual é uma salvação para todos os problemas, mas ajudará a resolver uma parte significativa deles.
Os diagramas definitivamente ajudarão com:
- a qualidade e velocidade de imersão no projeto / tarefa;
- melhorar a situação com o fator ônibus;
- reduzir custos de mão de obra para manutenção de documentação técnica;
- simplificar a transferência de casos entre colegas;
- reduza os custos de mão de obra para implementação, teste e revisão de código, pois a lógica de solução do problema é revisada antes mesmo do início da implementação - você evitará muitos erros.
Pessoalmente, na minha prática, os diagramas foram e continuam sendo uma ferramenta indispensável.
Desejo que você também encontre ferramentas que otimizem seu trabalho. Obrigado por ler até o fim.
PS Escreva nos comentários se você usa essa prática, quais ferramentas você usa?