Advertisement
  1. Code
  2. Programming Fundamentals
Code

Refatorando Código Legado: Parte 10: Dissecando Métodos Longos Através de Extrações

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called Refactoring Legacy Code.
Refactoring Legacy Code: Part 9 - Analyzing Concerns
Refactoring Legacy Code - Part 11: The End?

Portuguese (Português) translation by Erick Patrick (you can also view the original English article)

Na sexta parte de nossa série, falamos sobre como trabalhar com métodos longos, através do uso da programação em par e da visualização de código em diferentes níveis. Continuamente, aumentamos e diminuímos o nível de visualização, e observamos tanto coisas pequenas como a parte da nomeação, quanto a forma e a indentação do código.

Hoje, usaremos outra abordagem: Assumiremos que estamos sozinhos, sem companheiros de trabalho para nos ajudar. Usaremos uma técnica chamada "Extrair até a exaustão" que divide o código em várias pequenas partes. Esforçar-nos-emos para fazer com que essas partes sejam o mais entendíveis possível, de modo que nós do futuro, ou qualquer outro programador, sejam capazes de entendê-las facilmente.

Extrair Até A Exaustão

A primeira vez que ouvi falar desse conceito foi a partir do Robert C. Martin. Ele apresentou essa ideia em um de seus vídeos, como uma forma simples de refatorar códigos que são difíceis de entender.

A ideia básica é pegar partes pequenas e entendíveis de código e extraí-las. Não importa se você conseguir identificar quatro linhas de código ou quatro caracteres que podem ser extraídos. Ao identificar algo que pode ser encapsulado em um conceito mais claro, você deve extraí-lo. Você continua a fazer isso tanto no método original quanto nas partes recém extraídas, até que você não possa mais encontrar partes de código que possam ser encapsuladas de alguma outra forma.

Essa técnica é bastante útil quando se trabalha sozinho. Ela força você a pensar tanto nas partes pequenas quanto nas partes grandes de código. Ela tem um outro ótimo efeito: ela faz você pensar, e muito, sobre o código! Além da refatoração de extração de método ou variável mencionados acima, você realizará várias renomeações de variáveis, funções, classes e muito mais.

Vejamos um exemplo de um código aleatório da Internet. O Stackoverflow é um ótimo lugar para encontrar pequenos trechos de código. Eis um trecho que determina se um número é primo:

A essa altura, não tenho ideia como esse código funciona. Apenas o encontrei na Internet enquanto escrevia esse artigo e aprenderei mais sobre ele, junto de você. O processo a seguir pode não ser o mais claro. Ao invés disso, ele refletirá meus pensamentos e refatorações de acordo com que elas forem surgindo, sem qualquer planejamento anterior.

Refatorando o Verificador de Números Primos

De acordo com a Wikipedia:

Um número primo é um número natural maior que 1 que não possui quaisquer outros divisores além do 1 e dele próprio. 

Como pode ver, esse é um método simples para um problema matemático simples. Ele retorna true ou false, então, deve ser bem fácil testá-lo.

Como estamos apenas brincando com um código de exemplo, o caminho mais fácil é colocar tudo dentro de um arquivo de teste. Dessa forma, não precisaremos pensar sobre quais arquivos criar, a quais diretórios eles pertencem ou como incluí-los uns nos outros. Este é um exemplo simples para familiarizarmo-nos com a técnica antes de aplicarmos em um dos métodos do jogo de perguntas e respostas. Então, como tudo irá num só arquivo de testes, você pode nomeá-lo como deseja. O nomeei de IsPrimeTest.php.

Esse teste passa. Meu instinto me diz que o próximo passo é adicionar alguns outros números primos e escrever um outro teste com números não primos.

Isso passa. Mas, e quanto a isso?

Inesperadamente, falha: 6 não é um número primo. Esperava que o método retorna-se false. Não sei como o método funciona, ou o propósito do parâmetro $pf - simplesmente esperava que ele retornasse false, baseado no seu nome e descrição. Faço a menor ideia do porque não funciona ou como corrigi-lo.

Esse é um dilema bem confuso. O que deveríamos fazer? A melhor resposta de criar testes que passem para uma grande quantidade de número. É na tentativa e erro, mas, pelo menos, teremos alguma ideia sobre o que o método faz. Depois disso, poderemos começar a refatora-lo.

Ele retorna algo bem interessante:

Um padrão começa a emergir. Tudo sai como true até o número 9, quando começa a alternar com false até o 19. Mas, há algum padrão em repetição? Tente executá-lo para 100 números e, imediatamente, verá que não é um padrão. Ele parece funcionar para números entre 40 e 99. Ele falha com números entre 30 e 39, dizendo que o 35 é primo. O mesmo acontecem no conjunto 20 a 29, onde ele diz que o 25 é primo.

Esse exercício iniciou como um código simples para demonstrar uma técnica que se mostra muito mais difícil que o esperado. Resolvi mantê-la, porque ela reflete a vida real de uma forma bem pertinente.

Quantas vezes você começou a trabalhar em uma tarefa que pareceu ser simples e acabou descobrindo que era extremamente difícil?

Não queremos corrigir o código. Independentemente do que o método faz, ele deve continuar a fazê-lo. Queremos refatorá-lo para que outros possam entendê-lo melhor.

Como ele não aponta corretamente os número primos, usaremos a mesma abordagem do Resultado Esperado que usamos no primeiro artigo.

Execute esse código uma vez para gerar o Resultado Esperado. Ele deve executar bem rápido. Se precisar executá-lo novamente, não esqueça de remover o arquivo gerado antes de executar o teste. Ou o resultado será adicionado ao final do conteúdo anterior.

