👩🏿‍🤝‍👩🏼 👩🏾‍💼 😝 Domar a fera: código legado, testes e você 🤱🏿 🧝🏼 🤘🏾

Código legado é um código "antigo", cuja idade pode ser de 2 meses e 10 anos. Muitas vezes, os desenvolvedores escreviam sobre isso, dos quais a empresa lembra vagamente. Talvez eles não existissem, e o código legado nasceu com o Universo durante o Big Bang. Desde então, os requisitos para isso foram alterados várias vezes, o código foi corrigido no modo "era necessário ontem" e ninguém escreveu a documentação, como os testes. O código legado é confuso e frágil, não mostra nem o começo nem o fim. Como abordá-lo?

A seguir, cenas da série "Rick and Morty". Autores Justin Royland e Dan Harmon.

Você precisa chegar até ele com testes, mas prepare-se para a dor. Os problemas já começarão a partir do momento em que você decide realizar esse projeto. Você precisa entender por que deseja realizá-lo, convencer a gerência a aprovar o teste do código legado e ajudar seus colegas. Depois disso, surgem perguntas: por onde começar o estudo, quais testes executar primeiro e como não quebrar tudo? Mas o principal é como não cair em desespero quando você percebe que não há fim para o trabalho.

Kirill Borisov 12 anos na indústria, ao longo dos anos ele percorreu um longo caminho em muletas, códigos quebrados e estruturas apodrecidas de sistemas antigos: de sistemas de contabilidade monolíticos a microsserviços de autorização. A jornada concedeu a ele experiências e histórias que ele compartilhará na forma de conselhos valiosos.

Eu tenho um sonho - um dia trabalhar em um novo projeto. Tudo ficará bem desde o começo e tão fresco quanto a primeira neve: testes, arquitetura e significado. Mas isso é apenas um sonho, porque há 10 anos venho vendendo meu talento por dinheiro e passando de um projeto legado para outro.

Durante esse período, não tenho mais nervos, mas posso salvar os seus compartilhando minha experiência de interagir com o legado. Vou lhe dizer como domesticar a fera (código legado): trabalhe com código e pessoas, implemente testes, se precisa ser feito e como os desenvolvedores se relacionam com isso.

O que não estará aqui:

Dicas para escrever testes. Muitos livros, artigos e vários vídeos abordam essa questão.
Metodologias de discussão. BDD, TDD, ATDD - tudo a seu critério.
Tudo isso pode violar a NDA. As pessoas têm uma memória longa e os advogados têm braços longos.

O que é código legado

Existem muitas definições. Eu acredito que este é um código " bastante antigo " de 2 meses a 10 anos. O código legado é confuso e frágil, mas como uma cobra gigante devora sua cauda.

É isso que não permite que você comece a testá-lo com calma. Todos os desenvolvedores, de iniciantes a experientes, quando chegam a um projeto herdado, pegam uma lança de testes e correm para matar esse monstro. A lança quebra, e com ela as pessoas. Como resultado, permanece um desenvolvedor sem sinais de vida, que trabalha em um projeto legado há décadas.

É possível superar esta fera? Sim, mas é necessária preparação.

Treinamento

Lutar contra a fera não é tão importante quanto a fase preparatória. Começa com três perguntas para si mesmo.

"Por que estou fazendo isto?" Sério, por quê? Afinal, existem apenas duas opções.

, , , .
, .

Você quer trabalhar para o conforto dos outros ou para sua própria glória? Se para este último, com o primeiro sucesso desaparecerá o interesse, você desaparecerá, tudo desaparecerá. Você mudará para outra coisa, e os restos podres de seus empreendimentos obstruirão o projeto por muito tempo.

"Eu sei o que estou fazendo?" Se você escreveu testes, você sabe. Caso contrário, antes de correr para o monstro, domine o básico: escreva 3-4 testes, cubra uma pequena parte do código, preencha sua mão e sinta o poder.

"Eu tenho tempo para isso?" É ótimo intervir no código com bons impulsos e melhorá-lo, trabalhando para o futuro. Mas talvez não haja tempo para isso quando o presente queima. Nesse caso, o projeto precisa de você, não de uma imagem brilhante do futuro.

Quando responder a todas as perguntas afirmativamente, prossiga para a próxima etapa.

Reconhecimento

Examine a estrutura do projeto . Você tem uma idéia sobre a estrutura do projeto, os componentes e o princípio do trabalho? Certamente sim, mas talvez não coincida com a realidade. É importante entender o que você deve enfrentar antes de começar o trabalho. Dedique algum tempo para percorrer o projeto e estudá-lo completamente.

