Recentemente chegou às bancas a edição de número 09 da revista MundoDotNet. Essa edição conta com um artigo onde descrevo uma técnica interessante para administração de cenários de testes implementada com sucesso pelo meu colega Paulo Cesar Fernandes aqui na empresa.  A técnica consiste em interceptar a execução de métodos de forma a armazenar objetos construídos durante a execução da aplicação em um banco de dados orientado a objetos. Assim, esses objetos podem ser carregados na memória no momento em que são necessários para o SetUp de testes unitários. Na verdade, o artigo foi um pouco além de descrever a técnica. Grande parte do texto é dedicada a explicar as raízes e as várias formas em que técnicas de teste podem ser utilizadas para aumentar a qualidade do software no contexto de um projeto ágil. Alguns tópicos e trechos do artigo Uma nova visão para as atividades de teste de software:  A relação das atividades de teste com qualidade. Algumas das idéias de Deming que podem ser utilizadas em desenvolvimento de software. A relação de Deming com o estilo de administração japonês que levou ao Movimento Ágil e as técnicas que este movimento trouxe de forma a permitir a redução de inpeções no software. Testes como oportunidades para aumentar a qualidade: Em projetos ágeis, testar significa criar oportunidades para que o produto absorva elementos de qualidade de forma permanente. "Um teste automatizado injeta qualidade dentro do software". Quando testes automatizados podem aumentar a qualidade do processo:  Testes de aceitação automatizados criam as condições para melhoria do processo de desenvolvimento na medida em que estabelecem um instrumento de colaboração e de comunicação entre clientes e desenvolvedores. "o propósito de um teste de aceitação é aumentar a qualidade do processo de comunicação necessário para as atividades de análise e levantamento de requisitos, por meio de especificações executáveis". Quando testes automatizados podem aumentar a qualidade do produto: Aqui a defesa é que o uso de TDD aumenta a qualidade interna do produto na medida em que cria as condições para a evolução sustentável do software. "o propósito do teste unitário é influenciar o design da aplicação, permitindo que ele evolua sem sofrer os danos causados pelo seu processo de degradação". O artigo também oferece um rápido exemplo de como uma ferramenta como o Fitnesse pode criar especificações executáveis fáceis de ler e de produzir. Conforme imagem a seguir:   A abordagem Ágil oferece uma nova perspectiva para endereçar qualidade de software. Acho que esse artigo dará ao leitor uma boa idéia do que isso quer dizer.

Posted by: alisson.vale
Posted on: 6/17/2008 at 9:43 PM
Tags: , ,
Categories: Coding | Projetos Ágeis
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (3) | Post RSSRSS comment feed
 
 
Essa semana saiu mais uma edição da Revista MundoDotNet. Desta vez, pude dar minha contribuição com um artigo em que a idéia é relacionar "métricas de código" com "design de software".  Acho que ainda exploramos muito pouco dos benefícios que as métricas de código podem oferecer para o aumento nos níveis de qualidade do design de um software. Apesar de haver muitas ferramentas, raramente se vê alguém que efetivamente obtém alguma vantagem em utilizar as informações que elas geram. De maneira geral, eu tento dar ali um caminho para se chegar a sintomas de problemas de design por meio da análise numérica de informações extraídas do código-fonte. Assim como um médico pode usar os números extraídos de exames - como números de plaquetas, ph, taxas de glicose e colesterol e outras centenas de índices possíveis - para diagnosticar doenças e prescrever tratamentos, desenvolvedores de software também podem. Um dos caminhos é saber como algumas medições revelam problemas no design. Obviamente que números não são suficientes para avaliar o design de um software. A avaliação subjetiva e humana sempre será necessária. Mas eles podem sim ser de grande ajuda nessa questão. Quando falamos em "problemas de design", a primeira coisa que me vem a cabeça são os mau-cheiros de código que nos levam aos padrões de refatoração. Assim, o artigo tenta mostrar como podemos encontrar pontos de refatoração à partir de métricas coletadas no código-fonte. Além disso, há a questão de utilizar tal abordagem de modo sistêmico, criando assim alguns mecanismos de proteção contínua do design e abrindo espaço para a evolução do código de forma contínua. Sei que muitos leitores desse blog não trabalham e também não conhecem a plataforma .Net. Mas, mesmo para eles, recomendo comprar de vez em quando a MundoDotNet (eu não trabalho com Java, mas estou sempre lendo a MundoJava). A MundoDotNet é uma revista que foca na plataforma, porém com uma boa ênfase em aspectos gerais sobre desenvolvimento (como design, arquitetura e técnicas de desenvolvimento), o que a faz ser atraente para qualquer um que leve desenvolvimento a sério. No caso do meu artigo em específico, ele poderá ser lido e aproveitado por usuários de qualquer plataforma de desenvolvimento. Se quiser discutir sobre o artigo, é só deixar um comentário aqui ou me enviar um e-mail. Boa Leitura! 

Posted by: alisson.vale
Posted on: 2/12/2008 at 7:40 PM
Tags: ,
Categories: Coding | Design
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (6) | Post RSSRSS comment feed
 
 
Às vezes algumas idéias impressionam pela criatividade e simplicidade. Quem costuma fazer pair programming e/ou gosta de manter as mãos no teclado o máximo de tempo possível enquanto desenvolve na IDE, vai gostar do AddIn que Roy Osherove construiu: o KeyJedi. Ele exibe todas as teclas de atalho que são pressionadas enquanto se desenvolve. Ele pode ser utilizado para: Produção de Screencasts - quem está assistindo não se perde quando o desenvolvedor utiliza teclas especiais para efetuar operações de forma mais rápida; Aprendizado em sessões de Pair Programming - o co-piloto pode aprender alguns acessos rápidos enquanto assiste o piloto operando a IDE. Auto-Disciplina - O KeyJedi permite que você "prenda" o mouse em sua janela enquanto está desenvolvendo. Ou seja, ele não deixa você usar o mouse na IDE. Isso vai te ajudar a adquirir o costume de não recorrer ao mouse enquanto está desenvolvendo. O interessante é que se você alternar para outro aplicativo o mouse é automaticamente liberado. Obviamente, você pode configurar qual a tecla de atalho que prende e solta o mouse. Muito útil para quem quer se auto-disciplinar e ganhar produtividade enquanto desenvolve.

Posted by: alisson.vale
Posted on: 6/26/2007 at 2:48 AM
Categories: Coding
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed
 
 
O singleton é um dos design patterns mais populares e mais simples de implementar. Nesse post, eu descrevo como esse pattern do GoF pode ser uma armadilha de design quando utilizado de forma inapropriada. [More]

Posted by: alisson.vale
Posted on: 11/22/2006 at 2:39 PM
Categories: Coding | Design
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed
 
 
Post sobre TDD e sua verdadeira natureza que visa propiciar um melhor design para as aplicações. [More]

Posted by: alisson.vale
Posted on: 3/15/2006 at 2:54 AM
Categories: Coding
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed
 
 
Pra quem, como eu, trabalha com C# ou outras linguagens .Net, a busca pela IDE perfeita têm sido mais árdua do que, por exemplo, nossos amigos que trabalham com plataformas e, principalmente, comunidades mais maduras, como é o caso do Java. [More]

Posted by: alisson.vale
Posted on: 2/27/2006 at 7:57 PM
Categories: Coding
Actions: E-mail | Kick it! | DZone it! | del.icio.us
Post Information: Permalink | Comments (0) | Post RSSRSS comment feed