[MÚSICA] [MÚSICA] Olá,

bem vindo ao curso sobre TDD.

Eu sou Clovis Fernandes e hoje iremos dar continuidade ao nosso exemplo que

tem múltiplos maus cheiros e exemplifica o uso do ciclo de refatoração.

Nós iremos tratar dos maus cheiros de 3 a 5 que

a gente havia monstrado anteriormente.

Retomando o código a que nós tínhamos, nós tínhamos chegado,

às variáveis agora demonstram a intenção, não é, tá certo?

Elas são mais apropriadas, os nomes são mais apropriados.

Eliminamos também as expressões booleanas que eram negativas, agora são positivas.

Então a resposta da minha pergunta agora fica muito mais rápida de ser respondida,

mas qualquer pergunta que eu fizer sobre o código, não é,

tá certo, fica mais rápido, porque ele já está mais bem estruturado.

Obviamente ele ainda tem alguns problemas, que nós iremos tratar.

O primeiro dos problemas são os comentários, está certo?

Vocês percebem que os comentários quando eu começo

a colocar nomes apropriados expressões booleanas apropriadas, não é, tá certo?

Os comentários começam a ficar supérfluos, então basta removê-los.

Nesse caso também o que a gente fez, fazendo apenas ciclo, não é, tá certo?

foi tirarmos todos os comentários, mas a gente tem que tomar cuidado porque

às vezes ao tirar código a gente comete algum erro, não é, tá certo.

Mas como o comentário é mais fácil, é tolerável isso e eu só fiz.

Ao fazer ciclo quero dizer que: eu fui tirei todos os comentários do

método calculated discount e aí fiz teste, tá certo?

E parto para pegar o próximo mau cheiro para ser tratado.

Vamos dar uma olhada aí agora,

eu queria que vocês examinassem 10 segundos, está certo?

Respondessem a essas 2 perguntas, tá certo?

Qual é o desconto se cliente já subsidiado, que a gente já costuma fazer,

e se você sentiu falta dos comentários.

Então, 10 segundos pare o vídeo e pense sobre essas perguntas e dê suas respostas.

[SEM_ÁUDIO]] Bom, estou de volta.

O que é que acontecia com os comentários, não é, está certo?

Normalmente, os comentários que são desnecessários,

eles atrapalham o entendimento.

Então, ao ter eliminado eu deixei o rastro da eliminação só

para vocês saberem onde estavam os comentários, não é, está certo?

Eles atrapalhavam pouco o entendimento, quando ele é desnecessário.

Então, ao retirar, experimentos feitos sobre isso,

as pessoas sentem código já com a intenção

já está expressa, tudo, bons nomes,

que o comentário mais atrapalhava do que ajudava, está certo?

Então sem o comentário na verdade, ainda está atrapalhando

pouco porque eu estou com essas marcas escuras aí, está certo?

Mas sem essas marcas escuras ficaria mais,

muito mais rápido responder qualquer uma das perguntas aí.

O quarto mau cheiro, está certo?

É o Código Duplicado.

Como expliquei, normalmente com a experiência você já

vai fazer a retirada desse código duplicado junto com

a refatoração do If Aninhado do jeito que a gente vai mostrar.

Aqui eu estou mostrando só para exemplificar, tanto é que eu estou usando

aí uma técnica de refatoração que eu é que inventei, está certo?

Essa Replace Temp with Return Value é só para mostrar

que eu estou fazendo a substituição do código que

ia me levar a uma saída única, agora vai ter múltiplas saídas.

Todos os lugares que tinham atribuições passo a ter Return,

é isso que quer dizer esse Replace Temp with Return Value, está certo?

E eu obviamente,

ao fazer a substituição dessas atribuições o que é que vai acontecer?

No final, eu vou fazer isso 3 vezes, 4 vezes,

porque eu tenho 4 atribuições, está certo?

E no final sobram apenas a declaração,

a definição da variável, não é, o int Discount e no final

