Como refatorar para Startups 2022: razões e compensações

(Postado cruzado do site da Klotho )

Esta postagem de blog é uma visão geral de alto nível sobre os motivos para refatorar código e sistemas em uma configuração de inicialização. Cobrimos riscos, abordagens e compensações a serem consideradas em 2022.

Como julgar quando o custo vale os ganhos

Seja honesto com você mesmo

A tentação sempre será refatorar: o código do mundo real é confuso e os engenheiros não gostam de código confuso. Certifique-se de que há um caso de negócios para refatoração medindo quanto tempo a equipe está gastando em recursos diretamente visíveis ao cliente.

Nossa pesquisa mostra que empresas de médio porte e startups de rápido crescimento gastam 39% da capacidade de engenharia em trabalhos indiferenciados, como infraestrutura. Divida as histórias em subtarefas, como infraestrutura e refatoração, para que você possa medir para onde está indo seu tempo.

Bem estruturado é bem mantido

Limites claros entre os módulos os tornam mais fáceis de testar, implantar e monitorar. Fique de olho nos bugs relatados pelos clientes, na latência do serviço e na frequência com que você precisa reverter o código. No outro extremo do ciclo de vida do software, há vários indicadores de que você está tendendo a um gargalo: quanto tempo leva para ir do projeto ao envio, o grau de satisfação da engenharia e o aumento dos custos de infraestrutura - todos esses podem ser indicadores importantes que você acumulou dívidas.

Pontos de inflexão nos negócios

As bases de código tendem a se organizar em três dimensões: tamanho da equipe, ritmo de novos recursos e número de clientes. Quando esses números mudam significativamente, pode ser hora de analisar a divisão dos componentes.

Se você estiver aumentando a equipe ou aumentando a taxa de desenvolvimento de recursos, o fator limitante será a legibilidade do código. Comece com refatoração oportunista e direcionada. Se sua base de clientes está crescendo, você pode precisar de tecnologias ou fluxos de trabalho mais escaláveis.

Controle o que puder, planeje o resto

Escolher certo não impedirá a re-arquitetura

A refatoração e a rearquitetura não significam que você fez uma escolha ruim anteriormente. Mais frequentemente, as forças motrizes por trás da re-arquitetura estão ligadas a mudanças de requisitos ou fatores externos. Existem pelo menos 4 dimensões significativas que forçarão uma re-arquitetura durante a vida útil de um produto: taxa de desenvolvimento de novos recursos, tamanho da equipe de engenharia, quantidade de tempo gasto em trabalho indiferenciado e crescimento do cliente. Cada um deles é progressivamente mais difícil de controlar diretamente.

Comece com as discagens fáceis…

Das quatro dimensões, as duas mais fáceis de controlar são a taxa de novos recursos e o tamanho da equipe de engenharia. Você pode controlar a taxa de novos recursos sendo mais rigoroso quanto ao planejamento e priorização. Escalar a equipe é um processo mais lento, mas geralmente é algo que você pode pelo menos planejar.

Se a equipe e a taxa de novos recursos forem pequenas, é improvável que a refatoração tenha um impacto significativo nos negócios. No outro extremo do espectro, uma grande equipe trabalhando em muitos recursos pode se beneficiar da reorganização em equipes menores — e você deve considerar a refatoração ou a rearquitetura do código correspondente. Uma arquitetura que permita limites organizacionais e de código mais limpos permitirá que o produto e a empresa sejam dimensionados.

…e depois passar para os mais difíceis

A quantidade de tempo que sua equipe gasta em trabalho indiferenciado pode ser difícil de controlar, e o crescimento do cliente é a medida mais difícil de afetar. Se isso fosse fácil, todos minimizariam o trabalho indiferenciado e maximizariam o crescimento do cliente! Ainda assim, você pode

supere os problemas com uma abordagem cuidadosa e proativa da refatoração.

O primeiro passo é saber quando não refatorar. Se o crescimento do cliente e a quantidade de tempo gasto em trabalho indiferenciado forem baixos, não gaste tempo refatorando: concentre-se em recursos impactantes e visíveis ao cliente. Da mesma forma, se você tiver um bom crescimento de clientes e uma baixa quantidade de trabalho indiferenciado, sua equipe está indo bem. Considere a refatoração tática para evitar que a quantidade de trabalho indiferenciado cresça, mas não gaste muito tempo nisso.

Se sua equipe está gastando muito tempo em um trabalho indiferenciado, é hora de revisitar a arquitetura para uma que se adapte melhor a sua empresa hoje.

Se a adoção do cliente for menor, sua prioridade deve ser uma arquitetura mais barata que lhe dará mais espaço.
Se a adoção do cliente e a quantidade de tempo que sua equipe gasta em trabalho indiferenciado forem altas, talvez seja hora de focar em uma solução centralizada e otimizada. Isso normalmente assume a forma de uma equipe de operações dedicada que pode executar com eficiência as tarefas de infraestrutura. Este é um grande problema para se ter - então reserve um momento para parabenizar a si mesmo e sua equipe por chegar até aqui!

Tenha um alvo e encontre atalhos para chegar lá

Tenha um plano, mesmo que não seja perfeito

Depois de se comprometer com uma nova arquitetura, não tenha medo de pensar grande. Confie em seus engenheiros para criar um estado final que eles adorariam e, em seguida, reduza-o conforme necessário. As chances são de que a oportunidade para uma grande re-arquitetura virá apenas uma ou duas vezes no ciclo de vida de um produto, portanto, esteja preparado para viver com qualquer compromisso que fizer. Mas, da mesma forma, saiba que mesmo os melhores planos vão dar errado quando você começar a implementá-los.

Faça grandes planos, dê pequenos passos

Depois de saber onde deseja que o código esteja, seja tático sobre como obtê-lo. Trabalhe um componente de cada vez ou escolha componentes que estejam o mais distantes possível um do outro. Se você ainda não investiu em testes sólidos, tanto no nível da unidade quanto no nível do sistema, agora é a hora. Os testes lhe darão a confiança de que suas alterações não prejudicarão as experiências existentes do cliente, mas também podem ajudar sua equipe a definir sua definição de pronto. Quando os testes forem aprovados, o componente estará pronto!

A melhor tecnologia é aquela que você pode adaptar

A chave para reduzir o impacto da refatoração e re-arquitetura em startups em particular é usar tecnologia adaptável.

Historicamente, as empresas escolhem tecnologias específicas como VMs, sem servidor ou contêineres para hospedar seus aplicativos. O problema é que mudar de uma tecnologia para outra é proibitivamente caro, e o que você precisa hoje pode não ser o que você precisa amanhã.

Uma arquitetura adaptativa é aquela que permite hospedar seu aplicativo em qualquer tecnologia com a mesma facilidade. Isso permite que você ajuste o ambiente de hospedagem em tempo real, para atender às suas necessidades atuais. Escolhas de tecnologia específicas como AWS Lambda, Fargate, Kubernetes, gRPC, Linkerd, Azure/GCP tornam-se intercambiáveis.

Ao reutilizar construções de linguagem de programação existentes, como funções e manipuladores de eventos, bem como interfaces que são idiomáticas para cada linguagem, as arquiteturas adaptativas tornam os serviços em nuvem mais fáceis de usar.

Procure abstrações e ferramentas que sejam leves, mas flexíveis o suficiente para permitir a troca de tecnologias. Achamos que as anotações do Klotho são adequadas, pois permitem separar o significado semântico de sua arquitetura da configuração de implantação - mas com investimento suficiente em bibliotecas de tempo de execução e automação de infraestrutura, você mesmo pode criar uma solução semelhante.