Por volta de março de 2017, me pediram para fazer uma revisão de código do produto antes do lançamento. Essa empresa teve problemas com vazamentos de memória, falhas espontâneas, carregamento lento, picos no consumo de CPU e um lançamento foi planejado em algumas semanas. Você já deve ter ouvido essa história - não de mim e nem dessa empresa. Ela é surpreendentemente típica.
Nos reunimos no fim de semana e começamos a analisar o código juntos. Após cerca de meio dia, uma fonte de problemas conhecidos foi descoberta e outro meio dia foi necessário para escrever um documento de correção para os desenvolvedores. O lançamento foi um sucesso, mas a história me fez pensar: como o produto chegou a esse estado.
Quando conversei com os desenvolvedores, eles pareciam pessoas inteligentes. O único problema óbvio foi a falta de experiência. Eu já deparei com isso antes. Este é um fenômeno comum e bastante normal. Mas, neste caso, foi observada uma falha hedionda: a experiência não era suficiente para
todos os desenvolvedores.
Um departamento de desenvolvimento foi criado recentemente e uma equipe foi contratada na ausência de um diretor técnico. Mesmo um técnico tem dificuldade para testar outro programador - nem consigo imaginar um teste sem conhecimento técnico. Eles contrataram o primeiro desenvolvedor, ele verificou o segundo desenvolvedor - e assim por diante, até que uma equipe foi formada.
Se você tiver sorte e o primeiro desenvolvedor tiver uma experiência significativa e um desejo de treinar, então estará no papel. Mas se você não tiver sorte - e as chances disso são muito altas -, você receberá uma equipe em rápido movimento que cria software muito frágil.
"Aja rapidamente e quebre tudo", eles dizem. Mas essa é uma péssima idéia se a empresa conta com um pequeno número de grandes clientes. Produtos quebrados geralmente os afugentam, o que, por sua vez, afeta seus negócios. Você pode descrever a estratégia efetiva de diferentes maneiras, mas a frase “movendo-se lenta e firmemente em direção à meta” claramente não é impressionante.
De fato, há um equilíbrio entre movimento rápido e lento. É difícil encontrar esse equilíbrio, porque cada produto tem seu próprio equilíbrio. Suponho que a intuição é baseada na experiência, e esta é uma resposta terrível para um iniciante.
O que fazer para o novo desenvolvedor?
Parece natural procurar uma resposta na Internet. Acontece que é
incrivelmente eficaz .
Mas também é
incrivelmente perigoso .
Eu colaborei com essa empresa após o lançamento do produto. Examinei uma quantidade significativa de código, ajudei no treinamento de desenvolvedores e criei novos projetos para eles. Tudo correu bem.
Certa vez, minha atenção foi atraída por um pedaço de código. Eu poderia jurar que o vi antes. É claro que, pesquisando a linha no Google, encontrei uma cópia exata do código em uma postagem do blog. Naturalmente, li o artigo inteiro - até o parágrafo que dizia:
"Não faça isso na produção" .
Mas essas linhas estão me olhando diretamente da base de código em produção.
Não demorou muito tempo para encontrar muitos trechos de código de artigos semelhantes. Um aviso foi escrito em quase todos os lugares, ou claramente não foi suficiente. Todos eles resolveram um pequeno pedaço do problema, mas permitiram muitas liberdades para facilitar a leitura do código. Isso pode ser entendido. A maioria dos leitores aprecia a brevidade ao aprender um conceito.
O código dessas entradas do blog se espalhou pela base de código como uma infecção, causando problemas aqui e ali sem qualquer motivo ou padrão. E não havia cura óbvia além de ler todo o código em uma linha e corrigir manualmente os problemas um por um. Sem testes de unidade e implantação automática, demorou
quase um ano . Tenho certeza de que o custo de corrigir o código excedeu o custo de escrevê-lo.
Mas que escolha esses desenvolvedores tiveram? Eles precisavam lançar algo e nunca haviam lançado um aplicativo em produção. Portanto, eles fizeram o que qualquer pessoa sã tentaria fazer - e aprenderam ao longo do caminho.
Os sistemas de produção falham de várias maneiras. Sem experiência ou conhecimento teórico dessas falhas, é difícil entender intuitivamente como prevenir ou resolver esses problemas. É difícil exigir que uma nova equipe alcance um resultado perfeito, especialmente sem algum tipo de liderança.
Antes de continuar, quero observar que todas as pessoas que participaram do caos tinham boas intenções. Os desenvolvedores queriam criar um bom produto e desenvolver. Os gerentes queriam a mesma coisa. Os autores do blog queriam compartilhar soluções úteis. Todos tentaram se ajudar, e é importante lembrar disso.
O problema não está nas pessoas.Eu simpatizo muito com os desenvolvedores que estão nessa posição. Eles têm mais informações do que jamais precisarão, mas estão completamente desorganizadas. Isso é semelhante a tentar montar um quebra-cabeça de dez partes; você só precisa encontrá-las em um monte de 10.000.000 de peças, onde todas as peças são quadradas e o resultado final é desconhecido. Boa sorte
Se você lê aqui esperando uma resposta, lamento: não tenho uma resposta simples. Este problema é difícil de resolver. A solução é muito grande para um artigo, muda todos os dias e difere nas nuances de cada projeto.
Esse problema me levou a iniciar um blog. Tive a sorte de aprender com mentores, escritores e colegas incrivelmente talentosos por quase vinte anos. Sem o conselho dessas pessoas, eu ainda estaria escrevendo diretivas
GOTO no QBasic (brrr). É hora de pegar a bola e atacar.
Para resumir.
Este blog é dedicado a todos os aspectos do desenvolvimento de aplicativos prontos: da automação da infraestrutura ao teste, design, depuração, documentação, processo de desenvolvimento e segurança. Cada artigo é independente e adequado para uso no mundo real -
adequado para uso na produção .