Return Discount que os 2 são códigos inúteis.

O último, inclusive, dá erro de compilação.

O primeiro dá warning que está avisando que você está usando uma variável,

está definindo uma variável e não está usando nenhum lugar, está certo?

Então isso é código inútil, o que a gente chama de Código Morto, né?

Fica comentado, vocês vão ver lá no meu material, que ele termina comentado,

então ele é código comentado morto.

Então, tanto código comentado morto, né, está certo,

e código vivo mas que está lá, existe, mas ele é inútil,

a gente chama de não serve para nada, ele deve ser removido, está certo?

Então a gente nesse caso, vai ter como eu estou mostrando aí para vocês,

nós vamos fazer esses 5 ciclos, não é?

4 para ir tirando cada uma das variáveis e vir

dando return no valor que era atribuído a cada variável, está certo?

E o último para retirar esse Código Morto.

É ciclo porque eu faço isso e testo, faço a segunda vez e testo, faço

a terceira vez e testo e assim por diante, faço a quinta vez e testo, está ceto?

É isso que a gente faz para eliminar.

Então, se vocês perceberem agora o código ficou agora muito mais simples, não é,

está certo?

Não tem mais aquelas variáveis,

a variável temporária recebendo a atribuição, está certo?

Está muito mais limpo, mais claro, não é?

Agora tem menos coisas atrapalhando.

Nesse código, inclusive, fica bem evidente que a ausência de

comentários simplifica e torna uma coisa mais prazerosa até de olhar, está certo?

Então responder a essa pergunta eu não vou nem fazer isso agora nesse momento,

porque está muito rápido, não é, olhou e já sabe qual é a resposta para qualquer

uma das 4 possíveis respostas que eu quisesse fazer.

É muito mais claro agora, está certo?

E o último mau cheiro é o If Aninhado, está certo?

O If Aninhado aí a gente usa várias técnicas, está certo?

Existem usando o polimorfismo, alguns padrões

de projeto e outras coisas que a gente pode fazer.

Nesse exemplo nós vamos estar usando o que a gente chama de

Replace Nested Conditional with Guard Clauses,

ou seja: a condicional aninhada, o If Aninhado, não é, está certo?

Nós vamos substituir por o que se chama de clausula de guarda, está certo?

O que é que é essa clausula de guarda eu vou mostrar olhando o código alí,

está certo?

Então, é como existe existem 3 ifs nela

e uma clausula de guarda simplesmente é você retirar o else, não é, está certo?

Vamos mostrar aqui o código anteriormente.

Quando eu faço if is sênior return 0, eu vou sair se for

verdadeiro, se ele fosse sênior, se não for ele vai cair no if seguinte.

Então, eu não tem essa, o else é desnecessário, está certo?

É isso que a clausula de guarda vai fazer,

ela simplesmente faz sair a condição e eu não preciso mais ter o else,

eu vou fazendo isso 3 vezes, não é, porque eu tenho 3 ifs nela a sair, está certo?

Tenho 3 Ifs nela e o código fica assim, não é, faço 3 vezes o ciclo,

que faço, elimino else e testo, elimino outro else e testo,

elimino o último else e testo e aí fico com esse código que está aí.

Eu estou marcando cores aí só para ressaltar as

4 retornos de valores que constam do programa, não é, está certo?

Se é sênior volta a 0, se já é subsidiado volta a 250,

se é a tempo parcial também devolve 250 e se for

tempo full time, não é, está certo?

Volta a 500.

Quer dizer, o privilegiado aí nesse caso,

nesse exemplo é quem é a tempo integral, está certo?

Eu estou reproduzindo aqui o código aqui antes da gente começar a fazer

todo esse ciclo de refatoração.

Está certo?

Esse ciclo de refatoração foram fizemos 13 passadas no ciclo, está certo?

Fizemos 13 passadas nesse ciclo.

O código inicial era esse, que ficava difícil responder àquela

