Why TDD makes a lot of sense for Sudoko

15 views
Skip to first unread message

Marcelo Hablocher

unread,
Aug 28, 2017, 4:15:05 PM8/28/17
to TDD no mundo real
Olá pessoal!

Não sei se todos no grupo já viram este artigo. Me deparei com ele recentemente. Por achar bem interessante, estou divulgando.


Valeu!

Marcelo

Maurício Aniche

unread,
Aug 30, 2017, 5:43:31 AM8/30/17
to TDD no mundo real
Oi Marcelo,

Obrigado por compartilhar o link! Eu conhecia o post do Norvig!

Acho que com o passar dos anos, fiquei um pouco mais cético quanto aos efeitos de TDD (como prática *isolada*). IMHO, o grande truque ainda é ter uma "caixa de ferramentas grande" e conhecer boas práticas de design de código e algoritmos. Estudar, estudar, estudar. Sem saber/dominar design de classes OO (ou qualquer boa prática do seu paradigma), não há mágica. 

Nesse post o autor diz que começou com "recursive depth first search". Bem, TDD não ensinou isso pra ele. Se vc não souber o que é um DFS em um grafo, muito provavelmente vc não vai sair com essa solução. Já li soluções que usam algoritmos de busca com meta-heurística [1] para resolver o problema. TDD não vai te ajudar a derivar tal solução *nunca*. Aliás, não executei a solução dele, mas inspecionando o código, é força bruta. E, como ele mesmo escreve, a solução demorou algum tempo pra executar em um sudoku grande. Pq TDD não o ajudou a resolver isso tb? Pra resolver, só entendendo e desenhando um algoritmo bom mesmo!! A solução do Norvig tem várias otimizações e talvez por isso seja mais longa. 

Lembro-me claramente do meu estudo de mestrado, onde eu queria demonstrar de todo e qualquer jeito que TDD fazia mágica. Não consegui. Peguei participantes do meu experimento me dizendo "puxa, coincidentemente ontem estudei Observer, e aí apliquei ele aqui". Ou participantes (maioria) que produziram o mesmo código com e sem TDD.

Pensar em testes e fazer TDD pra te forçar isso vai ajudar a testar de maneira mais fácil. Mas se vc não sabe escrever uma classe testável (vc não entende ainda de isolar e injetar dependências, coesão, ou acoplamento), será que sai algo?? Tenho um post no meu draft sobre isso. Vamos ver se crio coragem para terminar!


Um abraço,

--
Você recebeu essa mensagem porque está inscrito no grupo "TDD no mundo real" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para tdd-no-mundo-r...@googlegroups.com.
Para mais opções, acesse https://groups.google.com/d/optout.
--
Maurício Aniche
Postdoc researcher
Delft University of Technology
@mauricioaniche

Rafael Ponte

unread,
Aug 30, 2017, 9:04:19 AM8/30/17
to TDD no mundo real
Oi Mauricio, muito bacana sua resposta.

Assim como você eu acredito que TDD vai te ajudar até determinado ponto com relação ao design e qualidade do seu código - o que já é muita coisa mesmo. Sem conhecimentos de design de classes, refactoring, OO, SOLID, design patterns, algoritimos etc o TDD não vai fazer mágica na sua cabeça do tipo "Eureka!" para te induzir a melhor solução, no entanto TDD pode te mostrar que há espaço para melhoria no seu código, embora você não saiba como. Comecei a pensar e refletir sobre isso após ler seus artigos, palestras, livros e discutir com você algumas vezes em eventos e foruns. Ah, até lembrei que houve uma discussão bacana sobre isso no Twitter semanas atrás com uma galerinha boa!

Enfim, como você disse, é necessário MUITO estudo e prática. No caso dos grafos, onde eu nunca estudei sobre, mesmo com meu conhecimento de OO e TDD eu tenho certeza absoluta que jamais implementaria uma boa solução, eu precisaria estudar sobre o assunto antes ou durante a implementação do código.

