Vitor Pamplona

Innovation on Vision: Imaging , Enhancement and Simulation

Debug Driven Development

É engraçado ver como lugares diferentes, propósitos diferentes, demandam estilos diferentes de programação. Sempre fui fã do Desenvolvimento Dirigido a Testes (TDD), porém, em certos lugares, o TDD não é a melhor opção. E não é por preguiça ou problema de adaptação da equipe, é por otimização de resultados mesmo. Aqui no Mestrado, por exemplo, eu tenho uma rotina de desenvolvimento muito diferente de qualquer empresa de software. Utilizo um estilo de programação que não é orientada ao usuário final, nem ao domínio e muito menos a testes (embora eu utilize testes automáticos sempre que é possível). É uma espécie de Desenvolvimento Dirigido a Debug (DDD). Explico.

O propósito dos softwares criados aqui no grupo é um só: publicação. E, para tal, é necessário que todas as teorias, técnicas e estruturas de dados sejam apresentadas, argumentadas, comparadas e validadas. É necessário provar com números e não com " achismos " cada opção, cada suspeita, cada frase. O resultado é um artigo tão fechado e tão cheio de gráficos e validações provenientes dos programas que poucas pessoas contra-argumentam.

Os sistemas tem uma alta incidência de formulações matemáticas avançadas como integrais e derivadas. Embora que o resultado destas equações possa ser validado por TDD, muitas vezes é necessário saber o que está ocorrendo no meio de uma equação, durante algum processo. É este tipo conhecimento que nos permite desenvolver novas teorias, sugerir melhorias, provar as nossas idéias e avançar a ciência. No entanto, este conhecimento é, muitas vezes, difícil de extrair utilizando as ferramentas de debug genéricas convecionais. Portanto, é comum ver os desenvolvedores implementando ferramentas de Debug específicas para cada caso.

 Imagine o seguinte caso. Você está criando a animação de um círculo que aumenta e diminui o seu raio baseado em uma equação diferencial grandinha. Certo dia, você vê uma variação estranha na animação, um pico íngreme no raio que faz os resultados ficarem irreais para os olhos de um especialista. Você não pode deixar esse ponto em aberto para a publicação, precisa saber o que está acontecendo. Para tal, você implementa no seu programa mesmo uma série de vizualizações de vários ângulos, gráficos da animação, gráficos de partes da equação, gráficos de velocidade, gráficos e amplitude da tua derivada, gráficos da derivada de segunda ordem e por aí vai. Tudo por casa de uma variação quase imperceptível as pessoas normais, mas que certamente será contra-argumentada pelos revisores do artigo. Desta forma você tem muito mais do que seus resultados no programa e você já desenvolve pensando no debug visual para o artigo a fim de evitar perda de tempo durante a escrita do mesmo, lá na frente. Algo como a imagem ao lado.

Cria-se então, uma espécie de programação orientada a debug. Centrada em focar o software em gráficos, animações e passo-a-passos que auxiliem na explicação das teorias quando estas são apresentadas. Que é um estilo bem curioso a meu ver, pois dá ao " leitor ", a informação correta e clara sobre o que acontece com o software em cada momento. O leitor sabe o que está acontecendo, não é uma caixa preta como normalmente se vê por aí.

Além do mais, todos sabem que ninguém utilizará o seu código no futuro, apenas utilizarão as novas idéias descritas no artigo. Não existe usuário final ou melhor, o usuário final é o próprio desenvolverdor. O sistema só existe para garantir que a idéia do desenvolvedor é válida e funciona corretamente. Como somos de computação gráfica, os resultados que estão em nossos artigos são, geralmente, imagens, animações e gráficos. Imagens e animações são praticamente impossíveis de validar com testes unitários, na verdade é possível, mas o trabalho é tão grande que não faria sentido utilizar.

Outro ponto interessante é que aqui não existem equipes. Normalmente o software é desenvolvido por uma única pessoa. Nas raras ocasiões em que há duas pessoas trabalhando no mesmo fonte, eles fazem questão de um não mexer no código do outro para evitar perda de tempo com a gerência do desenvolvimento. Ou seja, ao invés de perder tempo criando uma estrutura de desenvolvimento, com softwares de gerenciamento e etc, opta-se, com sucesso, por políticas interpessoais simples. É mais fácil perguntar sobre ou pedir um fonte a um amigo do que instalar uma estrutura de SVN e forçar todos a usá-la.

No nosso " mercado " é muito comum o uso do Ctrl + C + Ctrl + V. Explico. Ao invés de alterar o seu programa, criando telinhas de configuração com inúmeras opções, como o software é descartado após a submissão do artigo, é comum copiar o sistema da maneira como está e trabalhar nele para o artigo especificamente. Isto não prejudica a legibilidade da versão original com ferramentas de debug desnecessárias. Eu por exemplo, apesar de trabalhar com SVN, já tenho 4 versões diferentes para cada uma dos meus 5 softwares de uso e desenvolvimento diário. Cada uma tem uma particularidade. E pensando agora, eu levaria cerca de 2 anos para juntar todas elas numa versão só, criando uma arquitetura OO de acordo com as nossas leis javeiras e mantendo os algorítimos e resultados intactos.

Outra coisa engraçada. As telas aqui não são nada user-friendly. Apesar da computação gráfica estar ligada as áres de interação Humano-Computador, as nossas interfaces são mais obscuras que " qualquer coisa que você já viu na sua vida ":). Na minha por exemplo, cada tecla pressionada (case-sensitive) faz alguma coisa no software. Algumas para debug, outras para animação, outras para um passo-a-passo, outras para configuração, outras para interação visual, etc. O meu help, o texto que diz o que cada tecla faz é um arquivo TXT com explicações detalhadas.

Eu simplesmente não vejo um meio de desenvolvimento mais produtivo ou com mais qualidade que esse, sem que este novo com melhorias qualitativas consuma um tempo além dos dois anos do curso. Além disso, eu acredito que muito software comercial precisa, em partes, de um desenvolvimento dirigido a debug. Acreditem é muito legal bater o olho em uma imagem ou animação e ver como o software funciona. Alguém já fez uma animação com dados reais do momento num software para linha de produção? Posso apostar que se a animação for bem feita o gerente de processos vai só bater o olho e saber o que está fazendo cada setor de sua empresa.

Estou até pensando em criar novos diagramas para desenvolvimento de software. Um diagrama muito mais claro que os já existentes.

Posted in Sep 29, 2008 by Vitor Pamplona - Edit - History

Showing Comments

Bah, justamente que eu vem fazendo para programar um sistema de detecção de colisão em 3D. Apesar de meu trabalho não ser tão matematicamente pesado quanto o seu, o debugger é realmente uma mão na roda para saber onde as equações estão nós traindo.

O chato é que como você mesmo escreveu " Imagens e animações são praticamente impossíveis de validar com testes unitários... ", então tenho que ficar usando o Alt-Tab para alternar entre o gdb e a tela.

- - O

- - Posted in Jan 26, 2008 by 189.6.242.136

Interessante...

- - Pedro

- - Posted in Jan 26, 2008 by 189.27.240.128

Add New Comment

Your Name:


Write the code showed above on the text below.