[MÚSICA] [MÚSICA] Olá, bem vindo ao curso sobre TDD. Eu sou Clovis Fernandes e hoje iremos responder, por que refatorar? Nós temos mostrado que no TDD, no ciclo do TDD, nós temos a fase de refatoração então por que refatorar? Para garantir qualidade no software produzido, para obter, para produzir software de qualidade, é isso que nós esperamos mostrar nessa aula. Então, por que refatorar? Para obter software de qualidade, para obter qualidade no software. Nós examinamos o software, nós vamos verificar algumas características, nós vamos ver mais para a frente, está certo? Nós vamos examinar o fato de o software apresentar alguns sintomas de que não tem qualidade, está certo, esses sintomas a gente chama de mal cheiro, para adiantar, mas então a gente vai examinar e no final, eu vou transformar esse software, eu vou refatorar garantindo que ele tenha o mesmo comportamento, está certo? E aí eu posso então, atestar que ele é software de qualidade, ou seja, ao final desse proceso do TDD eu posso então ter software com uma qualidade melhor. O que eu quero obter é isso. Quer dizer, como nós definimos anteriormente, software de qualidade? Bom, quando eu estou fazendo ciclo de TDD, eu tenho lá caso de teste gero teste no JUnit e faço ele falhar. Depois eu passo, isso na parte vermelha, depois na parte verde eu vou construir código para fazer ele funcionar. Está certo? Então isso é o mínimo que a gente espera, que ele já esteja funcionando, está certo? Então a chance de o software atender a todos os requisitos é bastante garantida nesse fato. Pelo ciclo do TDD nós não garantimos? É que eu construo software de muita qualidade ali, porque, na verdade eu vou tentar fazer o mais rápido possível, o mais simples possível, o desenvolvimento do código de produção para que determinado caso de teste seja aprovado, está certo? Então eu não me preocupo muito. Lógico que com o tempo, com a experiência, eu passo a já embutir muitos princípios de qualidade na hora que eu já estou criando o código, melhor, está certo? Mas eu, não é uma preocupação. Então a preocupação depois é, para ter código de qualidade, é que o código não só funcione, isso é o mínimo, é o básico, está certo? É que ele seja escrito para os desenvolvedores, porque são, eu que estou desenvolvendo e os meus colegas e os futuros desenvolvedores que vão manter esse software, eles precisam entender, então o código tem que ser escrito e refatorado para esse nível de qualidade que os desenvolvedores não tenham muita dificuldade depois. Então o código tem que estar limpo, claro, está certo? Que seja fácil de ler, ou mais fácil possível de ler, ou mais fácil possível de compreender, porque eu vou querer fazer e promover mudanças. Então isso é o que reflete o que eu chamo de software de qualidade. Conferir qualidade ao software, está certo? É garantir essas coisas, que vai, no final, vai fazer com que o processo todo garanta rapidez, qualidade que eu estou atendendo os requisitos, no nosso caso as responsabilidades, está certo? E ao mesmo tempo, facilitando a vida dos futuros desenvolvedores. Dois grandes problemas que a gente normalmente vai acumulando enquanto está desenvolvendo software, com TDD ou não, não importa a técnica, é a duplicação de código, está certo, que nós vamos ver mais para frente algumas técnicas de como refatorar para eliminar essa duplicação. Mas, uma coisa muito importante é a legibilidade do código. Vocês vejam aí que eu tenho exemplinho de código limpo, né, está certo, que está dizendo, se for legível, seja feliz, caso contrário, refatore, está certo? Por que isso? Porque eu vou querer expressar a intenção minha está certo, todas as partes do meu software. Nas variáveis de instância eu quero escolher nomes que reflitam o significado daquela variável de instância, vez de usar uma variável I, X, Y, eu vou usar nome mais apropriado para a função daquela, pode ser quantidade por exemplo, valor, quer dizer, eu vou dar nomes que são expressivos e que constituam uma intenção relativa aquele software que eu estou produzindo. Vai valer também para as variáveis temporárias tá, que eu vou dar nomes apropriados às variáveis temporárias também, para que o código continue sendo legível. Eu vou dar bons nomes para os métodos, tanto para os métodos do código de produção, quanto para o código de teste. Nós já mostramos algum exemplo no código de teste que eu estou também interessado, mesmo no código de teste, de ter código de qualidade, está certo? Nomes expressivos. Os nomes das classes e os nomes das interfaces quer dizer, eu quero ter expressado essa intenção de uma maneira que torne o código melhor. Para isso, vamos fazer pequeno teste agora. Eu vou querer que vocês leiam esses 2 códigos, parem o video nesse ponto e digam para mim, qual desses 2 trechos que são, o trecho vermelho ele apresenta algum problema de qualidade e o de baixo supostamente já é uma refatoração. Mas a pergunta aqui é, qual que é o mais legível, tá certo? O rosa, cima ou o verde, embaixo? Pare o video e me responda. [SEM_ÁUDIO] Na minha opinião e na opinião da maioria dos desenvolvedores de software, esse que está verde baixo, está certo, é mais legível do que o que está cima, está certo. Porque é que ele é mais legível? Porque ele expressa a intenção, a intenção do que eu estou querendo fazer fica expressa lá, está certo? Então se vocês lerem ai, se é verão, naquela data, então o custo é igual ao custo verão na quantidade. Caso contrário, o custo é igual ao custo inverno na quantidade, ou seja eu estou me expressando de uma maneira muito próxima do que eu estava querendo realmente expressar, para que as pessoas entendam isso com muita facilidade. Então isso é para vocês verem que é importante, vai ser primordial, eu tinha até apresentado que o expressar intenção era uma das principais técnicas que nós usaríamos na produção de software. E ela vale tanto quando a gente produz TDD ou quando não produz TDD, tanto faz isso. Com isso, nós mostramos para vocês porque refatorar, quer dizer, porque é que a gente vai refatorar? Porque no TDD, nós nos preocupamos com o atender as responsabilidades, atender os requisitos, vai funcionar, tem que funcionar de acordo com as responsabilidades e os casos de teste para cada responsabilidade. Então o comportamento eu estou garantindo, mas como esse software vai ser usado por outros desenvolvedores e por mim mesmo, daqui uma semana a gente já não lembra mais o que fez no código, está certo? Nós na refatoração, vamos tornar esse código que não necessariamente foi produzido com a intenção de ser código de qualidade, embora ele vai com o tempo, você vai embutir muitas características de qualidade nele, mas aí é por isso que existe a refatoração, é onde eu vou garantir qualidade ao software, eu vou obter software de qualidade. Obrigado. [MÚSICA]
