Como se tornar um engenheiro melhor: fios de aço

Steel Threads são uma abordagem de design de software poderosa, mas obscura. Aprender sobre fios de aço fará de você um engenheiro melhor. Você pode usá-los para evitar problemas comuns, como dores de integração. E você pode usá-los para reduzir a complexidade do design do sistema.

Tão obscuro que foi deletado da Wikipédia em 2013

Quão desconhecidos são os Fios de Aço? O conceito foi excluído da Wikipedia em 2013 porque “a ideia não é notável na engenharia de software e não recebeu cobertura significativa de fontes notáveis”. Vamos adicionar à cobertura e também explicar por que é uma abordagem tão útil.

O que são fios de aço?

Um fio de aço é uma fatia muito fina de funcionalidade que passa por um sistema de software. Eles são chamados de “thread” porque tecem as várias partes do sistema de software e implementam um caso de uso importante.

Eles são chamados de “aço” porque o fio se torna uma base sólida para melhorias posteriores.

Com uma abordagem Steel Thread, você cria a versão mais fina possível que cruza os limites do sistema e abrange um caso de uso importante.

Exemplo de abordagem convencional e problemática

Digamos que você esteja criando um novo serviço para substituir uma parte de sua base de código monolítica. A maneira mais comum de fazer isso seria

1. Observe o código antigo e descubra as necessidades do novo sistema.

   
   

2. Projete e crie as APIs que fornecem os recursos de que você precisa.

   
   

3. Acesse o código antigo e atualize as referências para usar as novas APIs. Faça isso atrás de um sinalizador de recurso.

4. Corte usando o sinalizador de recurso.

   
   

5. Corrija quaisquer problemas que surjam até que esteja funcionando, desativando o sinalizador de recurso, se necessário, para voltar ao caminho de código antigo.

   
   

6. Quando estiver estável, remova os caminhos de código antigos.

Parece razoável, certo? Bem, essa é a forma mais comum de operação dos engenheiros de software, mas essa abordagem tem muitas minas terrestres.

Que problemas eu esperaria neste projeto?

1. Pode ser atraente construir o novo serviço de forma desconectada do sistema antigo. Afinal, o design pode parecer mais puro. Mas você também está introduzindo significativamente mais mudanças estruturais, e está fazendo essas mudanças sem qualquer integração com o sistema antigo. Isso aumenta significativamente a dor de integração. Minha expectativa seria que todas as estimativas para o projeto não fossem realistas. E eu esperaria que o projeto fosse considerado um fracasso depois de concluído, mesmo que o serviço resultante tenha um design geralmente bom.

   
   

2. Eu esperaria que a mudança para o novo sistema fosse problemática. Haverá uma série de problemas descobertos à medida que você mudar, o que exigirá voltar aos caminhos de código antigos ou trabalhar intensamente para corrigir problemas nos estágios finais do projeto.

Ambas as coisas são evitáveis, por não ter um grande corte. Observe que mesmo cortar mais de um por cento do tráfego para o novo serviço com um sinalizador de recurso é uma abordagem de substituição. Por que? Você está cortando todo aquele um por cento do tráfego para todas as mudanças ao mesmo tempo.

Eu ainda não esperava que fosse bem. Você está dando passos muito grandes.

Exemplo usando uma rosca de aço

Compare essa abordagem com a maneira de fazer o Steel Thread.

1. Pense no novo sistema que você está construindo. Crie alguns casos de uso restritos que representem o Steel Threads do sistema – eles cobrem funcionalidades úteis no sistema, mas não lidam com todos os casos de uso ou são limitados de alguma forma.

   
   

2. Escolha um caso de uso inicial que seja o mais restrito possível e que forneça algum valor. Por exemplo, você pode escolher uma API que acha que faria parte do novo serviço.

   
   

3. Crie a nova API em um novo serviço.

   
   

4. Faça com que funcione apenas para esse caso de uso restrito. Para qualquer outro caso de uso, use o caminho de código antigo. Coloque-o em produção e em pleno uso. (Dica: você pode até fazer o caminho de código novo E antigo e comparar!)

   
   

5. Em seguida, adicione gradualmente os casos de uso adicionais, até mover toda a funcionalidade necessária para o novo serviço. Cada caso de uso está em produção.

   
   

6. Depois de terminar, você extrai o código antigo e os sinalizadores de recursos. Isso não é nada arriscado, já que você já está rodando no novo sistema.