Faça um diagrama de dependência . Nenhum projeto vive no vácuo. Bancos de dados, serviços externos, bibliotecas - tudo isso pode ser usado no projeto.

O que foi feito para você? Você pode não ser o primeiro a lutar contra a fera. Examine as práticas dos “antepassados” que queimaram e deixaram o projeto.

Após o reconhecimento, seguimos para as hostilidades.

Lute com a organização

A primeira rodada é uma briga com sua organização. O principal é o seu gerente, chefe direto.

Gerente . Ele não é tão assustador quanto parece. Essa é uma pessoa comum com necessidades comuns: para entregar o projeto no prazo e sem problemas desnecessários, obtenha dinheiro e bônus por ele e viva.

O líder não é contra seus compromissos. Ele é contra você correndo para o projeto com gritos: “Testes! Testes! Testes! Se você fizer isso, ele olhará para você como a pessoa que gasta seu tempo e retarda o resto.

Mostre o benefício. O gerente fala a língua do bem, tempo e dinheiro. Entenda que eles são motivados pelo desejo de encerrar o projeto no prazo e obter mais resultados por menos recursos.

O teste não deve ser enviado assim:

- Oh, vai ser legal!

Nossas idéias devem ser promovidas da seguinte forma:

- No último trimestre, tivemos 50 falhas que poderiam ser corrigidas no estágio de desenvolvimento do produto. Você pode corrigi-lo usando testes. Eles confirmarão que as alterações não alteraram a funcionalidade, se não esperamos. Economizaremos as horas gastas na resolução desses problemas e reduziremos o valor da penalidade paga devido a um sistema danificado.

Dizendo "otimização, dinheiro, economizando tempo", você fala o idioma do gerente. Quando ele ouve essas palavras, ele está imbuído da idéia. Ele vê em você não o próximo programador raivoso apaixonado por novas tecnologias, mas uma pessoa interessada em melhorar o produto. Ele não aprovará todas as suas idéias de uma só vez, mas é altamente provável que proponha a Prova de conceito.

Prova de conceito aumenta as chances.Forneça ao gerente um trecho de código isolado e separado, um subsistema coberto por testes, iniciado e executado. Isso pode ser feito se você pegar um dos bugs doloridos que aparecem em uma determinada frequência e tentar pegá-lo e corrigi-lo com um teste. O PoC confirmará suas intenções, mostrará que você tem um plano e que seu trabalho traz resultados.

Não prometa muito. Para o gerente, os números são importantes: quais são os resultados, o momento e por quais forças. Mas o gerente é uma criatura gananciosa por resultados. Não prometa demais desde o início. Se você promete resolver todos os problemas de uma só vez, o gerente irá às autoridades com isso. As autoridades dirão: "Ótimo!", Mas reduzirão o financiamento e reduzirão os prazos na esperança de que entregemos o sistema muito antes.

Quando concordamos com o gerente, nos voltamos para aqueles com quem temos que trabalhar todos os dias.

Colegas

Eles não gostam de mudanças. Um colega típico de um projeto legado típico é uma pessoa que perdeu a fé na vida e no futuro. Ele não está inclinado a mudar e se resignou ao destino: "Estou aqui para sempre, não há como escapar do pântano". O problema é que você começa a mexer água nesse pântano. Você exige que ele escreva e execute alguns testes, mas ele quer fazer seu trabalho, fechar a tarefa e ir para casa.

Envolva seus colegas com benefícios - explique por que eles se sentirão melhor. Por exemplo, eles gastam constantemente tempo e esforço, permanecendo após o trabalho para curar alguns bugs. Pressione: "Se você não implantar um código quebrado para produção, não precisará gastar tempo corrigindo-o. Escreveremos testes, pegaremos esse código, ele quebrará menos ".

Mostre paciência e empatia.Você se comunica com as pessoas - pergunte por que elas estão preocupadas com a sua ideia. Sugira encontrar um terreno comum para entender um ao outro. Esta é a principal tática para trabalhar com pessoas: não brigue, não colidir com a testa, seja mais amigável.

Você pode ser impedido de apresentar a ideia antes da reunião de colegas no próximo stand-up da equipe. O mecanismo do "pensamento em grupo" funciona na equipe: ninguém quer tomar uma decisão, todo mundo se olha e vê que ninguém está queimando de entusiasmo.

Há um truque sujo para resolver esse problema. Infelizmente, na minha vida, usei mais de uma vez.

Dividir para reinar. Vá a um de seus colegas no almoço ou no canto e diga: “Toda a equipe já se inscreveu, você é o único que está atrasando o processo. Talvez possamos encontrar uma linguagem comum?

