TDD – Test Driven Development

Algo que tem sido muito falado atualmente são as metodologias de desenvolvimento ágil, e um dos pilares de tais metodologias é a TDD, traduzindo, Desenvolvimento Dirigido a Testes.

TDD (Test Driven Development) é um técnica de programação ágil que tem aspectos de especificação e validação.
Com TDD especificamos nosso software em detalhes no momento que vamos escrevê-lo criando testes executáveis e rodando-os de maneira que eles mesmos testem nosso software.

Trocando em miúdos, quando vamos escrever um software, nós começamos escrevendo seu teste, uma classe que vai testar o software, assim, testamos o software e vamos o remodelando até o momento no qual os testes não mais falharem, então concluímos que TDD pode ser definida como uma técnica de programação onde todo o código produzido é criado em resposta a um código que falhou.

Parece bem simples a princípio, mas não é. TDD tem muitas técnicas. Não é simplesmente uma forma de testar softwares, mas sim de desenhar as aplicações.

Como funciona?

Basicamente, escrevemos um teste, rodamos este teste até que algo falhe, escrevemos o código fonte mais simples possível para passar neste teste, escrevemos o teste (aprimorando-o para cobrir mais aspectos do código fonte do produto), testamos até que algo falhe, reescrevemos nosso código para que ele passe no teste…. e ficamos neste ciclo até nosso software estar completo!

Vale a pena conhecer mais o tema, sugestões são:

- Este ótimo post de Scot Ambler
- Este vídeo

Enjoy!

Firefox Accessibility Extension

Achei um ótimo plugin para o Firefox que possibilita testarmos aplicações WEB quanto as normas do W3C (ou normas que você pode criar).

Basta você instalar e executar os testes que desejar! É animal. Vale lembrar que é uma ótima prática produzir páginas de acordo com as normas do W3c!

Download e manual em http://firefox.cita.uiuc.edu/

Enjoy!

Técnicas de programação defensiva V

Continuando com os posts sobre programação defensiva, vamos para a quinta técnica:

Nunca deixe ninguém utilizar o que eles não deveriam utilizar!

Essa é fácil também. Quando estivermos programando algo, temos que pensar em proteger nossas coisas, ou seja, cuidar para que atributos, variáveis, classes, métodos, etc, possam ser utilizados somente por quem estiver autorizado a utilizar.

Como assim???

Falando mais praticamente, devemos limitar o escopo de nossos elementos ao menor nível possível. Por exemplo, devemos declarar atributos públicos, somente se realmente necessário.

Mas por que?

É simples. Imagine que deixando um atributo público, outras “pessoas” vão poder alterar seu valor, o mesmo vale para classes, métodos, etc… Isso não é perigoso? Alguem não pode alterar algo indevidamente? O correto é que você, em suas classes, tenha os métodos de acesso e alteração para os atributos da mesma, são os famosos getters e setters! Você deve ter os métodos de acesso aos seus atributos que garantam a persistência dos mesmos, ainda que seja uma classe simples, é muito importante criar os mecanismos de acesso no lugar de manter os atributos públicos.

É importante dizer que você não deve sair criando getters e setters indiscriminadamente, vale a pena a leitura deste artigo: http://blog.caelum.com.br/2006/09/14/nao-aprender-oo-getters-e-setters/.

Finalmente, vale a pena dar uma estudadinha nos modificadores de acesso do Java para implementar esta técnica mais eficientemente. Recomendo lerem esta página: http://www.javacamp.org/javaI/modifier.html.

É isso, cuide de suas coisas hein?!

Enjoy!

Técnicas de programação defensiva IV

Continuando com os posts sobre programação defensiva, vamos para a quarta técnica:

Mantenha seu código claro, evite complicações desnecessárias.

Esta tambem é fácil! Muitas pessoas, com boa intenção, tentam escrever um código muito “otimizado”, colocando várias instruções  na mesma linha, ou utilizando estruturas que não vão mais complicar do que agregar, assim, tornam o seu código fonte muito difícil de ler.

Tenha em mente que provavelmente outras pessoas vão ler seu código, e se você desenvolve algo muito complexo, mais tempo o programador vai levar para entender seu código, impactando assim o orçamento do projeto.

Um exemplo bobo que pode tornar um código mais simples de se entender, é a utilização de ( ) em empressões matemáticas, ou mesmo em comparações. Pode-se ainda pular linhas entre “etapas” do seu código fonte.

Uma boa prática para ser lembrada neste ponto, é a utilização do KISS.

Resumo da ópera: mantenha seu código o mais simples possível, obviamente sem abrir mão da perfeita funcionalidade do mesmo, mas evitando complicações desnecessárias.

Enjoy.

Técnicas de programação defensiva III

Dando seguência a série sobre programação defensiva, vamos para a terceira técnica:

Não acredite em ninguém.

Esta técnica é bem simples e prega que nunca devemos acreditar em usuário, arquitetos, programadores, classes, etc.

O que isso significa?

Significa por exemplo, que sempre devemos deixar nosso programa preparado para todas as possibilidades que ele possa vir a enfrentar. Um arquiteto pode lhe falar que seu programa vai receber sempre uma data quando chamado. Certo, mas é impossível não receber algum valor nulo(não acredite no arquiteto)? Quem te garante que o programa que chama seu programa faz todos os tratamentos adequadamente (não acredite em classes)? Qual sua garantia que o usuário vai sempre digitar uma data, e além disso, vai digitar no formato correto (nunca acredite em usuários)?

Com base nessas perguntas, podemos observar então, que devemos preparar nossos programas para tratar parametros, inputs, etc, jamais acreditando que eles vão sempre ser passados, e além disso, vão estar no formato correto.

Enjoy.