Um abraço,

Rafael Ponte
TriadWorks | Formação Java
http://cursos.triadworks.com.br

Daniel Franzini

unread,
Aug 30, 2017, 10:21:43 AM8/30/17
to tdd-no-m...@googlegroups.com
Na minha experiência, que é de um mundo meio diferente (C para embarcados), o TDD não te ajuda a bolar uma solução boa mas te ajuda a garantir que qualquer solução atende ao que foi pedido e que nas evoluções futuras, ainda vai atender.

Para mim, TDD é mais um porto-seguro (e uma ferramenta para lidar com Elefantes de código-legado, como código PL/SQL[1]) para que eu tenha eficiência em produzir um código minimamente entregável. Um test-set abrangente e automático é algo que se tornou indispensável para qualquer um que entrega algo não-trivial.


[1] Eu tenho os meus próprios Elefantes mas o seu é mais famoso, @Rafael Ponte.

2017-08-30 10:04 GMT-03:00 Rafael Ponte <rpo...@gmail.com>:
Oi Mauricio, muito bacana sua resposta.

Assim como você eu acredito que TDD vai te ajudar até determinado ponto com relação ao design e qualidade do seu código - o que já é muita coisa mesmo. Sem conhecimentos de design de classes, refactoring, OO, SOLID, design patterns, algoritimos etc o TDD não vai fazer mágica na sua cabeça do tipo "Eureka!" para te induzir a melhor solução, no entanto TDD pode te mostrar que há espaço para melhoria no seu código, embora você não saiba como. Comecei a pensar e refletir sobre isso após ler seus artigos, palestras, livros e discutir com você algumas vezes em eventos e foruns. Ah, até lembrei que houve uma discussão bacana sobre isso no Twitter semanas atrás com uma galerinha boa!

Enfim, como você disse, é necessário MUITO estudo e prática. No caso dos grafos, onde eu nunca estudei sobre, mesmo com meu conhecimento de OO e TDD eu tenho certeza absoluta que jamais implementaria uma boa solução, eu precisaria estudar sobre o assunto antes ou durante a implementação do código.

Um abraço,

On Wed, Aug 30, 2017 at 6:43 AM Maurício Aniche <maurici...@gmail.com> wrote:
Oi Marcelo,

Obrigado por compartilhar o link! Eu conhecia o post do Norvig!

Acho que com o passar dos anos, fiquei um pouco mais cético quanto aos efeitos de TDD (como prática *isolada*). IMHO, o grande truque ainda é ter uma "caixa de ferramentas grande" e conhecer boas práticas de design de código e algoritmos. Estudar, estudar, estudar. Sem saber/dominar design de classes OO (ou qualquer boa prática do seu paradigma), não há mágica. 

Nesse post o autor diz que começou com "recursive depth first search". Bem, TDD não ensinou isso pra ele. Se vc não souber o que é um DFS em um grafo, muito provavelmente vc não vai sair com essa solução. Já li soluções que usam algoritmos de busca com meta-heurística [1] para resolver o problema. TDD não vai te ajudar a derivar tal solução *nunca*. Aliás, não executei a solução dele, mas inspecionando o código, é força bruta. E, como ele mesmo escreve, a solução demorou algum tempo pra executar em um sudoku grande. Pq TDD não o ajudou a resolver isso tb? Pra resolver, só entendendo e desenhando um algoritmo bom mesmo!! A solução do Norvig tem várias otimizações e talvez por isso seja mais longa. 

Lembro-me claramente do meu estudo de mestrado, onde eu queria demonstrar de todo e qualquer jeito que TDD fazia mágica. Não consegui. Peguei participantes do meu experimento me dizendo "puxa, coincidentemente ontem estudei Observer, e aí apliquei ele aqui". Ou participantes (maioria) que produziram o mesmo código com e sem TDD.

