Neste curso, assumimos que você já sabe projetar e desenvolver programas mais complexos em Java, com método e organização graças às boas práticas e princípios exercitados no curso anterior; mas você talvez não se sinta ainda confortável em projetar programas usando técnicas ágeis, como o desenvolvimento guiado por testes (TDD). O objetivo deste curso é expor você aos princípios e práticas de desenvolvimento guiado por testes, tanto para modelar quanto para desenvolver aplicações e componentes de software, sem abandonar os conceitos e princípios de orientação a objetos aprendidos no curso anterior. De fato, pregamos que tais conceitos e princípios fortalecem o emprego do TDD no desenvolvimento ágil de software com mais qualidade. Este curso terá um grande foco em atividades hands-on, permitindo a você captar todos os aspectos práticos da técnica e facilitar a sua aplicação quando estiver projetando e desenvolvendo software de maneira ágil nos próximos cursos. Os conceitos de desenvolvimento de software com Java apresentados neste curso incluem o seguinte: revisão de testes de unidade; automação de testes; desenvolvimento guiado por testes; ciclo do TDD; refatoração de código de produção; ciclo de refatoração; uso de objetos stubs e mocks; boas práticas no TDD; modelagem de software por meio do TDD. Ao final deste curso, você terá amadurecido de tal modo suas habilidades de programação que será capaz de implementar, agora usando o TDD, versões modificadas e estendidas do componente de gamificação constante do Trabalho de Conclusão da Especialização, com base nas boas práticas exercitadas neste curso.
Conhecendo a Refatoração: Quando refatorar?
Loading...
Do curso por Instituto Tecnológico de Aeronáutica
TDD – Desenvolvimento de Software Guiado por Testes
313 ratings
Na lição
Semana 1
Olá, bem-vindo ao Curso 2 – Desenvolvimento de Software Guiado por Testes. Neste módulo você fará contato com os conceitos básicos de TDD. Ao final desta semana, você será capaz de: 1) entender como funciona o TDD e, principalmente, que o TDD é uma técnica poderosa de projeto e desenvolvimento de software; 2) será capaz de entender o papel fundamental da Refatoracão dentro do ciclo do TDD, permitindo a você alcançar um código de mais qualidade passo a passo e continuamente!
Conheça os instrutores
Clovis FernandesProfessor Titular in Portuguese
Ciência da Computação
Eduardo GuerraProfessor Colaborador
[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]
Explore nosso catálogo
Registre-se gratuitamente e obtenha recomendações, atualizações e ofertas personalizadas.
O Coursera proporciona acesso universal à melhor educação do mundo fazendo parcerias com as melhores universidades e organizações para oferecer cursos on-line.
© 2018 Coursera Inc. Todos os direitos reservados.
