Entrevista sobre tópicos atuais com Donald Knuth

Daniel Quirino Oliveira wrote:O dia em que as pessoas começarem a entender que TDD e unit tests menos a ver com testes em si e mais a ver com design, boa parte das threads do GUJ vão perder sentido

Pois é. Varios momentos eu leio codigo e penso "se tivesse unit test, nao estaria abrindo esse FileInputStream aqui no meio dessa classe". TDD leva ao desacoplamento.

AIMEUDEUSOKNUTHNAOUSAUNITTESTSEAGORAOQUEEUFAÇO?!?!?!??

O dia que eu tiver trabalhando isolado, numa plataforma que eu inventei, num sistema que eh praticamente 99% teoria computacional, eu paro de escrever unit tests

This message was edited 1 time. Last update was at 29/04/2008 07:57:40

O dia que eu puder mandar cheques de valores exponenciamente crescentes para cada bug encontrado no meu sistema também paro de escrever testes.

Por exemplo, se eu começar com um cheque 2 reais e aparecerem uns 39 tópicos sobre bugs no fórum do meu projeto de fundo de quintal, vou torrar 549.755.813.888 no último deles. Provavelmente nem vendendo todos jatinhos do meu chefe vou conseguir pagar esse valor se compensarem.

Inspirado nessa thread: http://gc.blog.br/2008/04/29/programadores-de-schrodinger/

This message was edited 1 time. Last update was at 29/04/2008 21:45:05

Olá

Um comentário meio nada a ver com o assunto mas que tem a ver como minha relação com o Dr Knuth.

Confesso que nas primeiras leituras que fiz do Knuth tive imensa dificuldade para entender. Naquela época não tinha nada pronto. Se você quisesse um sort, tinha que escrever o seu na raça. Vivíamos na época em que busca binária era novidade e tabelas hash prometiam ser a última Coca Cola do deserto. Fui atrás dos 3 livros do Knuth como a solução dos meus problemas. Como eram livros muito caros para importar, ia até a USP para estudá-los. Vários capítulos me exigiram ler mais de uma vez.

Se eu tivesse estudado o Knuth depois de algum outro livro mais básico ou se tivesse tido um professor para me explicar algumas dúvidas por falta de base teórica, talvez pudesse ter lido em muito menos tempo.

E ainda achava muito chato de ler os algorítmos escritos naquele assembler maluco.

Confesso que não sei de nenhuma atividade não acadêmica do Dr Knuth. Acho que no fundo ele não passa de um nerd que envelheceu.

Abaixo um dos cheques de US$ 2.56 (equivalente a 256 pennies em 1 dolar hexadecimal) que ele deu para os que acharam um erro tipográfico em seus livros.

Ele fez muitos cheques que somavam até março de 2005 um total de US$ 20 mil, mas poucos deles foram depositados porque quem achou algum erro preferiu guardar o cheque como troféu. Como alguém assinou no Slashdot:
- Intelligence: Finding an error in a Knuth text.
- Stupidity: Cashing that $2.56 check you got.

http://en.wikipedia.org/wiki/Donald_Knuth

[]s
Luca (velho, mas fã de testes unitários)

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

pcalcado wrote:Exato, e elas sao complementares.

Ele nao usa porque nao precisa.

Poxa, dessa eu não sabia, que existia gente que não precisa de testes

Vou compartilhar uma coisa com vocês. Estive programando sozinho um software para controle de projetos de engenharia mecânica e civil. Bem, numa primeira fase que era um protótipo, passei praticamente 4 meses programando sozinho. Como era um protótipo logicamente não tinha testes unitários e nem qualquer teste, pois era só uma prova de conceito (a gente nem sabia se o projeto iria de fato rolar).

Bem, quando virou um projeto de verdade tive que saldar esse débito técnico e escrever os testes junto com uma equipe pequena. Não foi uma das tarefas mais gostosas não.

Independente disso, agora estou sozinho de novo. De fato, faz uns 3 meses que estou sozinho. Realmente É BEM MAIS FÁCIL programar sozinho. Você pode fazer integração contínua só 1 vez por dia. Pode até esquecer de fazer algumas vezes na semana. Eu estou escrevendo os testes antes mas por ter me acostumado a isso. Quando você está sozinho é menos comum os testes quebrarem comparado do que quando você está em equipe.

