Quais são os pontos-chave de trabalhar efetivamente com o código legado? [fechadas]

120

Eu vi o livro Trabalhando efetivamente com o código herdado recomendado algumas vezes. Quais são os pontos-chave deste livro?

Existe muito mais para lidar com código legado do que adicionar testes de unidade / integração e, em seguida, refatorar?

    
por Armand 28.11.2011 / 08:42
fonte

5 respostas

142

O principal problema com o código legado é que ele não tem testes. Então você precisa adicionar alguns (e depois mais ...).

Isso em si exigiria muito trabalho, como @mattnz observou. Mas o problema especial do código legado é que ele nunca foi projetado para ser testável . Então, normalmente é uma confusão enorme de código espaguete, onde é muito difícil ou absolutamente impossível isolar peças pequenas para serem testadas na unidade. Então, antes do teste de unidade, você precisa refatorar o código para torná-lo mais testável.

No entanto, a fim de refatorar com segurança, você deve ter testes de unidade para verificar se você não quebrou nada com suas alterações ... Essa é a captura 22 do código legado.

O livro ensina como sair desse problema, fazendo as alterações mínimas, mais seguras, absolutas no código apenas para habilitar os primeiros testes unitários. Estes não são feitos para tornar o design mais agradável - apenas para permitir testes unitários. Na verdade, às vezes eles tornam o design mais feio ou mais complexo. No entanto, eles permitem que você escreva testes - e depois de ter testes de unidade no lugar, você está livre para fazer o design melhor.

Existem muitos truques para tornar o código testável - alguns são óbvios, outros não são de todo. Existem métodos que eu nunca teria pensado sobre mim mesmo, sem ler o livro. Mas o que é ainda mais importante é que o Feathers explica o que torna precisamente uma unidade de código testável. Você precisa cortar dependências e introduzir barreiras em seu código, mas por duas razões distintas:

  • sentindo - para verificar e verificar os efeitos da execução de um trecho de código e
  • separation - para obter a parte específica do código em um arnês de teste antes de tudo.

Cortar dependências com segurança pode ser complicado. Introduzir interfaces, mocks e Injeção de Dependência é um objetivo limpo e agradável, mas não necessariamente seguro para fazer neste momento. Então, às vezes temos que recorrer à subclassificação da classe sob teste, a fim de substituir algum método que normalmente, por exemplo, iniciar um pedido direto para um banco de dados. Outras vezes, podemos até precisar substituir uma classe de dependência / jar por uma falsa no ambiente de teste ...

Para mim, o conceito mais importante trazido por Feathers é costuras . Uma costura é um lugar no código onde você pode alterar o comportamento do seu programa sem modificar o próprio código . Criar emendas em seu código permite separar o pedaço de código em teste, mas também permite que você detecte o comportamento do código em teste mesmo quando é difícil ou impossível fazer diretamente (por exemplo, porque a chamada faz alterações em outro objeto ou subsistema, cujo estado não é possível consultar diretamente a partir do método de teste).

Esse conhecimento permite que você perceba as sementes da testabilidade na pilha de código mais desagradável e encontre as alterações mínimas, menos prejudiciais e mais seguras para chegar lá. Em outras palavras, para evitar refatorações "óbvias" que correm o risco de quebrar o código sem que você perceba - porque você ainda não <<> tem os testes unitários para detectar isso.

    
por 28.11.2011 / 09:58
fonte
89

Maneiras rápidas de obter os pontos-chave de Trabalhando efetivamente com o código herdado

por 28.11.2011 / 18:57
fonte
37

Eu trabalho em uma base de código de milhões de linhas de código, algumas que remontam à década de 1980. É apenas software, então é só uma questão de escrever alguns testes de unidade, então você pode ir e refatorar isso, e torná-lo muito melhor.

A palavra chave aqui é apenas - é uma palavra de quatro letras que não pertence ao vocabulário de nenhum programador, muito menos a quem está trabalhando em sistemas legados.

Quanto tempo você acha necessário para escrever um teste de unidade, para testar uma hora de esforço de desenvolvimento? Para discussão, digamos outra hora.

Quanto tempo é investido no sistema legado de milhões de linhas e 20 anos? Vamos dizer, 20 desenvolvedores por 20 anos vezes 2000 horas / ano (eles trabalharam muito duro). Vamos agora escolher um número - você tem novos computadores e novas ferramentas, e você é muito mais esperto do que os caras que escreveram essa peça de $% ^^ em primeiro lugar - digamos que você vale 10 deles. Você tem 40 anos homem, bem, você tem ...?

Portanto, a resposta à sua pergunta é que há muito mais. Por exemplo, essa rotina é de 1000 linhas (eu tenho algumas que são mais de 5000), é excessivamente complexa e é um pedaço de espaguete. Seria apenas (mais outra palavra de quatro letras) levar alguns dias para re-fatorar em algumas rotinas de 100 linhas e mais algumas ajudantes de 20 linhas, certo? ERRADO. Oculto nessas 1000 linhas estão 100 correções de bugs, cada uma uma exigência de usuário não documentada ou um caso de borda obscuro. São 1000 linhas porque a rotina original de 100 linhas não funcionou.

Você precisa trabalhar com a mentalidade " se não estiver quebrado, não consertá-lo ". Quando está quebrado, você precisa ser muito cuidadoso ao consertar - enquanto melhora, que você acidentalmente não muda outra coisa. Note que "quebrado" pode incluir código que é inatingível, mas funcionando corretamente, depende do sistema e do seu uso. Pergunte "o que acontece se eu estragar tudo e piorar", porque um dia você vai, e você terá que dizer ao chefe dos patrões por que você escolheu fazer isso.

Estes sistemas podem sempre ser melhorados. Você terá um orçamento para trabalhar, uma linha do tempo, o que for. Se você não - vá e faça um. Pare de melhorar quando o tempo / dinheiro acabar. Adicione um recurso e tenha tempo para melhorar um pouco. Corrigir um bug - novamente, gastar um pouco de tempo extra e torná-lo melhor. Nunca entregue isso pior do que quando você começou.

    
por 28.11.2011 / 09:32
fonte
17

Existem dois pontos-chave para tirar do livro.

  1. Código legado é qualquer código que não tenha cobertura de teste.
  2. Sempre que você precisar alterar o código legado, verifique se ele tem cobertura.

Como outros entrevistadores apontaram, tentar atualizar preventivamente seu código legado existente é uma recado de idiota . Em vez disso, sempre que você tiver que fazer uma alteração no código legado (para um novo recurso ou uma correção de bug), reserve um tempo para remover seu status herdado.

    
por 28.11.2011 / 17:51
fonte
6

Em uma casca de noz que é verdade - adicionar testes e refatoração é o que é tudo isso.

Mas o livro oferece várias técnicas diferentes para fazer isso com código que é muito difícil de testar e refatorar com segurança.

    
por 28.11.2011 / 09:19
fonte