Pré-Lançamento: Livro TDD na Prática

ainda não foi definido o valor do livro. O preço é formado apenas quando o livro vai para gráfica, algo que deve acontecer até o final do mês de maio. [/quote]

[size=24]; -)[/size] , comprei o livro da Caelum é não gostei, espero que esse faça melhor sucesso …[/quote]

Bom agora é esperar ate junho pra saber o valor.

Qual o livro da Caelum vc comprou e não gostou?

olá Jonas,

o livro da Caelum tem um objetivo X. O meu tem um objetivo Y. Então são completamente diferentes, não há relação entre eles.
O meu é focado mesmo, em quem nunca fez TDD na vida e quer pelo menos sair do 0x0 de forma prática. É tanto que a parte de teoria no livro, limitei ao que todo desenvolvedor deve saber no minimo. Se o cara que se aprofundar mais em teoria, entender bem detalhado, ai tem que ver outras referência no mercado que é focado nesse ponto. Eu fiz isso, pq não sou fã de teoria, gosto de ter uma boa base teórica, mas não ficar mergulhado nela. Senão eu fico louco :). Necessito praticar e ver a coisa funcionando e alinhar com o que eu li.

[quote=LPJava]olá Jonas,

o livro da Caelum tem um objetivo X. O meu tem um objetivo Y. Então são completamente diferentes, não há relação entre eles.
O meu é focado mesmo, em quem nunca fez TDD na vida e quer pelo menos sair do 0x0 de forma prática. É tanto que a parte de teoria no livro, limitei ao que todo desenvolvedor deve saber no minimo. Se o cara que se aprofundar mais em teoria, entender bem detalhado, ai tem que ver outras referência no mercado que é focado nesse ponto. Eu fiz isso, pq não sou fã de teoria, gosto de ter uma boa base teórica, mas não ficar mergulhado nela. Senão eu fico louco :). Necessito praticar e ver a coisa funcionando e alinhar com o que eu li. [/quote]

Bom, acho que você me entendeu então, digo isso porque Livro Arquitetura e Design de Software é um resumo sintético e nada praticável sobre o que tenta demonstrar, bom talvez porque o curso F-J91 seja o carro chefe obrigatório do assunto, mas pra quem compra o livro quer se encontrar e não se perder, é a minha opinião.

ainda não foi definido o valor do livro. O preço é formado apenas quando o livro vai para gráfica, algo que deve acontecer até o final do mês de maio. [/quote]

[size=24]; -)[/size] , comprei o livro da Caelum é não gostei, espero que esse faça melhor sucesso …[/quote]

Bom agora é esperar ate junho pra saber o valor.

Qual o livro da Caelum vc comprou e não gostou?[/quote]

Livro Arquitetura e Design de Software

[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. :slight_smile:

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.

Parabéns, quando sair eu vou comprar. :smiley:

[quote=Leozin]Camilo é o nosso Paulo Coelho do GUJ!

Parabéns pelo livro!

Abração![/quote]

Hm, como nem o Paulo Coelho é unanimidade, vou destoar um pouco, com todo o respeito ao autor que é nosso colega de fórum. Adoro TDD e gostaria muito de comprar o livro, mas quando estava estudando pra certificação OCJP comprei o livro do Camilo e achei o livro muito ruim, mal escrito, mal revisado, e muito fraco tecnicamente. Novamente, com todo o respeito ao autor, sobre o qual não tenho nada a comentar, mas essa foi a minha opinião sobre a obra.

Como TDD é um assunto que me interessa bastante, o livro até me interessa, mas dado esse histórico…no blog será disponibilizado um “preview”?

[quote=alias][quote=Leozin]Camilo é o nosso Paulo Coelho do GUJ!

Parabéns pelo livro!

Abração![/quote]

Hm, como nem o Paulo Coelho é unanimidade, vou destoar um pouco, com todo o respeito ao autor que é nosso colega de fórum. Adoro TDD e gostaria muito de comprar o livro, mas quando estava estudando pra certificação OCJP comprei o livro do Camilo e achei o livro muito ruim, mal escrito, mal revisado, e muito fraco tecnicamente. Novamente, com todo o respeito ao autor, sobre o qual não tenho nada a comentar, mas essa foi a minha opinião sobre a obra.

Como TDD é um assunto que me interessa bastante, o livro até me interessa, mas dado esse histórico…no blog será disponibilizado um “preview”?[/quote]

alias obrigado por trazer esse comentário(nem eu gosto dos livros do Paulo Coelho :slight_smile: ). Gosto de ouvi-los. Apesar que tenho recebido quase 0, pois os emails dos leitores do meu primeiro livro, todos que recebi foram positivos, e há até posts aqui no no guj recomendando, mas isso é muito pessoal e vai de cada um. Há livros que eu tb já comprei que odiei, mas um colega do lado adorou. Eu tenho que concordar com você que a revisão poderia ter sido melhor, mas para aquele livro sair foi mais que um parto 2 anos trabalhando sozinho, a editora se envolveu apenas 6 meses perto da publicação.Enfim, foi muito estresse entre eu e a editora na época.E agora todo projeto eu imprimo ele antes e leio como se fosse o leitor (é dificil por estar envolvido há meses com o conteúdo), faço as revisões, contrato uma revisora à parte e depois mando para editora, para q eles façam a revisão deles. Há muitas coisas no mundo editorial aqui no Brasil que não posso comentar, mas é o que temos infelizmente. Já participei de revisão de uma editora fora do país, e lá as coisas são bem diferentes e bem melhor. E sobre a parte técnica do livro SCJP, eu sou suspeito, mas eu digo sempre que é importante alinhar o conteúdo técnico com o objetivo do livro. O mesmo para o livro de TDD, ele é para quem é iniciante ou nunca brincou com a técnica. Se o cara já “macaco velho”. É como eu digo no livro “não compre”. Assim que receber a versão final do livro por parte da editora, estarei disponibilizando alguns capítulos.

flw.