Depois de passar por tudo, você assina todos. Todos terão vergonha de admitir que pensaram que todo mundo já havia se inscrito. É desonroso e terrível, mas funciona. Use esta técnica com responsabilidade e como último recurso. Lembre-se - você ainda precisa trabalhar com essas pessoas.

Quando resolvemos com os colegas, estamos esperando por outro animal ganancioso.

Lute com o carro

Esse é o truque do código chamado produto. Vamos começar com o básico.

Desmonte o lixo. É necessário testar para que, com um impacto mínimo no sistema, obtenha um resultado verificável. Mas qualquer sistema legado está cheio de dados: eles foram adicionados por anos desde o lançamento e afetam o comportamento do sistema. Portanto, é necessário testar "do zero".

Prepare um “sistema esférico no vácuo”: esvazie as fontes de dados, faça as configurações mínimas que o sistema inicia, desative todos os possíveis “hacks” e “recursos”. Faça o sistema iniciar. Se iniciar, você terá o conjunto mínimo de dados necessário para o funcionamento. Este já é um bom ponto de partida - uma "lousa limpa".

Usando alguns efeitos mensuráveis, por exemplo, pressionando um determinado botão, você obterá um resultado de trabalho mensurável. Com isso, você pode prosseguir para a próxima etapa.

Desvendar os dados. Qualquer projeto herdado trabalha com o princípio de "deve ser entregue ontem". Tudo o que você estudou na universidade ou leu nos livros não funciona aqui. Ao iniciar o teste, você encontrará, por exemplo, uma dependência cíclica, impossível de recriar no programa, mas necessária para o funcionamento.

Comece com o "objeto principal". Para lidar com a floresta de dependência, tente pensar sobre qual objeto é o principal. Por exemplo, para o sistema de contabilidade do armazém, o objeto principal é a "caixa". Um objeto de "prateleira" é associado a ele e um objeto de "linha" é associado a uma "prateleira".

Recrie o mínimo necessário.Se você observar os links entre objetos e se aprofundar na árvore de dependência, poderá determinar o mínimo necessário de dados para objetos dependentes. Você precisa recriá-lo para que o sistema funcione e possa funcionar para testar sua funcionalidade.

Não tenha medo de alterar os links. Você pode ter que arregaçar as mangas e mergulhar nessa confusão: excluir e alterar links, alterar a estrutura do banco de dados. Você veio para melhorar o sistema, portanto, não tenha medo de fazer alterações.

Passamos a testes. Para confundir produtos antigos, uma boa estratégia são os testes de fumaça.

Testes de fumaça

O conceito de "teste de fumaça" chegou até nós do mundo da eletrônica. Um engenheiro montou um circuito gigante com um monte de lâmpadas e fios. Mas antes de começar a testar, apenas conectei o circuito a uma tomada. Se a fumaça começou, algo deu errado.

Nos sistemas de informação, o conceito de testes de fumaça é bastante simples. Imagine um serviço da web, ele tem um ponto de extremidade. Vamos tentar enviar a ele uma solicitação GET sem parâmetros. Se, por algum motivo, o produto quebrou repentinamente (erro 500), algo deu errado.

Teste de fumaça é um bom começo . Este é um teste que testa algumas funcionalidades e deixa claro que o sistema está funcionando ou quebrado. Mesmo uma solicitação simples para o terminal mais simples já afeta mais de 1% do código. Com testes tão pequenos, estamos preparando um trampolim para testes adicionais.

O teste de fumaça revela muitos problemas. É possível que durante todo o período de funcionamento do serviço ninguém tenha adivinhado para enviar uma solicitação sem parâmetros.

Use esta tática para cobrir vários pontos de entrada principais do seu programa: formulário de entrada de login / senha, serviços básicos da web, botões. Isso é algo que você já pode mostrar ao gerente e aos colegas.

Testes de função

Estes não são testes de classes individuais ou de um método, mas o nível mais alto possível de testar uma certa parte do funcional.

Imagine a funcionalidade para "gerar um relatório no serviço". Em vez de verificar partes individuais, testamos a situação da solicitação para criar um relatório com determinados parâmetros e obter um arquivo de dados. Não é necessário conhecer o mecanismo para gerar o relatório, mas se o serviço fornecer determinados dados de saída com determinados dados de entrada, essa caixa preta com alguma probabilidade funcionará como deveria.

A cobertura da funcionalidade principal com esses testes permite iniciar rapidamente e cobrir imediatamente grandes áreas. Você terá certeza de que o código funciona pelo menos aproximadamente como você imagina, ganha mais confiança, enche sua mão e revela ainda mais problemas.

Testes funcionais são um meio, não um fim.

É fácil se prender à agulha de teste funcional: "Estou testando a funcionalidade real! É isso que os usuários estão enfrentando. ”