Agora, crie o testes para o resultado esperado. Essa solução pode não ser a mais rápida, mas é fácil de entender e dirá qual o número exato não combina, caso algo dê errado. Mas, do jeito que está, existe duplicação de código em dois métodos de testes. Poderíamos extraí-la em um método private.

Agora, podemos continuar para nosso código de produção. Os testes executam em cerca de dois segundos no meu computador, então, é algo aceitável.

Extraindo Tudo Que Pudermos

Primeiro, podemos extrair um método chamado isDivisible(), na primeira parte do código.

Isso nos permitirá reusar o código na segunda parte do código, dessa forma:

E, tão logo começamos a trabalhar com esse código, percebemos que ele é mal indentado e alinhado. Algumas vezes, as chaves aparecem no começo da linha, outras vezes, no final. 

Algumas vezes, vemos o uso de tabulação para indentação, outra vezes vemos espaços. Algumas vezes, há espaços entre operando e operador, outras vezes não. E, não, esse código não foi criado para ser desse jeito. Isso é código da vida real. Código de verdade, não algum exercício artificial.

Assim está muito melhor. Imediatamente, as duas declarações if estão bem parecidas. Mas não podemos extraí-las por conta das declarações return. Se não retornarmos algo, quebraremos a lógica.

Se o método extraído retornar um booleano e tivermos de verificar se devemos retornar do isPrime(), isso não ajudaria em qualquer coisa. Deve existir uma forma de extraí-lo através do uso de conceitos funcionais no PHP, talvez depois. Podemos fazer algo mais simples, primeiro.

Extrair o laço for por completo é um pouco mais fácil, mas, ao tentarmos reutilizar nosso método extraído na segunda parte do if, percebemos que ele não funciona. Isso se dá pela existência da misteriosa variável $pf, a qual sabemos quase nada. 

Parece que ela verifica se o número é divisível por um conjunto específico de divisores ao invés de pegar todos os divisores até o número mágico determinado por intval(sqrt($num)). Talvez devêssemos renomear $pf em $divisors.

Essa é uma das formas de fazer. Adicionamos um quarto parâmetro adicional em nosso método de verificação. Se ele possuir algum valor, usamos, caso contrário, usamos $i.

Podemos extrair alguma outra coisa? Que tal esse pequeno trecho de código: intval(sqrt($num))?

Isso não está muito melhor? De certa forma. Está melhor se a pessoa não souber o que intval() e sqrt() realizam, mas não ajuda a melhorar o entendimento da lógica. Por que terminamos nosso laço for naquele número em específico? Talvez essa seja a pergunta o nome da nossa função devesse responder.

Isso está melhor, já que explica o porque paramos nele. Talvez, no futuro, possamos inventar uma fórmula diferente para determinar aquele número. A nomeação também trouxe um pouco de inconsistência. Nós chamamos de fatores dos números, que é um sinônimo de divisores. Talvez devêssemos escolher um e usar apenas aquele. Permitirei você realizar a renomeação e refatoração como um exercício.

A pergunta é: podemos extrair algo mais? Bem, devemos tentar até a exaustão. Mencionei a possibilidade de aplicar o paradigma funcional no PHP, alguns parágrafos acima. Existem duas características da programação funcional que podemos aplicar no PHP, facilmente: funções de primeira ordem e recursão. Toda vez que vejo uma declaração if junto de um return dentro de um laço for, como no nosso método checkDivisorsBetween(), imagino a aplicação de uma ou das duas técnicas.

Mas, por que deveríamos passar por esse processo tão complexo? O motivo mais chato para isso é que esse método realiza duas coisas distintas: Ele itera e toma decisões. Quero que ele apenas itere e deixe a decisão para outro método. Um método sempre deve realizar uma única coisa e da melhor forma possível.

Nossa primeira tentativa foi extrair a condição e a declaração de retorno em uma variável. Ela será local, por hora. Mas o código não funciona. Na verdade, o laço for complica bastante as coisas. Acho que precisaremos lançar mão de recursão.

Quando pensamos sobre recursividade, devemos sempre começar com os casos excepcionais. Nossa primeira exceção é quando chegamos ao final da recursão.

Nosso segundo caso excepcional que quebrará a recursão é quando o número for divisível. Não queremos que a recursão continue. E esses sãos todos nossos casos excepcionais.

Essa é uma outra tentativa de usar recursão em nosso problema, mas, infelizmente, mais de 10mil recursões no PHP induz a uma falha na sistema do PHP ou do PHPUnit, no meu computador. Então, isso talvez seja um outro beco sem saída. Mas, se tivesse funcionando, seria um ótima substituto para a lógica original.

Desafio

Quando criei o Resultado Esperado, deixei passar algo, intencionalmente. Digamos apenas que os testes não cobrem tanto código quanto deveriam. Você é capaz de encontrar o problema? Se sim, como você o resolveria?

Pontos Finais

"Extraia até a exaustão" é uma ótima maneira de dissecar métodos longos. Ela força você a pensar em pequenos trechos de códigos e dar sentido a essas peças, extraindo-as em métodos. Acho incrível como esse simples procedimento, junto de renomeação frequente, ajudam-me a descobrir que algum código é capaz de fazer algo que eu nunca pensei que pudesse.

Em nosso próximo e último artigo sobre refatoração, aplicaremos essa técnica no jogo de perguntas e respostas. Espero que tenha gostado desse tutorial, um tanto quanto diferente. Ao invés de trabalhar com exemplos de livros, pegamos um código de verdade e começamos a lutar contra exemplos reais que vemos todos os dias.

Seja o primeiro a saber sobre novas traduções–siga @tutsplus_pt no Twitter!

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.