[quote=LPJava][quote=fabioEM][quote=LPJava]opa! pessoal,
obrigado pelo comentários e feedback. uhauhhua gostei da associação com Paulo Coelho, porém a diferença é que o Paulo é escritor, nasceu para escrever livros. Já eu, escrevo por hobby, esse ai tá na gaveta desde de 2010 e só em fev para inicio de março que conseguir fechar o último capítulo.
mausexdd: posso conseguir 30% de desconto :). Ainda não temos o valor, pois quem faz esse é a editora. Como sempre vou brigar por um preço acessível.
tnaires: esse é o objetivo, o livro é puramente “seco” em termo de Java, longe dos frameworks que vc citou. A idéia é praticar TDD e exercitar o ciclo e buscar resolver problemas. Dividir o livro em duas partes: Na primeira eu até ajudo os primeiros passos, mas na parte 2, ele vai se virando.
eu aprendi bastante durante esses 2 anos escrevendo, achei que pelo fato de usar no dia-dia seria moleza escrever o livro, mas não foi. Pois, escrever sobre refactoring, TDD etc. Esses assuntos que são abstratos e não tem receita de bolo, não é fácil. Tentar deixar claro para o leitor que nunca é a mesma solução para tudo, que saber dar os passos certos e como dar, é um tremendo desafio. E o melhor, não fazer o cara se sentir um TDD expert só pq leu o meu livro, ou do Kent Beck, que ai é apenas a porta de entrada e uma motivação para quem tá no 0x0.
valeu pessoal,pelo apoio. Assim q for lançado e receber os exemplares, vou sortear um :).[/quote]
Parabéns! Muito Show!
Porém conheço desenvolvedores que sofreram,sofrem e sofrerão bastantes com essa abordagem. Quando trabalhava na BRQ lembro que a especificação chegava sempre com prazo muito curto e bem simplista, na real, o desenvolvimento era realizado por etapas e conversando de forma continua com clientes e analistas. Por vez isso acarretava muitas mudanças e até um vamos tudo de novo!! Portanto, em 99% dos casos, usando essa metodologia, será mais oneroso. Acredito que o TDD é uma boa pratica quando se tens prazos mais confortáveis e boa visão dos requisitos que na prática tá difícil. Porém é uma opinião de quem realmente nunca trabalhou com TDD mas já vi. Logo posso estar errado, ou quem reclamava o fazia porque não sabia bem como funcionava a metodologia.[/quote]
opa! Fábio legal sua opinião. Eu passei por algo parecido. Na verdade o que coloquei no livro nada mais é o que aprendi nos ultimos dois anos com TDD. O ultimo projeto, tinhamos prazos curtos e uma demanda alta e poucos devs, trabalhei sabado, domigo, feriado, dia santo. Bem no inicio deu a ideia que TDD estava sendo oneroso, mas eu achei que tinha algo de errado. E falava: “nao pode ser oneroso, n faz sentindo”. Fui estudar mais, li o livro do Kent Beck umas 3x, motivo? Na minha opinião há muita coisa naquele livro que o Beck não é direto e que só percebemos quando temos um problema e conseguimos entender o que ele quer dizer. Li outros livros, e fui buscando entender meu ambiente com TDD.Dai percebi que no inicio eu:
- não tinha o entendimento da técnica de TDD;
- que não era só criar unit test primeiro, TDD está envolvido com o Design tb e diretamente. Não se separa os dois. Na verdade o design da solução vinha do TDD;
- não sabia onde focar e gastava tempo demais com detalhes que não era importante, para meu ego como desenvolvedor era ideal eu ter mais tempo para poder testar, rodar todo ciclo TDD, mas para o ego do meu PM isso é custo;
- eu teria que ser persistente e não desistir;
No inicio fui criticado por outros desenvolvedores do projeto. Dizendo: “Isso é coisa do mundo do Kent Beck e Martin Fowler, só funciona na empresa dele”. fora as piadas. Porém, não respondi as críticas, mas eu pensei comigo: “vou provar que não é”. Moral da história, sofrir bastante no inicio, mas nas entregas eu me sair muito bem. Cada task/item/card que era entregue não tinha bugs de desenvolvimento, quando tinha era falha no analista de requisito, que passou a informação errada e dai tinha que mudar, mas isso ficava claro. Não estou dizendo que TDD não é produzir código sem bugs(ou a bala de prata), não tem relação, na minha opinião. E sim tudo é consequência. Agora os outros colegas que criticaram:
- nao conseguiam entregar dentro do prazo que estimou;
- e o velho ditado: “o código tá feito, só falta testar”;
- unit test com baixa qualidade(isso quando eles conseguiam fazer);
- a quantidade de bugs que abriam para task/item era grande;
Com TDD eu aprendi:
- ser mais ágil no desenvolvimento;
- fazer entregar mais rápidas;
- melhorar minhas estimativas;
- buscar ter um código de qualidade;
juntar tudo isso no dia-a-dia com qualidade e baixo número de erros, confesso que não é fácil. Nos próximos 1-2 meses fui convidado para um novo projeto, que tem interesse em usar TDD e outras práticas de desenvolvimento com o objetivo de melhorar a qualidade interna deles. Já estou até ansioso para descobrir o que vou aprender com TDD dessa vez. :)[/quote]
Parabens mesmo pela iniciativa, e por esta resposta tambem.
Sempre quando me perguntam sobre bibliografia sobre TDD, eu indico o do Kent Beck ou o do Koskela, mas muitos esbarram no idioma. Nao ha muita coisa em portugues sobre o tema. Eh muito saber que tem alguem se dedicando a isto.
Sobre o ciclo de desenvolvimento com TDD, o que na verdade acontece, diferente do que muitos pensam, eh que ele acelera o ritmo de desenvolvimento e nao diminui. Nao so diminuindo as correcoes que voce tem que fazer, mas principalmente diminui o tempo que voce precisa pra testar o que voce fez. Normalmente ao alterar uma linha de codigo, voce tem que iniciar o servidor, passar por tela de login, percorrer o menu, entrar com os dados na tela e verificar se a sua alteracao funcionou corretamente. Se nao funcionou, voce volta, altera mais uma linha e repete o processo.
Nesse ponto TDD de oferece um ganho enorme, porque voce nao precisa de nada disso. Voce simplesmente roda o teste, o que dura milissegundos. Claro que voce tambem vai precisar rodar a aplicacao real, mas muito menos e somente quando tudo estiver pronto.
Parabens, Camilo. Espero realmente que seu livro venda muito porque quanto mais gente propagando esta tecnica melhor sera o nosso trabalho e mais facil, nao tenho duvidas.