Faça uma especificação completa e detalhada do seu programa antes de começar a codificar. Isso pode parecer tedioso quando comparado à emoção de ficar horas na frente do computador digitando como um lunático, mas vai ajudar em vários aspectos.

Antigamente tínhamos as especificações funcionais escritas, ou seja, um grosso calhamaço de papel que resultava das entrevistas de análise e que ninguém lia mesmo e ia fazendo as coisas como dava na telha.

Tínhamos também os algoritmos, que ainda são bastante úteis para especificar pequenos trechos de código.

Mas se você quer realmente fazer uma especificação boa e prática para seus programas, sugiro que estude UML. Com UML você pode criar uma especificação totalmente visual para o seu programa, que será muito mais fácil de consultar do que as antigas especificações escritas. Afinal, uma imagem vale por mil palavras, como já foi dito.

Há várias razões para especificar um sistema detalhadamente:

a) Com uma boa especificação você não fica perdido, não fica em dúvida e nem tem de consultar o cliente repetidas vezes durante o processo de desenvolvimentos e teste;

b) Com uma boa especificação você sempre sabe onde chegar e como chegar lá;

c) Com uma boa especificação você tem um mecanismo para avaliar prazos e custos. Algumas métricas como a dos Pontos de Função baseiam-se na especificação do sistema;

d) Com uma boa especificação você terá uma excelente ferramenta para a manutenção futura, como veremos adiante;

e) Com uma boa especificação você tem um mecanismo para se proteger daquele cliente que, depois de combinar com você o preço do programa e o prazo de entrega, fica pedindo para acrescentar uma coisinha aqui e outra ali no sistema. Esse tipo de cliente quer sempre mais, mas quando você fala em extensão do prazo ou em aumento dos custos ele reclama, dizendo que só pediu umas besteirinhas... Prepare a especificação e mostre ao cliente, fazendo com que ele concorde em ater-se a ela e deixando claro que o software será entregue daquele jeito e que se alguma necessidade nova surgir será implementada na versão seguinte. Sugiro que bote isso no papel, mediante um contrato formal. Os clientes sempre dão um jeito de bagunçar tudo, se deixarmos.

Na fase inicial da análise, aquela de conversar com os interessados no programa para saber o que eles desejam, dê especial atenção aos DIAGRAMAS DE CASOS DE USO. São uns diagramas UML bonitinhos, com uma porção de bonequinhos para lá e para cá, representando as formas de interação dos usuários com o seu programa. Podem parecer meio infantis no princípio, mas serão um grande apoio durante o processo de desenvolvimento.

Mais adiante, concentre-se no DIAGRAMA DE CLASSES se estiver pensando em Programação Orientada a Objetos (POO) ou no DIAGRAMA DE FLUXO DE DADOS e DIAGRAMA DE ENTIDADES/RELACIONAMENTOS se estiver usando Programação Estruturada.