Técnicas de programação defensiva II

Continuando os posts sobre programação defensiva, vamos a segunda técnica:

Nunca programe com pressa

Essa realmente é difícil de fazer! Ainda mais nos dias de hoje com a pressão para entregar resultados num curto espaço de tempo… Mas enfim, temos que tentar programar com a maior calma possível.

Devemos pensar linha por linha do nosso código, e NUNCA focar somente no total contexto de nossa aplicação. Se ficarmos somente “mirando” no resultado, podemos criar uma linha que vai quebrar toda nossa aplicação, então pense em TODAS AS POSSIBILIDADES de uma única linha de código. Por exemplo, o que vai acontecer se você deixar passar uma linha como essa:

If (variable.equals(“mandioca”){…..;}

Já pensou se a variável for nula? Seu código quebrou!!!

Então, pense linha por linha e espere sempre o pior, não suponha que a variável vai ter sempre um valor.

A pressa também nos faz deixar coisas pendentes no código, coisas do tipo: “Implementar teste”, “Testar se o contador está sendo iniciado”, “Trocar a list por map”, etc.

Se você deixa algo por fazer, tem grande chance de esquecer, ou mesmo que não esqueça, quando voltar para fazer vai perder um grande tempo para se lembrar do contexto do que estava fazendo.

Moral da história: mantenha a calma.

Técnicas de programação defensiva I

Continuando os posts sobre programação defensiva, vou falar neste post e em próximos posts sobre técnicas de programação defensiva. Para dar início vamos a primeira técnica:

Empregue sempre um estilo de codificação

Primeiro: O que é um estilo de codificação? Podemos resumir a ópera dizendo que um estilo de programação é a forma como a qual você escreve seu código fonte, por exemplo quantos espaços você dá para começar a escrever o código e quantos espaços você dá quando está dentro de um loop, ou seja, edentação. Outros exemplos podem ser nomenclatura de variáveis, de métodos, classes, comentários, etc.

É importante que você tenha um estilo e o siga em TODOS seus programas, mais importante ainda é que sua equipe siga o mesmo estilo. Quando você inicia em um projeto, a primeira pergunta para o líder do mesmo deve ser: nós temos algum documento com nosso estilo de programação? Se a resposta for sim, você DEVE seguir o mesmo. Se o projeto não tiver um documento com a especificação de estilo, crie um e o siga, proponha para o time que o siga.

Por que ter um estilo?

Imagine que você trabalhe em uma equipe de N desenvolvedores e cada um programa de uma forma. Não vai ser muito mais complicado entender o código fonte de uma pessoa que não segue padrão algum? Você não ganharia tempo lendo um código bem edentado, comentado, com nomes padronizados e dessa forma não conseguiria produzir um código melhor? É possível enumerar outros benefícios, mas pelo menos no meu ponto de vista, esse é o maior benefício: o ganho na facilidade em entender um código fonte alheio ou até mesmo um código fonte que nós mesmos produzimos a muito tempo.

Para finalizar, um pequeno exemplo de estilo pode ser:

Todo if, else, for, etc, deve ter um ‘{‘ e ‘}’ correspondente abaixo das instruções tal como no modelo abaixo:

if (msg == null)
{
msg = “TEST”;

}

Enjoy!

Como produzir um bom código fonte?

Continuando os posts sobre programação defensiva, uma das primeiras coisas que temos que ter na cabeça é: enquanto programadores, NUNCA devemos presumir que algo sempre vai acontecer. NUNCA faça suposições.

SEMPRE devemos esperar o pior e estar preparados para o pior. É fato que muitos programas apresentam problemas pois os programadores assumiram coisas erradas.

Exemplos de coisas que os programadores assumem que são erros podem ser:

• A função que estou chamando vai sempre retornar um valor não nulo.
• Quando chamarem minha função vão sempre passar parâmetros válidos.
• O usuário vai sempre completar o formulário.
• O usuário nunca vai digitar tipos de dados inválidos, por exemplo, vírgula num campo data.
• etc…

Então, programador, tenha em mente: não vivemos em um mundo perfeito e nunca sabemos o que nosso programa vai sofrer, então, dica número 1: nunca assuma que determinadas condições irão sempre acontecer.

Sobre Defensive Programming

Atualmente escutamos muitas pessoas falando da tal de programação defensiva, ou defensive programming. Basicamente, programação defensiva nada mais é do que você programar pensando em todas as possibilidades que podem afetar seu programa, dessa forma, cuidadosamente PENSAR antes de codificar e estabelecer TODAS as situações que poderão ocorrer no seu código, antes de colocar as mãos na massa.

Normalmente quando as pessoas tem algo a ser desenvolvido, elas já abrem a IDE e saem programando, seguindo o seguinte fluxo:

O correto, seria pensar e depois programar, dessa forma, o fluxo seria:

Pense mais antes de programar e tenha melhores resultados!!!

Tenha em mente que Programação Defensiva não corrige problemas em um software já existente, mas sim, ajuda a evitar problemas nos seus próximos códigos.

Recomendo para os interessados em melhorar suas técnicas de programação o livro “Code Craft: The Practice of Writing Excellent Code”, do autor Pete Goodliffe. As figuras acima foram retiradas desse livro.

Nos próximos tópicos irei falar sobre as técnicas de programação defensiva.

Vamos melhorar nosso código fonte junto!

Boas práticas para o WebSphere

Encontrei um documento muito bom com uma lista de boas práticas para serem implementadas em aplicações que utilizam WebSphere Application server.

É interessante notar que boa parte delas podem ser implementadas em outros servidores de aplicação.

Baixe aqui: http://www-01.ibm.com/software/webservers/appserv/ws_bestpractices.pdf

Enjoy!