[MÚSICA] [MÚSICA] Olá. Bem-vindo ao curso TDD- Desenvolvimento de Software Guiado por Testes. Eu sou Clovis Fernandes. Hoje, nós vamos falar de conjunto de siglas que aparece aí. Bom. Vou aproveitar para dizer que eu demorei para aprender a diferença entre sigla e acrônimo. Então, vocês vejam que aí eu tenho, por exemplo, ITA. ITA, é acrônimo para Instituto Tecnológico de Aeronáutica. Já, por exemplo, a palavra IBM é uma sigla para International Business Machine. O que diferencia, então, sigla de acrônimo? O acrônimo, eu posso ler como se fosse uma palavra. ITA é acrônimo. IBM, como eu soletro cada letra é uma sigla. Nós temos aí, a sigla TDD. Então, TDD é uma sigla porque eu leio letra por letra. Então TDD é o Text Driven Development ou Designer, que corresponde a desenvolvimento, português, não é? Desenvolvimento de Software Guiado por Testes. Ao final dessa aula, você saberá que não é preciso fazer projecto antecipado e completo do curso para você fazer o TDD. Então, essas siglas que estão aí se referem mais ou menos a isso. Então, quando eu falo o BDUF vou misturar com acrônimo. Vou ler como se fosse sigla e acrônimo, BDUF Big Design Up Front, que é o projecto grande antecipadamente. Então, eu estou querendo dizer para vocês que eu, para fazer TDD eu não preciso fazer isso antes de implementar e também não vou fazer a outra sigla que é o NoDUF. No, D, U, F. Eu não vou usar essa que é Nenhum, Design algum antecipadamente. No Design Up Front. Nem, não vou fazer nada disso também. Então, na aula de hoje o que eu quero ver é eu preciso fazer projecto antecipado e completo antes para fazer o TDD? Vamos tentar responder e mostrar que não e nem o seu oposto que é não fazer nada que muitas pessoas da comunidade do TDD, acham que isso é certo, nós discordamos pouco. Então, o que é que vem a ser o BDUF? Big Design Up Front. Projeto Grande feito antecipadamente. Está certo? Nós vamos tentar mostrar que no TDD, isso não vai ser necessário. O BDUF corresponde, então, a projecto da sua aplicação que seria feito e completado e aperfeiçoado antes da implementação começar. Isso, normalmente, é feito outros projetos. O processo cascata exemplifica bem o BDUF. Uau! aqui! linda cascata que estamos vendo aí! Mas não é dessa cascata que eu estou falando, mas o nome foi derivado por causa disso. O que eu estou falando é desse processo de desenvolvimento de software, que eu tenho lá cima os requisitos, uma análise de requisitos, o projeto, a implementação, a verificação e testes, o software é colocado produção e entra manutenção. O BDUF, esse Big Design Up Front, ele corresponde à análise de requisitos e ao design, exatamente antes da implementação. Se o BDUF não é uma boa alternativa para o TDD, porque eu não quero, nesse processo de cascata, eu perco muito tempo fazendo a especificação de coisas que podem ser ou inúteis ou que vão mudar no futuro. Eu levo muito tempo fazendo isso. Depois, faço o projeto de tudo e aí começo a implementar e só depois vou testar. TDD a gente não faz isso, né, o nosso processo é testar antes, fazer falhar, fazer o código funcionar, refatorar. É esse ciclo que nós vamos seguir. Então, se o BDUF não é uma boa alternativa, qual é que é a alternativa boa para isso? Obviamente, na comunidade TDD, existem muitos que praticam e acham que o oposto disso do BDUF, que é fazer tudo antes da implementação, o oposto, que é não fazer muita coisa antes da implementação, está certo? Seria o ideal. Eu vou mostrar aqui, com alguns exemplos não computacionais que isso talvez não seja uma coisa boa. Eu vou estar chamando isso de NoDUF, No Design Up Front, português, design algum antecipadamente, ou seja, não vou fazer nenhum design, está certo? Antecipadamente. Será que essa é uma boa alternativa? Bom, quero lembrar que essa sigla NoDUF, não é usualmente empregada na literatura ou na indústria de software. Eu estou usando aqui é, exatamente, só para pontuar a conceituação sobre o que estou querendo dizer, que é, não fazer quase nenhum projeto antecipado. Então, eu estou chamando de NoDUF, No Design Up Front. Projeto Algum Antecipadamente. Eu não vou fazer nada antecipadamente ou muito pouco. Está certo? Isso é o que a comunidade TDD, muitos pensam e fazem uso disso. Eu discordo e vou mostrar alguns exemplos, não computacionais que vão exemplificar isso. Suponha que, na imagem a seguir, eu queira fazer uma corrida campestre de motos e aí eu tenho duas perguntas que eu gostaria de fazer para, você olha a imagem, está certo? E vai responder: seria bom local? Eu tenho informações suficientes para começar essa corrida? Está certo? Então, esse é trechinho de uma imagem, eu estou mostrando onde eu vejo, que tem grana, que tem uma trilha no meio. Está certo? Então, olhando isso o que é que você pode imaginar? Aparentemente sim, eu posso fazer uma corrida de motos aí, mas, veja eu não tenho informações suficientes, eu tenho poucas informações, eu estou olhando de uma maneira muito restrita esse meu local, está certo? Agora, vamos ampliar esse local. Uau! Uma bela vista também. Mas, as duas perguntas, não é? Será que é bom local? E tenho informações suficientes? Agora, eu tenho mais informações e certamente, esse não é bom local para fazer uma corrida de motos, uma corrida campestre de motos, porque o lugar é muito perigoso, está à beira de precipícios. Então, bastou eu ampliar pouquinho, olhar pouquinho à frente, ter pouquinho mais de informação, eu já pude tomar uma decisão. O NoDUF corresponde a você estar olhando de maneira limitada e não ver à frente alguma coisa. Então, não é uma boa coisa. A gente viu que não é uma boa coisa ter, querer fazer, ter todas as informações antes, não é? No Big Design Up Front. Mas, também no NoDUF, não ter nenhuma informação, ou ter muito pouca informação, também não é uma coisa boa. Imagina agora que eu queira fazer uma pesquisa de campo sobre biodiversidade. num determinado local. Vamos responder novamente às mesmas perguntas. Seria bom local? Eu tenho informações suficientes para começar? Então, esse é o trecho do que eu quero fazer. Está certo? Fazer essa análise de campo, essa exploração de campo, de biodiversidade, está certo? Olhando para isso, aparentemente sim, seria bom local, tenho muita vegetação, certamente eu vou ter muitos animais e outras informações ali. Só que também eu não tenho muitas informações suficientes. No caso agora, vou olhar, ampliar, eu estou olhando de uma maneira muito limitada, não é? Está certo? Agora, vamos ampliar isso pouquinho? Pronto. Uau! Uma bela cena também. Está certo? Vocês vejam que agora, eu tenho mais informações. Está certo? Eu tenho mais informações agora. Quer dizer, bastou olhar pouquinho além e eu já consigo vislumbrar outras necessidades para essa minha pesquisa aí, está certo? Eu tenho montanhas, eu tenho vale extenso. Então, talvez eu precise que algum dos biólogos façam escaladas, façam rappel. e gostaria de saber também algumas outras informações adicionais, como chuva, clima da região etcetera e tal. A resposta nesse caso, certamente sim, porque ao olhar pouquinho mais eu consigo vislumbrar mais sobre a pesquisa de campo e a resposta é certamente sim, é bom local para isso. E eu agora tenho a informação suficiente para uma tomada de decisão, preliminar, pelo menos. Está certo? Então, a chave aqui é isso: conjunto de informações suficiente, quer dizer, agora eu tenho mais informações. Ou seja, eu não preciso ter todas as informações, por exemplo, dessa última pesquisa de campo, informações topográficas e coisas adicionais sobre isso, eu não preciso ter conjunto de informações completas. Mas eu preciso ter conjunto de informações suficientes, para eu poder iniciar a minha pesquisa de campo. Então, a chave não é ter muita informação antes de começar a implementar e nem quase nenhuma informação antes de começar a implementar. É ter o conjunto de informações suficiente. Como nós vamos chegar a definir o que é informação suficiente, isso vai ser outra coisa. Nessa nossa aula, eu espero que você tenha então entendido que o desenvolvimento de software usando a abordagem BDUF, ou seja, Big Design Up Front, não é uma coisa boa, nem o seu oposto, quase nenhuma informação. No BDUF, você demora a começar a implementar e o seu sistema já vai ficar muito rígido, porque eu tomo muitas decisões antecipadamente e se precisar mudar alguma coisa, eu vou ter dificuldade, exatamente por causa dessa rigidez. No caso do NoDuf ou seja, eu não tenho design nenhum, né, está certo? Nem de requisitos, nem do design propriamente dito, está certo? O que é que acontece? Às vezes, eu não tenho todos os requisitos, eu não tenho informações, eu não consegui olhar para a frente sobre alguns percalços que eu possa ter no meu desenvolvimento. E ao fazer isso, talvez eu tenha problemas no futuro, porque eu posso seguir, o projeto vai sendo seguido para desenvolvimento que pode me levar a problemas. Está certo? Ele talvez não esteja muito pronto também para mudanças inesperadas. Eu vou contar caso aqui para vocês, pessoal, hoje ele é grande cientista, começou a fazer uma tese de mestrado comigo, torno de 2003, 2004, que era sobre repositório inteligente para gerenciar o perl programming, né, na modelagem ágil, que ele começou a programar esse repositório inteligente usando o TDD, TDD individual, né, está certo? Chegou dado momento, e ele estava usando essa técnica, que eu vou colocando os meus requisitos, e eu imagino que vai emergir uma arquitetura, projeto do meu sistema que seja saudável. Quando ele veio me apresentar esse projeto, o projeto tinha muitas falhas, ele não conseguia me responder muitas coisas, ele não era muito inteligente, o que é que faltou? Faltou ele ter uma visão pouquinho mais antecipada disso, ele teria que ter olhado a literatura sobre outros repositórios inteligentes para fazer análises parecidas, e ao não ter olhado isso, ele fez uma arquitetura que acabou sendo inadequada para suportar os novos requisitos. Ou seja, mesmo você querendo não, não seguindo plenamente o TDD, olhando o suficiente para a frente, você pode ter problemas. A conclusão a que nós devemos chegar, é que o certo é fazer projeto suficiente antecipadamente, nem muito, nem pouco. O suficiente, e fazer o suficiente não é uma coisa também que a gente tem certeza do que vai ser feito. Nós sempre vamos ficar dúvida, mas esse é o assunto da próxima aula. Espero então que tenha ficado claro que você não vai precisar fazer projeto usando o BDUF ou NoDuf. Obrigado!