Não é este também o padrão “estrangulador”? Sim, mas isso também pode ser usado para novos projetos. Leia sobre um exemplo de greenfield.

Os fios de aço evitam a dor de integração e proporcionam maior confiança

A dor de integração é uma das maiores causas de problemas de última hora em projetos. Quando você passa para um novo sistema, sempre encontra problemas inesperados. Você deve suspeitar de qualquer coisa que envolva um corte. Faça as coisas em pequenos incrementos.

Os Steel Threads integram-se desde o início, para que você nunca tenha muita dor de integração para enfrentar. Em vez disso, você tem uma pequena dor de integração ao longo do caminho.

Além disso, seu serviço nunca precisa ser testado antes de ir ao ar, porque você o testou de forma incremental, ao longo do caminho. Você sabe que ele pode lidar com cargas de produção. Você já adicionou latência de rede, então conhece as implicações disso.

Todas as surpresas são avançadas e tratadas de forma incremental, apenas como parte da maneira como você implementa gradualmente o serviço.

O importante é que você tenha um sistema integrado e funcionando e, enquanto trabalha nele, você o mantém funcionando. E você o desenvolve com o tempo.

Fios de aço podem ajudar a superar a complexidade

Quando você está projetando um sistema, você tem MUITA complexidade. Construir um conjunto de requisitos para o novo sistema pode ser uma tarefa desafiadora.

Ao usar uma abordagem Steel Thread, você escolhe alguns dos requisitos principais e os formula de uma forma que atravessa as camadas do sistema e exercita seu design. Ele fornece uma espécie de estrutura esquelética para todo o sistema.

A implementação desse Fio de Aço torna-se então os ossos sobre os quais outros requisitos podem ser construídos.

Assim, os fios de aço são um subconjunto dos requisitos de um sistema.

Fios de aço também podem ser usados em trabalhos greenfield

Digamos que você esteja implementando um clone do Slack. Seu fio de aço inicial pode ser algo como:

“Qualquer pessoa não autenticada pode postar uma mensagem em uma #sala geral codificada em uma conta codificada. As mensagens persistem por meio de atualizações de página.”

Observe como esse fio de aço inicial é limitado. Ele não lida com autenticação, usuários ou contas. Ele lida com a gravação de mensagens e com a persistência delas.

Seu segundo fio de aço pode tornar o sistema mais útil. Você poderia, por exemplo, ter um Fio de Aço que permite ao autor da mensagem escolher o nome sob o qual postar.

Este segundo Fio de Aço não fez muito. Você ainda não tem autenticação, contas ou mesmo um conceito de usuário. Mas você criou uma sala de bate-papo que funciona o suficiente para começar a usá-la.

Além disso, observe que você não puxou o fio de aço por todas as partes do sistema. Mas você eliminou os conceitos de usuários e contas.

As roscas de aço fornecem feedback antecipado

Observe que neste exemplo de clone do Slack, você pode obter feedback antecipado sobre o sistema que está construindo, mesmo que ainda não tenha construído muito. Esta é outra razão poderosa para usar fios de aço.

Após apenas esses dois Fios de Aço, sua equipe pode começar a usar a sala de bate-papo em tempo integral. Pense em quanto sua equipe aprenderá usando seu sistema. É um sistema funcional.

Compare isso com o que você teria aprendido construindo os sistemas de usuário e conta, conectando tudo e, finalmente, construindo uma sala de bate-papo.

Comece com fios de aço

As roscas de aço costumam ser um bom lugar para começar ao projetar seus projetos. Eles criam um esqueleto para o resto do trabalho que está por vir. Eles fixam as partes centrais do sistema para que haja lugares naturais para serem desenvolvidos.

Eu encorajo você a tentar uma abordagem Steel Threaded. Acho que você descobrirá que pode transformar seus projetos. Deixe-me saber suas experiências com ele!

As roscas de aço estão intimamente relacionadas às fatias verticais

Você já deve ter ouvido falar do termo “corte vertical”. Eu descrevo o conceito em meu post sobre Milestones .

Steel Threads é uma técnica de design de software que resulta na entrega de seu software em fatias verticais. O termo tende a ser usado para descrever as fatias verticais iniciais de um sistema.

São conceitos intimamente relacionados, mas não completamente iguais.

Eu também ouvi falar de Fios de Aço sendo chamados de “balas rastreadoras”.

Imagem de Steen Jepsen do Pixabay

Esta história apareceu originalmente em: https://www.rubick.com/steel-threads/