[MÚSICA] Olá a todos, meu nome é Eduardo Guerra, esse é o curso Princípios de Desenvolvimento Ágil de Software, e hoje, a gente tá falando de modelagem ágil, só que onde entra o TDD e a refatoração nessa estória? Né, a gente tá o curso inteiro aí falando de TDD, refatoração, como fazer o modelo, né, como modelar através dessas técnicas, e como que o diagrama se encaixa junto com essas técnicas aí no processo de desenvolvimento, vamos ver isso nessa aula. Tá? Então essa é a pergunta que a gente vai tentar responder nessa aula, como que esse uso de diagramas se encaixa com o TDD e com a refatoração num projeto ágil. Então a ideia é por exemplo, no momento que você vai começar uma feature, o diagrama ele pode te ajudar tanto na comunicação da ideia, se você tá passando pra uma outra pessoa fazer ou quanto na discussão daquela ideia aquela solução inicial, aquela ideia inicial, então nesse caso o diagrama ele serve como explorar o problema. Então a ideia se você tá usando o pair programming, você vai lá junto com seu par frente ao quadro branco, vai lá, rabisca o diagrama, e discute com ele qual é a melhor abordagem, que classes vocês vão criar, e aí ou pode ser num papelzinho ali do lado do computador, então esse diagrama ele vai servir como uma base, né, pra implementação de vocês. O TDD a gente viu que muitas vezes foca uma classe só, mas qual classe você vai fazer primeiro? Quais classes são necessárias? Então esse diagrama inicial dá esse norte. Obviamente ele não precisa ter tanto detalhe, porque depois você vai usar o TDD pra fazer o design das APIs. Com o diagrama você vai ter aquela visão mais global, mais de como o software está, como que a solução que você tá fazendo se encaixa na arquitetura, se encaixa dentro do software. E aí com o TDD e a refatoração você vai fazer aquele design mais detalhado, por exemplo, quais os métodos que a classe precisa ter, como que vai ser a construção dessa classe, tudo isso daí pode ser definido no TDD e no diagrama você procura ter aquela visão do todo, como que as classes se conectam e etc, até mesmo pra você poder saber quais mocks você vai precisar criar nas suas classes. E aí, é, baseado no diagrama, você pode, por exemplo, começar refatorando o código existente. Muitas vezes a gente precisa refatorar pra abrir espaço pra nova funcionalidade que a gente precisa. Imagina, por exemplo, que você já tem uma classe ali que tem pedaço do que você quer e aí você decide é, por exemplo, que você vai, ao invés de você botar mais hífen, que você vai por exemplo utilizar uma solução baseada composição, pra utilizar ali dentro daquela classe, você pode antes de começar a implementação, fazer a refatoração do código anterior pra dar espaço pra aquela nova funcionalidade que você vai fazer, no caso o seu diagrama incluiria não só as classes novas, mas também essas classes atuais e como elas seria modificadas. Então nesse ponto você já tem uma refatoração inicial, né, quando necessário de alguma parte do código existente, vai que, por exemplo, você percebe que você vai precisar dum pedaço de código que tá num outro método, você quer extrair aquele método prum local onde ele possa ser reutilizado, então tem vários exemplos aí que você faz essa preparação do código existente pra poder fazer a sua implementação, então você já começa por aí utilizando a refatoração. Tá, seguida você vai pegar uma das classes ali do seu diagrama e vai fazer o TDD cima dela pra desenvolver todas as responsabilidades daquela classe dentro daquele contexto e aí você vai definir a API, você vai fazer aquele design mais fino de quais os métodos, quais os parâmetros, que que é necessário, como que vai ser a parte de tratamento de erros e etc, tudo isso aí que a gente viu no curso de TDD. Tá, depois você vai repetindo esse processo pras outras classes, então imagina que a sua solução ali envolva umas três classes, você vai desenvolver uma, outra, outra, usando ali o TDD, aí você decide o que você vai mocar, o que você vai desenvolver junto e etc. Mas raramente uma solução é uma classe só. Então às vezes ir direto pro TDD é complicado e fazer essa modelagenzinha inicial ajuda bastante. E aí pra fechar a implementação, você fez o teste ali de cada classe individual, que que a gente faz, a gente faz ali alguns testes de integração envolvendo todas as classes ali pra ver se a funcionalidade foi implementada corretamente. Depois que a gente já tiver os testes de unidade e os testes de integração a gente parte pra uma nova fase de refatoração que a gente vai dar uma olhada se a solução como todo ficou legal daquela forma. Às vezes a gente fala, nossa essa classe aqui, eu, já aconteceu comigo, por exemplo, de eu ver que uma classe ele tá com quase nenhum código, e aí eu retirar ela da solução. Ou perceber que, por exemplo, uma classe ficou sobrecarregada de funcionalidade, quiser mudar, uma coisa importante é que nesse momento pode ser que a sua refatoração leve pra uma solução ou leve pra uma estrutura completamente diferente daquela que você utilizou lá no seu diagrama, daquela que você pensou inicialmente, isso não tem problema nenhum, tá, você pode mudar, o ideal é que depois de ser feito você revisite e repense se aquilo realmente é a melhor solução termos de estrutura para o seu software naquele momento depois que você já implementou. Tá, e aí você decide, pode ser que aquele diagrama que você fez pra entender melhor o problema não sirva mais aí você pode pegar e jogar ele fora. De repente a sua equipe fala: nossa, isso que você fez é legal, pô isso é importante pras pessoas entenderem e aí decide manter aquele diagrama, muitas vezes até com uma certa mudança, né, pode ser que você tenha mudado, mas que mesmo assim seja interessante. E aí nesse caso você pode, se você achar que agrega valor pra equipe, o diagrama, ou parte dele, virar uma documentação e aí você define todas aquelas coisas que a gente viu na modelagem ágil: qual que seria a frequência, né, ele seria atualizado, o nível de detalhamento e etc... Tá? Então a gente vê que a utilização do diagrama, ela casa bem com o TDD e com a refatoração que são aplicados momentos diferentes pra, com objetivos diferentes. Então a gente vê que, não é vou utilizar diagrama ou o TDD com refatoração. Não. Você pode utilizar as duas coisas e e extrair aí os benefícios de cada dos mundos, aí, utilizar a técnica, ele é realmente boa, por exemplo, o TDD ele é bom pra fazer o design mais focado, ele não é muito adequado pra fazer design grande, pra você ter aquela visão do todo. Pra isso o diagrama é melhor, então vamos utilizar cada. Por outro lado o diagrama, se ficar definindo monte de detalhe ali, também às vezes não é interessante, então pra isso vamos usar o TDD. O diagrama é bom pra pensar antes. Então pode ser que surja alguma questão depois, nesse caso, vamos usar a refatoração. Então utilizando cada técnica aí num mundo onde ela é melhor. Certo? Então com isso espero que tenha ficado claro aí como o TDD e a refatoração se encaixam com a utilização de diagramas e até a próxima aula. [MÚSICA]
