[MÚSICA] [MÚSICA] Olá, bem vindo ao curso sobre TDD! Eu sou o Clovis Fernandes e hoje iremos falar sobre refatoração: Quando refatorar? Usualmente a resposta seria sempre no TDD. Vamos mostrar que condições isso realmente ocorre. Então, quando refatorar? Normalmente, quando eu recebo código, eu quero incorporar código legado, código que já está pronto, feito por outras pessoas, no meu sistema é sempre bom refatorar, está certo? Você vai encontrar sempre muitos problemas. Você vai encontrar problemas principalmente relacionados com o acoplamento, não é? Dependências muito grandes, acoplamento alto, e também problemas de coesão, não é? Baixa coesão quando o certo seria ter alta coesão. E outros problemas que a gente normalmente verifica quando está fazendo a refatoração e iremos estudar ao longo deste curso. Eu lembro que uma vez fizemos trabalho com código legado deu, dá muito trabalho fazer refatoração num código grande, está certo? Por isso que é importante, quando eu estou desenvolvendo o meu software, produzir software com qualidade para que, se alguém precisar usar, não sofrer tanto quanto nós sofremos. Nós tivemos muito trabalho, despendemos muito tempo para entender o software, só para entender o software, e depois para modificar por causa dos problemas que esse software tinha. Então código legado é uma coisa que sempre vai precisar refatorar. De qualquer forma, durante o desenvolvimento, quer seja usando projeto TDD ou não, mas principalmente o TDD obviamente, porque o TDD, no ciclo do TDD você tem uma fase que é a de refatoração e nós vamos detalhar algumas coisas dentro dessa fase ainda. E após o desenvolvimento, quer dizer mesmo dentro do ciclo do TDD. Então tem o ciclo do TDD que a gente já mostrou aulas passadas. Naquele momento que eu concluo todos os testes, os casos de testes de uma dada responsabilidade, eu ia lá, marcava essa responsabilidade como done e depois ia verificar se tinha mais responsabilidades. Nesse ponto, quando eu completo todos os casos testes de uma responsabilidade, não é? Está certo? Esse poderia ser ponto potencial de refatorar quando eu, antes de eu introduzir novo requisito, uma nova responsabilidade no nosso caso. Então se o código não está, eu não estava cuidando de refatorar de forma assídua, então nessa hora com certeza eu devo dar uma limpeza, tornar aquele código mais fácil de compreender e provavelmente deixá-lo adequado para alguma mudança, se aquela responsabilidade nova assim o exigir. O que não se deve fazer nesse caso, quando eu estiver usando o chapéu da refatoração, o chapéu azul, é não adicionar nenhuma característica ou responsabilidade nova, isso não faz parte da refatoração, está certo? Isso faz parte do, da, das outras fases do ciclo do TDD, do chapéu vermelho e do chapéu verde. Também não se adiciona teste, está certo? Se eu tiver que perceber que algum teste precisa ser feito, eu vou introduzir naquela lista de casos de testes para ser feito depois, está certo? Não durante a refatoração. Eu posso até, ao fazer a refatoração, entender pouquinho melhor e descobrir que está faltando alguma coisa para testar, mas aí eu coloco lá naquela lista, se for referente aquela responsabilidade, se for referente a uma responsabilidade anterior, eu, quando terminar os casos testes desta responsabilidade, eu retomo aquela responsabilidade anterior para fazer o tratamento daquele caso teste que eu acabei de descobrir. Então basicamente o que é que diferenciam as atividades das fases do chapéu verde, das atividades da fase do chapéu azul, da refatoração? As duas têm algo igual que elas transformam o código anterior de alguma forma, está certo? Mas o que é que diferencia? Vamos ver isso nessa próxima transparência. No caso do chapéu verde, na hora que eu, que eu tenho que tornar caso de teste que falhou, que eu fiz de propósito falhar na fase anterior, eu tenho que fazer ela funcionar e para isso eu vou transformar, eu vou adicionar código de produção, está certo? Para fazer esse teste funcionar, é isso que eu vou fazer, está certo? Mas o resultado disso é que eu estou mudando a bateria de testes, eu estou agora com novo teste bem sucedido. Eventualmente algum teste da bateria do passado pode vir a não funcionar mais, eu ter que remover, ou seja, eu posso ter que remover esse teste. Por exemplo, quando a gente falou sobre aquele sisteminha de contador de strings de caractere dentro de string. Quando a gente queria fazer para 2 strings, não dava para fazer porque o que eu tinha planejado era sempre caracter. Suponha que agora eu tenha uma nova responsabilidade, que é agora que eu possa fazer a contagem de 2 caracteres seguidos. Então quando da anterior, o código de teste apontava erro, quando eu usava essa rotina para procurar 2, agora faz parte, eu não, eu tenho que retirar aqueles casos de testes que apontavam erro, porque isso não faz mais sentido porque a nova responsabilidade que está funcionando agora, aceita fazer a ocorrência, procura de a ocorrência de caracteres, de 1 caracter e de 2 caracteres, está certo? Então eu tenho que mudar. Já no caso da refatoração, eu transformo o código de produção, mas a diferença da fase anterior, quando eu uso o chapéu verde, é que eu vou manter o comportamento observado, prévio do software, ou seja, a bateria de testes continua a mesma antes de eu fazer a refatoração e depois da refatoração. Na verdade ela é o meu salvo-conduto, ela vai me ajudar a garantir que eu faça as transformações, as refatorações, mudando, reestruturando o meu código de produção para ele ficar código melhor, de maneira segura porque se eu testar, eu sempre tenho que testar, eu vou fazendo passo a passo as refatorações e vou testando, se num dado momento a bateria falhar, de testes falhar significa que eu dei passo falso, a primeira atitude que é retornar ao código que estava funcionando, está certo? E aí eu vou estudar se, o que é que foi que eu posso melhorar na minha refatoração, para que o próximo passo seja também bem sucedido e assim por diante, fazendo para todas as refatorações que eu estiver fazendo. A outra pergunta que surge é: como é que eu sei que eu tenho que refatorar, está certo? Como a gente diz, muitas vezes eu passo nesse ciclo do TDD e não refatoro nada. Na verdade eu não sou obrigado a refatorar, está certo? Mas eu tenho que seguir algumas diretrizes, está certo? Uma delas é aquela que eu falei de quando eu adiciono uma nova responsabilidade, ou seja, eu testei a responsabilidade anterior completamente, então antes de iniciar a seguinte eu faço uma refatoração. Se eu achar que realmente o código já está bem estruturado, eu posso também não fazer, não há uma obrigação nesse sentido. É mais no sentido uma diretriz que você deve observar, está certo? O outro caso que eu, que seria também provável de que eu tenho, que eu vou ficar sabendo que eu tenho que refatorar, é quando alguém da equipe descobre algum bug e ao eliminar, remover esse bug, esse erro que estava no programa, está certo? É de bom tom fazer a refatoração, porque a técnica de programar continua sendo a mesma do TDD. Eu vou, eu vou por código ali que vai fazer funcionar e, ao fazer isso, pode ser que eu não siga todas as boas práticas de programação. Nessa hora eu passo novamente, se por acaso era bug simples e não produziu nada de muito estranho no código, o código continua ainda bem estruturado, eu, eu não vou precisar fazer essa refatoração. Outra coisa que a gente segue é o que o Fowler no livro de refatoração dele, que ele junto com outros escreveu para a linguagem Ruby, mas que o que ele fala serve para qualquer linguagem na verdade, 2009 que ele falou isso, é o que ele chama de a Regra de Três, está certo? A Regra de Três ela se aplica na hora que eu estou com o chapéu verde, está certo? Por isso que vocês estão vendo ali que eu estou usando, mostrando chapeuzinho verde. A primeira vez que eu escrevo código, eu vou lá e faço, para satisfazer teste que estava falhando, está certo? Isso é a regra. A segunda vez que aparece algo similar a esse anterior, no passo seguinte ou algum passo mais para a frente, não importa, mas é similar, está certo? Talvez eu fique meio, o que é que vai acontecer? Provavelmente vai haver uma duplicação de código, eu vou ser redundante. Então eu posso até fazer uma careta, ficar meio chateado por que eu estou deixando a duplicação, mas faço assim mesmo, duplico o código assim mesmo. A terceira vez que aparece algo semelhante, que vai triplicar o código, não é? Está certo? Nessa hora agora eu já não fico tão chateado, porque eu simplesmente triplico e sei que, quando eu mudar o chapéu do verde para o azul, a primeira coisa que eu vou fazer é refatorar, está certo? Ou seja, a regra de três está me, está me dizendo isso. Ele deu o nome de regra, porque seria uma coisa que você deve seguir sempre. Mas toda regra tem exceção, então essa também tem exceção, não é? O, é o caso de que, pode ser que quando eu estou seguindo os meus casos testes eu estou escolhendo alguns que eu já sei que vai haver duplicação, então eu já sei como é que aquilo vai ser feito, então eu já posso ir, logo após ele, fazendo a refatoração e já deixo pronto para os próximos. Também isso pode acontecer, vai depender da sua experiência fazer esse tratamento e observar isso com bastante cuidado e ver que é possível fazer sem problemas, está certo? Se não, vá no seguro, segue direitinho a Regra de Três e depois refatora de uma vez, está certo? Então quando refatorar então? Obviamente nós mostramos que eu posso refatorar logo, eu posso não refatorar na verdade, está certo? Eu não sou obrigado a refatorar. O ideal é sempre fazer refatorações constantes, mas dado momento ou outro eu posso não refatorar. Mas quando eu vou introduzir uma nova responsabilidade, uma nova funcionalidade, com certeza esse é bom ponto para eu refatorar. Quando eu vou fazer uma revisão de, para eliminar bug, também, está certo? E usando a Regra de Três. Ou seja, basicamente sempre. Esse, sempre que possível, porque aí eu faço pequenas refatorações. Eu vou fazendo isso, vez de fazer grandes refatorações. Grandes refatorações dão trabalho, pequenas refatorações dão menos trabalho. Fazendo com cuidado, porque eu vou estar sempre lastreado pela pela bateria de testes, eu não vou ter grandes problemas. Com isso pessoal, quando refatorar? Ficou respondido, sempre dentro do TDD. Obrigado! [MÚSICA]
