[MÚSICA] [MÚSICA] Olá, bem vindo ao curso sobre TDD, eu sou Clóvis Fernandes e hoje iremos falar de uma coisa muito, não sei se vocês vão gostar, eu vou falar do papel do mau cheiro, está certo? Aí, na verdade o que nós estamos falando aqui é sobre o que refatorar, quer dizer, como é que eu descubro o que eu devo refatorar? A ideia é simples, siga o mau cheiro e descubra o que precisa ser refatorado. Quer dizer esse mau cheiro vai ser alguma coisa que se encontra errado ou mal projetado no seu programa, está certo, que você vai identificar e vai associar algumas técnicas de refatoração. Então como fazemos para refatorar? Bom, primeiro nós vamos estar na fase, no ciclo de TDD, na fase de refatoração, está certo, e iremos seguir uma abordagem de analisar o nosso código, está certo, cuidadosamente para ver o que é que pode ser feito. Então nós examinamos o código busca de alguma coisa, o que é que é essa coisa que nós estamos busca? São indícios, sintomas na nossa área aqui, nós vamos chamar de mau cheiro, bad smell inglês ou simplesmente smell está certo? Ou seja isso é o que nós vamos estar procurando no código. E o que vai consistir isso? São coisas que suspeitamos que não estão muito bem no código, por exemplo quando eu deixo uma variável de instância pública, ou deixo uma variável de instância mesmo que seja privada, exposta através de getters e setters públicos. Isso é sintoma de que alguma coisa pode estar errada. O programa vai estar funcionando, está certo, mas é que eu dou margem a que pessoas cometam erros subtis, difíceis de serem descobertos e assim por diante. Bad smell também, mau cheiro, ele pode ser uma coisa complicada, que se a gente não tomar cuidado com ele, pode nos dar trabalho, dor de cabeça, preocupação se não corrigirmos, ou eliminarmos esse bad smell, está certo? Então se eu estou deixando dado exposto ou se eu estou deixando como a gente viu lá na Law of Demeter, que eu deixo exposto através de getter que me devolve objeto e dali eu posso obter outro objeto e aí eu começo a trabalhar e criar muitas dependências, acoplamentos complicados está certo? Então se eu não cuidar disso, eu vou algum momento ficar tomado como se fosse monte de lixo, monte de sujeira que vai atravancar o meu desenvolvimento. Normalmente a gente vai olhar então, isso como sintoma de que algo está podre no meu reino da Dinamarca, então o meu código é o meu reino da Dinamarca está certo? Bad smell vai ser sintoma de que algo está podre no meu reino está certo, e eu não vou deixar, não devo deixar isso acontecer, está certo? Já o Fowler no seu livro, que eu já citei, de 2009, que é o tradicional livro dele de refatoração, mas que foi feito uma edição para a linguagem Ruby, está certo? Mas isso que ele fala serve sempre para qualquer linguagem, eu estou falando de conceitos que são genéricos não é? Então ele fala que são pedaços de código que estão errados algum sentido não é, está certo, como eu falei naquele exemplo da variável de instância ou público ou exposta através de getters e setters, não é, públicos, está certo? Agora ele acrescenta uma coisa que é bastante interessante e que são feios de ver, não é, está certo? Isso que está escrito aí é ele dizendo isso, depois que você se acostuma com isso, você vai ver que realmente o código fica feio de ver. Você depois que eliminou, você fala "Nossa o código ficou com uma beleza", você vai ser capaz, enquanto você está vendo aquela sujeira, que são esses smells, não é, bad smells e que você não faz nada, você não dá muita importância a que eles são realmente feios, mas depois que você começa a eliminar, reestruturar seu programa, refatorar, está certo? E eliminar esses bad smells, vocês vão ver que o código que tem mau cheiro, ele é feio, é isso mesmo, ele é feio. Você vai acabar olhando e já percebe, já sente incomodo com isso. Exemplo é quando você tem muito código duplicado, está certo? Sendo que existiriam maneiras mais simples de eliminar essa duplicação e você não faz, os códigos ficam grandes, feios, redundantes, toda a vez que dá algum problema que você tem que mudar alguma coisa, você tem que mudar montes de lugar, porque você vai duplicando as coisas, está certo? Então isso acaba ficando feio mesmo não é, está certo? Então isso, o que o Fowler está falando aí é uma coisa que realmente acaba sendo verdadeira, vocês vão olhar ver o sintoma e já vai falar "Nossa que código feio". Uma coisa importante que o Fowler fez, eu acho que isso é fundamental e chamar a atenção disso, é que ele caracterizou conjunto, junto com uns colegas deles no primeiro livro, está certo? Ele caracterizou dando nomes aos tipos de mau cheiro você entendeu? Porque isso fica didaticamente até fácil para você identificar " esse tipo é o nome inadequado" como está aí na transparência, é código duplicado, está certo? Você conversa com outras pessoas e fala " isso é apenas problema de código", então a comunicação fica mais fácil e também tem o outro lado: cada desses mau cheiro depois vão estar associados a uma ou mais técnicas de refatoração para eliminar esse mau cheiro, então eu consigo relacionar essas coisas. Então esse, essa coisa de dar nomes foi uma coisa muito importante, está certo, e os nomes são normalmente bem interessantes. Então o nome inadequado, está certo, é aquilo que a gente falou, precisamos expressar a intenção. Para mim existe ranks aí mostrando os 10 tipos mais comuns de mau cheiro, não é, normalmente esses 8 que eu vou citar, esses 4 agora e os 4 daqui a pouco, estão esses 10 está certo, normalmente, mas eu considero o nome inadequado, aquilo que você não está expressando a sua intenção, dos piores, horrorosa, porque ele deixa o código muito ilegível, muito difícil de compreender e de fazer modificações, está certo? O código duplicado é aquilo que a gente já falou, você tem códigos que se repetem vários lugares, está certo, às vezes são só variáveis que estão duas subclasses de uma classe que você simplesmente vai fazer, está havendo uma redundância, ela pode então subir e ir para a sua super classe não é, está certo, e aí você pode fazer tratamento das variáveis usando getter e setter só para subclasses, não é, está certo, não precisa nem expôr também isso, só para subclasses. Então isso, essa questão do código duplicado tem variadas fórmulas, vamos ver algumas delas, está certo, e como isso pode ser resolvido. Outro grande problema é o método grande, o que é que é método grande? Método grande, se você estiver com código estruturado ele pode ser bem grande, mais de 10 linhas por exemplo, mas se o seu código é totalmente desestruturado, nem 5 linhas você vai conseguir entender, está certo? Então usa-se critério que os métodos devem ser sempre pequenos, o mais pequenos possíveis, está certo, com menos de 10 linhas desde que o código seja todo totalmente estruturado, está certo? Agora outro grande problema, é a classe grande, ela é chamada carinhosamente de classe God, porque ela vai juntar tudo numa classe. Vez de eu como desenvolvedor distribuir isso, essa inteligência do meu sistema várias classes pequenas, não é, está certo, então uma classe é grande, quando ela tem muitas variáveis, quando ela tem muitos métodos, não é, está certo, geral uma classe boa para nós no, na refatoração é uma classe com poucas variáveis de instância, com poucos métodos, não é, está certo? E uma classe God o que é que ela faz? Ela não, você não distribui a inteligência do seu sistema nas várias classes, você deixa tudo numa classe só, está certo? Eu lembro que uma vez professor meu fez uma tese de Mestrado que era para fazer uma classe, para fazer uma planilha, quando o Excel foi lançado, não é, isso à muito tempo atrás Quando o Excel foi lançado, ele fez uma classe que fazia toda a planilha com uma classe, e ele ficava, ficou orgulhoso de ter sido feito isso, não é? Nós achamos na terra, porque não existia esses critérios de boa qualidade nós achamos bastante estranho isso, porque nós costumamos fazer programas com várias classes distribuindo inteligência que, já naquela época, a gente já trabalhava com responsabilidade e responsabilidade nos induz a isso, principalmente porque você inclui o tell don't ask, está certo? E aí você vai distribuindo a inteligência, está certo? Classe God, nunca usar por favor. A outra coisa que também pega bastante são comandos de if e switch. Há comandos condicionais, de maneira geral, não é? Está certo? Vocês vão ver que há abuso. Nós usamos de forma muito inadequada, está certo? Às vezes, você resolve isso através de polimorfismos, às vezes de algum padrão de projecto, às vezes uma maneira de subclasse de polimorfismo, e às vezes uma maneira bem mais simples, está certo? Coisas bem simples. É uma coisa que nós vamos mostrar alguns exemplos também. Outra é Inveja de Característica. Que é que é isso de Inveja de Característica? É aquilo que a gente usava no tell don't ask. Você está se referindo a alguma coisa que está exposta, vez de você pedir para essa classe fazer alguma coisa para você, você vai lá, pega essa coisa, está vendo, trás para você, faz aqui, sendo que você não precisava estar fazendo aqui, está certo? Então, essa Característica que está ocorrendo aqui, mas ela deveria ser método que deveria estar lá, não aqui, está certo? Então nós vamos mostrar exemplo também sobre isso. A outra é a Intimidade Imprópria. A Intimidade Imprópria, algum momento, ela vai se tornar uma classe God, se você deixar. Mas a Intimidade Imprópria é: vez de eu distribuir, como na própria classe God, a inteligência do meu sistema por outras classes eu pego, trago essas, essas informações e métodos que estariam dentro dessa outra classe e dentro da minha, está certo, mas numa escala menor do que com a classe God. A outra coisa que, na modelagem age nós, não que proibimos, mas a restrição é muito forte, é sobre comentários, está certo? Os comentários, eles devem ser bastante limitados a descrever o quê e porquê alguma coisa está ocorrendo e ainda assim muitas dessas explicações vão ficar, vão ficar resolvidas quando eu, eu faço uma, uma expresso a minha intenção de uma maneira muito boa nos nomes de, de variáveis, métodos, e assim por diante. De qualquer maneira, os comentários, eles são sintomas muito fortes do, de algum desses problemas anteriores que eu acabei de mostrar aí, está certo? Esses 8 problemas que, esses 4 anteriores e esses 4 aí, está certo? Os comentários acabam servindo de sintoma, indício de alguma coisa, está certo? E pode até ser usado, o comentário acaba, pode acabar sendo o nome de método que eu vou acabar fazendo e assim por diante, ou seja, não se perde o que, que, o que estava lá quando se usou comentário. Eu vou mostrar aqui agora para vocês o ciclo, desde o momento que eu, vocês estão vendo ali? Tem cachorro farejando. Sintoma, não é? Está certo? Mau cheiro, bad smell, está certo? Eu começo a farejar isso e usando a facilidade que o Fowler nos deu, eu consigo então encaixar numa das categorias dos tipos de, bad smell, está certo? De mau cheiro, isso ajuda muito a entender porque, dado tipo do bad smell, eu posso relacionar com os tipos, eu posso relacionar com, com as técnicas para resolver esse problema do mau cheiro. Então, eu tenho lá sintoma, está certo? Eu consigo dar nome para ele e associar a ou mais, a ou mais técnicas de refaturação. Eu vou olhar com cuidado o meu código naquele momento e escolher a que seja mais apropriada para aquele dado momento. Isso pode ser, uma que seja, por restrição de tempo, eu vou usar uma que seja mais rápida de resolver. Não resolve totalmente, está certo? O problema do mau cheiro e, assim por diante. Vai ser uma questão que eu vou, vou decidir na hora. Com isso, então, mostramos o papel do mau cheiro, não é? Ele responde o que é que eu vou refaturar. Quer dizer, eu vou refaturar aquilo que for apresentado pelo mau cheiro que eu encontrar. Está certo? O fato de eu ter catalogados tipos de mau cheiro, isso me ajuda didaticamente até na hora de conversar com outras pessoas sobre o tipo do mau cheiro. Eu vou falar: eu estou com código duplicado, eu estou com uma intimidade inapropriada aqui, está certo? As pessoas vão entender por causa disso e, com isso, eu consigo então, associar algumas técnicas de refaturação àquele tipo de mau cheiro. Obrigado.
