Nossa abordagem para a consistência do desenvolvimento de software

Não documentar o que você pode automatizar

Esta publicação no blog faz parte de uma série em que compartilho nossa migração de aplicativos monolíticos (cada um com seu próprio repositório de fontes) implantado no AWS para uma arquitetura de serviços distribuídos (com todo o código-fonte hospedado em um monorepo) implantado no Google Cloud Platform.

O que é consistência no desenvolvimento de software?

Vejo consistência como parte integrante do software de entrega com êxito. Muitas vezes eu me juntei ou trabalhei com equipes de software que tinham pouca ou nenhuma consistência.

Aplica-se a todos os aspectos do desenvolvimento: estilo de código, comentários, ferramentas, onboard, criação de novos serviços. Ele também se estende ao gerenciamento de produtos, definindo e rastreando tarefas, e geralmente processos da empresa.

Vamos tomar o caso “criação de novos pacotes e serviços” do meu projeto atual, onde migramos de aplicativos monolíticos para serviços menores, independentes e distribuídos. Veja como criamos os primeiros 3 serviços:

  • Serviço 1 : 100% artesanal, teste e erro, muitos becos sem saída.
  • Serviço 2 : Copie e cole o serviço 1, ajuste sempre que necessário, substitua a lógica de negócios antiga por uma nova relevante para o serviço 2. Repita até que espero que tudo funcione de alguma forma.
  • Serviço 3 : Copie e cole … o que diabos estamos fazendo?

Você pode detectar a consistência? Corrigir, Copiar e colar parece bastante consistente. O que acontece quando as pessoas que passaram um serviço de construção da semana 1 seguiram em frente? Quem sabe o que precisa ser ajustado para criar o serviço 8? Imagine o pesadelo quando ocorre um erro fundamental e afeta todos os serviços … ?.

Agora a questão é, como tornamos isso mais consistente? Perguntei a alguns amigos e muitos responderam: Documentar o processo .

  • Service 1 : 100% hand-crafted, trial & error, algumas palavras juradas aqui e ali.
  • Documentar o processo
  • Serviço 2 : Copie e cole o serviço 1, siga a lista de verificação da documentação para atualizar o novo serviço.
  • Serviço 3 : siga as etapas acima, desde que nada tenha mudado e a documentação ainda esteja atualizada ?.

Não documentar o que você pode automatizar

Como alguém que gastou mais de metade de sua vida na indústria de software, percebi que a maneira mais simples de manter-se sã nesse ambiente em rápida mudança é escrever scripts que fazem o trabalho para mim.

A documentação é excelente, desde que seja precisa. Há situações em que a documentação é necessária, mas para o caso de uso que discutimos nesta publicação do blog (criar novos pacotes e serviços), a documentação é a abordagem errada.

Cada novo pacote ou serviço tem uma certa forma que é bastante semelhante entre todos os outros, como todas as casas tem algum tipo de fundação, algumas paredes e janelas e um telhado.

Imagine o procedimento a seguir para criar 3 serviços:

  • Serviço 1 : Execute o gerador de serviços, forneça valores específicos do serviço, pressione Enter.
  • Serviço 2 : Execute o gerador de serviço, forneça valores específicos do serviço, pressione Enter.
  • Serviço 4 : Execute o gerador de serviço, forneça valores específicos do serviço, pressione Enter.

Automatize o processo

Agora, não vamos apenas imaginar o procedimento acima, vamos ver como conseguimos exatamente isso em nosso projeto.

Para ser transparente, obviamente, tivemos algo como o serviço 0, onde fizemos tudo a mão, testávamos o serviço, implantávamos, ajustávamos etc. No entanto, sabíamos que queremos automatizar esse processo, então nós prestamos muita atenção a isso desde o início.

Nossa ferramenta de escolha é Plop . Uma alternativa popular é Yeoman . Nós escolhemos o Plop por sua simplicidade e agora que ele suporta AddMany , ele fornece tudo o que precisamos.

Atualmente, temos dois geradores:

  • Pacote
  • Serviço

Todos os arquivos de modelo vivem em uma pasta _templates . A estrutura do diretório é:

 . 
 ??? _templates 
 ? ??? pacotes 
 ? ? ??? README.md 
 ? ? ??? iso 
 ? ? ??? svr 
 ? ? ??? web 
 ? ??? serviços 
 ? ??? README.md 
 ? ??? svr 
 ? ??? web 
 ??? scripts 
 ?? geradores 
 ??? helpers.js 
 ??? index.js 
 ??? pacotes 
 ? ??? index.js 
 ??? serviços 
 ??? index.js

Os arquivos de modelo README.md existem uma vez para pacotes e uma vez para serviços. Isso garante que cada pacote (e cada serviço) siga a mesma estrutura. Um arquivo README.md contém as informações necessárias para que qualquer pessoa contribua para um pacote ou serviço.

Mais abaixo, os generators são definidos. O ponto de entrada do gerador e o gerador de pacotes aparecem assim:

Os geradores de serviços são um pouco mais complexos, já que eles também cuidam de alguma configuração de serviço adicional, como criar um recurso RuntimeConfig no GCP , criando um canal em Slack , adicionando um novo componente na Jira , etc.

Conclusão

O gerador pode ser bem incluído em um script NPM no package.json raiz do repositório.json, assim:

 { 
 "scripts": { 
 "gerar": "plop --plopfile ./scripts/generators/index.js" 
 }, 
 "devDependencies": { 
 "plop": "^ 1.9.1" 
 } 
 }

Tudo o que demora agora para gerar um novo pacote é yarn generate . Uma CLI interativa orienta os desenvolvedores através de algumas perguntas. Um recurso agradável é o fato de que você pode passar o nome do gerador como um argumento, por exemplo, o yarn generate service traz você direito às questões relacionadas ao serviço.

Texto original em inglês.