pergunta ou a qualquer uma das pergunta que eu quisesse fazer.

Se eu quisesse fazer sobre o quanto que seria o desconto pra

quem é tempo total, não é, está certo, que trabalha tempo integral,

seria muito difícil responder também, está certo?

Então, é, o código inicial era muito complicado, mesmo com os comentários.

Sem os comentários, que era o normal dele,

ele foi feito sem comentários, eu coloquei os comentários, não é, está certo?

E voltando aqui, nesse caso aqui,

eu estou pondo comentário que está errado, é errôneo ainda, não é, está certo?

Que complica mais ainda.

Eu errei na hora de colocar, está certo?

No meu caso, eu errei de propósito mas simbolizando

que você pode errar colocando comentário se a pessoa, se for

acreditar no comentário é, pode está se enganando por que esse

código estava fazendo certinho, por que passava no teste,

está certo, mas o comentário estava errado, não é, está certo?

Então se eu fosse querer entender o programa por causa do comentário eu

estaria entendendo errado e o programa fazendo certo, eu ficaria "como é que o

programa está fazendo certo se aqui está diferente?" Está certo?

E olha o código final, não é.

Código mais enxuto, código mais simples, bem estruturado,

os 5 maus cheiros foram eliminados.

É, esses ciclos que eu fiz é número razoável, está certo,

mas ele é feito rapidamente, está certo?

Você com experiência vai fazer isso muito rapidamente, está certo?

É uma coisa bastante interessante que com o tempo, com a experiência você vai

identificando todos esses maus cheiros que eu mostrei hoje,

quando você vê novo código que tiver algo equivalente,

você já vai olhar e falar: nossa que código mais feio,

que código cheio de mau cheiro, vamos melhorar esse código, está certo?

Se fôssemos perguntar para vocês: qual é o código que é mais claro,

mais fácil de entender?

Aquele inicial, está certo?

Aquele inicial ou o atual, esse último que nós colocamos, está certo?

Se eu perguntasse para vocês, fizesse qualquer uma das perguntas, é,

qualquer uma das perguntas relativo ao calculate discount ficaria

mais fácil encontrar as respostas no código atual ou no código antigo?

Não é, está certo?

Obviamente, nós fomos mostrando isso de tal maneira,

que sem dúvida, eu encontro, tenho mais facilidade de dar respostas

e ao dar respostas significa que eu estou, que o código é claro,

o código é limpo, o código é fácil de entender, está certo?

Então é isso que eu quis mostrar para vocês.

Eu parto de código cheio de mau cheiro, sigo o ciclo de refatoração,

vou eliminando esses maus cheiros e eu chego códigos muito mais interessantes.

Vocês percebam que nesse exemplo não foi necessário ter comentário algum.

Eventualmente, alguns programas poderão ter comentários que seriam apropriados.

Geralmente comentários que descrevem o quê ou porquê alguma

coisa deve acontecer, pode ser que algum deles

não sejam eliminados pelas técnicas de refatoração e façam sentido.

Mas, no nosso caso, nenhum deles fazia sentido e eles foram todos retirados,

está certo?

Com isso a gente completou esse exemplo que tinha 5 maus cheiros,

não é, para exemplificar o ciclo de refatoração.

Ou seja, aquilo que eu mostrei pra vocês, que o espetáculo que nós estávamos

mostrando pra vocês do ciclo de refatoração é muito interessante,

por que ele nos ajuda sendo guiados pelos maus cheiros, está certo?

É, que estão relacionados a tipos específicos de técnicas de refatoração,

isso me ajuda e simplifica muito a minha tarefa de ter no final

código mais limpo, mais fácil de compreender e, obviamente,

mais fácil de estender e até integrar com outros programas.

Obrigado.

[MÚSICA]

Ciclo de Refatoração: Exemplo com Múltiplos Maus Cheiros – Parte 3: Até Quinto Mau Cheiro

TDD – Desenvolvimento de Software Guiado por Testes

Meet the Instructors