Pensar em testes e fazer TDD pra te forçar isso vai ajudar a testar de maneira mais fácil. Mas se vc não sabe escrever uma classe testável (vc não entende ainda de isolar e injetar dependências, coesão, ou acoplamento), será que sai algo?? Tenho um post no meu draft sobre isso. Vamos ver se crio coragem para terminar!


Um abraço,

On Mon, Aug 28, 2017 at 10:15 PM Marcelo Hablocher <habl...@gmail.com> wrote:
Olá pessoal!

Não sei se todos no grupo já viram este artigo. Me deparei com ele recentemente. Por achar bem interessante, estou divulgando.


Valeu!

Marcelo

--
Você recebeu essa mensagem porque está inscrito no grupo "TDD no mundo real" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para tdd-no-mundo-real+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.
--
Maurício Aniche
Postdoc researcher
Delft University of Technology
@mauricioaniche

--
Você recebeu essa mensagem porque está inscrito no grupo "TDD no mundo real" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para tdd-no-mundo-real+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.
--
Rafael Ponte
TriadWorks | Formação Java
http://cursos.triadworks.com.br

--
Você recebeu essa mensagem porque está inscrito no grupo "TDD no mundo real" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para tdd-no-mundo-real+unsubscribe@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.



--
Daniel

"Let us change our traditional attitude to the construction of programs. Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do." (Donald Knuth)

"Yes, technogeeks can be funny, even if only to each other." (http://www.boogieonline.com/revolution/science/humor/)"

"Man is driven to create; I know I really love to create things. And while I'm not good at painting, drawing, or music, I can write software." (Yukihiro Matsumoto, a.k.a. ``Matz'')

Alexandre Aquiles

unread,
Aug 30, 2017, 11:00:36 AM8/30/17
to TDD no mundo real
Lembrei do Uncle Bob fazendo um algoritmo de ordenação com TDD, usando aquela ordem de transformações dele (Transformation Priority Premise).

Teoricamente, ele chegou ao QuickSort.

Mas vale o que Aniche descreveu: o tio Bob JÁ CONHECIA o QuickSort. Todo mundo carrega uma bagagem de experiências e conceitos consigo.

BTW, no post original sobre o Transformation Priority Premise, o tio Bob diz que era uma maneira de evitar que você espelhasse o código de testes no de produção, o que levaria a algoritmos horríveis:
"I invented it as rule to prevent my TDD students from acquiring the nasty habit of writing production code that mirrored the tests"

Agora, TDD já me ajudou a chegar numa solução meia boca (ou não) mesmo sem a bagagem necessária, como disse o Daniel. E a entender melhor um problema e os requisitos; a quebrar o gelo; a manter um ritmo.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para tdd-no-mundo-r...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.
--
Maurício Aniche
Postdoc researcher
Delft University of Technology
@mauricioaniche

--
Você recebeu essa mensagem porque está inscrito no grupo "TDD no mundo real" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para tdd-no-mundo-r...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.
--
Rafael Ponte
TriadWorks | Formação Java
http://cursos.triadworks.com.br

--
Você recebeu essa mensagem porque está inscrito no grupo "TDD no mundo real" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para tdd-no-mundo-r...@googlegroups.com.

Para mais opções, acesse https://groups.google.com/d/optout.

Maurício Aniche

unread,
Aug 30, 2017, 11:04:43 AM8/30/17
to TDD no mundo real
É, esse post do Uncle Bob foi o que começou a me decepcionar sobre a comunidade TDD, haahaha.

Rafael Ponte

unread,
Aug 30, 2017, 12:11:05 PM8/30/17
to TDD no mundo real
Se não estou enganado, esse post do Uncle Bob foi aquele na qual ele dizia que bastava seguir sua lista de prioridades (passos) que era possível resolver qualquer problema com a melhor solução e melhor qualidade de código. Lembro que o bafafa na epoca foi grande!
Reply all
Reply to author
Forward
0 new messages