É mais fácil gerenciar débito técnico quando você está sozinho.

rodrigoy wrote:É mais fácil gerenciar débito técnico quando você está sozinho.

Em compensacao, eh bem mais dificil se manter motivado, revisar o codigo pra descobrir onde estao problemas em potencial (ou partes que podiam ser melhoradas), e vc aprende bem menos.

E quando você muda o coração da sua aplicação você sabe que não matou as outras partes

E quando você tem uma idéia você escreve num teste ao invés de um pedaço de papel

E você ganha user stories bem documentadas gratuitas

E daqui há quinze dias, quendo o projeto der uma desafogada e você tiver tempo para seus pets de novo, voc6e vai conseguir continuar e não escrever tudo de novo

E quando sair alguma coisa do seu pet projeto você vai poder compartilhar cm alguém que pode começar a entender apenas lendo seus testes

E... por ai vai.

Senhores,

me desculpem a sinceridade, mas

eu trabalho com várias pessoas que são "geniais", e posso assegurar que a maior parte dessas pessoas que trabalham com computação científica jamais leram qualquer coisa sobre testes unitários e o que as tornam diferentes são a capacidade de criar novas técnicas e aplicar técnicas as vezes elementares em problemas que ninguém tinha ousado resolver. Em suma, a maior parte dos códigos estão sendo escritas em C, prolog, pseudo-código, matlab etc. A comprovação da solução são realizados com cálculos matemáticos e experimentais...

Neste contexto, que é o universo que o Dr Knuth faz parte, ninguém quer saber se ele usa a metodologia A ou B, se ele escreve com a ferramenta X ou Y e simplesmente querem saber o que eles estão aprontando... para o mundo começar a utilizar daqui uns 10 ou 20 anos.

Novamente, não acredito que as técnicas e argumentos apresentados até aqui melhore significativamente o trabalho dessas pessoas... Eu acredito que é absolutamente ERRADO assumir que qualquer técnica ou metodologia pode ser aplicadas a qualquer ou todos tipos de problemas e soluções.

Acho que o entrevistador foi infeliz em não ver que o Dr Knuth não faz parte do grupo de pessoas que usam a tecnologia para desenvolver sistemas corporativos e que ele na realidade faz parte de um reduzido time que CRIA nova técnicas, que talvez venhamos utilizar um dia.

Acho que devemos criticar menos as pessoas pelo que elas usam ou pensam e mais pelo que elas fazem ou deixem de fazer...

Knuth é o pai de toda base algoritmica e lógica computacional, acho que devemos respeitar melhor a visão dele.

fw

Olá

Dieval Guizelini wrote: pessoas que trabalham com computação científica jamais leram qualquer coisa sobre testes unitários e o que as tornam diferentes são a capacidade de criar novas técnicas e aplicar técnicas as vezes elementares em problemas que ninguém tinha ousado resolver. Em suma, a maior parte dos códigos estão sendo escritas em C, prolog, pseudo-código, matlab etc. A comprovação da solução são realizados com cálculos matemáticos e experimentais...

Concordo em parte e acrescento algumas considerações e ressalvas:

1) O uso de testes unitários não é igual em todos os ambientes de programação. Em Ruby, por motivos que não vou me alongar, são necessários muito mais testes unitários do que em Java. Já em Java se usa muito mais do que em C/C++, Fortran e outras, tanto por necessidade como por hábito.

2) Hoje em dia há bibliotecas para testes unitários do tipo JUnit para praticamente todas as linguagens. Como exemplo cito Fortran: FUnit (hospedado no site da NASA) e Fruit do sourceforge. Nem sempre estas bibliotecas são tão evoluídas como as do Java e do Ruby. E nem sempre valem o esforço de aprender a usar para trocar pelos tradicionais meios de assegurar correção do código. Há gente que programa em Fortran que preferia a opção de logar tudo que foi feito e conferir o log na mão. Tenho programas antigos do início da década de 80 que era assim que se faziam testes unitários.