Um teste funcional envolve grandes pedaços de código que podem interagir com quantidades gigantescas de dados. Portanto, 3-4 testes funcionais são bons, 10 são piores e milhares de testes que levam 9 horas são demais. Infelizmente, isso também acontece.

Após os testes funcionais, faça os testes de unidade. Mas não vou falar sobre eles - você já sabe tudo.

Passamos pelas noções básicas de teste de máquina e voltamos ao tópico principal. Colegas e gerente não são o pior inimigo em uma batalha com o legado. O pior inimigo é você mesmo.

Lute consigo mesmo

Esteja preparado para o fato de que o caminho parecerá interminável . Trabalhar por uma semana em seu plano levará seis meses sem as perspectivas de conclusão do projeto.

A resistência é inevitável . Todos os aliados eventualmente começarão a duvidar, tentar sair da pista, convencê-los a sair dos testes e seguir para os recursos. Esteja preparado para isso. Lembre a todos por que você se envolveu em tudo isso, quanto esforço e tempo foram investidos. Argumento fraco, mas pode funcionar.

Ninguém garante sucesso . Mesmo que você mostre esforços heróicos, se dedique ao trabalho, seu projeto ainda poderá se esgotar e a cruzada com os testes terminará em nada.

Isso é normal, não é o fim da vida e da carreira. Isso nem mesmo confirma que você é um profissional ruim. A única conclusão aqui é que esse projeto em particular falhou.

Mas então você tem experiência e conhecimento. Da próxima vez, quando você pegar uma nova lança em sua mão e seu cavalo acelerar para outro moinho de vento, você estará pronto para quebrá-la também, mas mais tarde, por um método diferente e com menos danos.

Agora ofensivo, amargo e eterno.

Palavras de despedida

Não tenha medo de feedback. Eu tive que entrar nessa armadilha e ver como os outros caem nela. Fiz alguma coisa e trouxe colegas para se gabar: “Consegui!” Mas de repente acontece que meu mecanismo conveniente é inconveniente para os colegas, e eu não perguntei.

Escreva testes, tente o que você implementa . Muitas vezes, a introdução de uma nova estrutura de teste é fascinante, mas você não escreve os testes. Pode acontecer que, assim que você os escrever, você entenderá que não pode usar os testes. Talvez os colegas também vejam isso, mas estejam silenciosos ou simplesmente não escrevam testes.

Ajude colegas com problemasmesmo se eles não pedirem. Ajudar não significa assumir todo o trabalho consigo - relaxa os colegas e isenta-os de responsabilidade, e o número do "ônibus" cai para a unidade. Então você se torna um testador humano: algo está quebrado, o CI está vermelho, um guia de teste. Ajuda no âmbito do razoável.

O número do "ônibus" não é uma piada. Você nem sempre pode arrastar o projeto para si mesmo. Todo mundo pode se queimar, sair de férias ou sair. Portanto, transmita aos seus colegas seu conhecimento e responsabilidade, necessários para lidar com você. Isso ajudará a evitar chamadas desagradáveis quando você relaxa na praia, e o IC fica vermelho novamente.

Melhorar os mecanismos de teste. Muitos problemas podem ser evitados simplesmente porque testes lentos de repente se tornaram rápidos. Anteriormente, eles ocupavam 20 linhas de código, mas agora uma. Você não percebeu isso, porque depois que escreveu algo e esqueceu: "Funciona - não toque!" Mas essa regra nem sempre é aplicável.

Você não é o centro do universo. Mais uma vez, repito que o número do "ônibus" não é uma piada. Mais de uma vez me deparei com uma situação em que uma pessoa começou a testar e depois recebeu uma oferta para o projeto mais recente: ele deixou tudo, fugiu, mas não deixou comentários e documentação. Tudo funciona até um novo commit, mas é impossível corrigi-lo - ninguém entende como tudo funciona.

Eu não quero que você seja essa pessoa. Não se torne um fator limitante.

Escreva a documentação.
Realize treinamentos.
Compartilhe sua experiência.

Quando todos os colegas estiverem no mesmo nível que você (mais ou menos), o processo passará de uma corrida de uma pessoa para uma corrida de revezamento de equipe com a passagem da bandeira. Somente com o apoio de seus colegas você terá sucesso. Se você estiver sozinho no projeto, pense que outra pessoa depois de você também sofrerá sozinha. Dê ao seu seguidor um amigo na forma de documentação, não deixe morrer sozinho.

27 Moscow Python Conf++ Python 2 Python 3 — 2020 .

, (fb, vk, twitter) telegram- . !

Domar a fera: código legado, testes e você