3) Quando a gente trabalha tentando fazer um algoritmo funcionar, algumas vezes o problema do algoritmo está na teoria. Acreditem ou não, mas no meu mestrado levei um mês para retirar um bug de um algoritmo porque naquela época não havia google e eu precisava passar horas e horas na biblioteca fuçando livros atrás de alguma justificativa do porque aquela condição matemática falhava. Assim, pelo menos no meu tempo, era comum no ambiente científico, o cara escrever um código tosco só como prova de conceito e só depois de testado isoladamente refatorar para algo que podia ser usado dentro de um sistema. Era uma éspecie de teste unitário tentando fazer a fórmula funcionar isoladamente.

[]s
Luca

Luca, que tal postar no seu blog sobre esse bug (nem q seja de forma resumida)?

Hoje em dia, como vc resolveria com o google?

rodrigoy wrote:Vou compartilhar uma coisa com vocês. Estive programando sozinho um software para controle de projetos de engenharia mecânica e civil. Bem, numa primeira fase que era um protótipo, passei praticamente 4 meses programando sozinho. Como era um protótipo logicamente não tinha testes unitários e nem qualquer teste, pois era só uma prova de conceito (a gente nem sabia se o projeto iria de fato rolar).

Bem, quando virou um projeto de verdade tive que saldar esse débito técnico e escrever os testes junto com uma equipe pequena. Não foi uma das tarefas mais gostosas não.

Independente disso, agora estou sozinho de novo. De fato, faz uns 3 meses que estou sozinho. Realmente É BEM MAIS FÁCIL programar sozinho. Você pode fazer integração contínua só 1 vez por dia. Pode até esquecer de fazer algumas vezes na semana. Eu estou escrevendo os testes antes mas por ter me acostumado a isso. Quando você está sozinho é menos comum os testes quebrarem comparado do que quando você está em equipe.

É mais fácil gerenciar débito técnico quando você está sozinho.

Nos meus projetos solo eu sou muito mais desleixado com o código que escrevo e confio muito mais nos testes que normalmente no trabalho. Faço isso pois é muito mais produtivo e divertido. Nem sempre escrevo testes unitários pois, devido ao desleixo, estou mais preocupado com o resultado final então me foco em testes funcionais. Ultimamente só tenho escrito software fora da curva, pois para quase todos todos eles é mais fácil escrever testes de aceitação que unitários, o que explica meu foco.

cv wrote:

rodrigoy wrote:É mais fácil gerenciar débito técnico quando você está sozinho.

Em compensacao, eh bem mais dificil se manter motivado, revisar o codigo pra descobrir onde estao problemas em potencial (ou partes que podiam ser melhoradas), e vc aprende bem menos.

Sim... é exatamente isso!!! Motivação pega.

This message was edited 1 time. Last update was at 01/05/2008 15:41:55

Luca wrote:Olá
(...)
[]s
Luca

Concordo Luca, e acho que para os "normais" não existe justificativa para não se fazer uso destas técnicas...

Passei por experiências similares, como os bugs de ponto flutuante da biblioteca do MS-C 5....

até onde me recordo, um bom depurador ajudava nestes casos, naturalmente se os autores da biblioteca tivessem usados os testes unitários, provavelmente os bugs não existiriam...

Eu adorava o Turbo Debugger da Borland, e o depurador do clipper era muito bom, mesmo nas primeiras versões....

Mas, o que me chamou a atenção foi o fato da discussão ocorrer se Knuth usa ou não testes e se ele tem ou não que usar essa metodologia....

Knuth é para mim como o nosso glorioso Oscar Niemeyer, que com 100 anos de vida continua CRIANDO e não se limita as dificuldades que eventualmente uma estrutura pode apresentar... ele quebra o tradicional, faz a diferença... é obvio que depois que ele faz os rascunhos, precisam de um exército de pessoas para viabilizar o projeto.... mas e dai? vamos dizer ao genio para parar, para se restringir aos recursos básicos.... para desenhar prédios quadrados...

fw

Notícias, artigos e o maior fórum brasileiro sobre Java