Muita gente pensa que projetar um bom programa consiste apenas em planejar como ele vai se comportar, como ele vai funcionar. A dura realidade, porém, é que se deve levar em conta muitos outros fatores:

a) Seu programa será fácil de manter?

O trabalho de desenvolvimento é só um pedaço da tarefa. Para que um programa tenha um longo ciclo de vida e se torne economicamente interessante para os seus clientes, é necessário que ele seja de fácil manutenção.

Para isso é necessário que haja uma boa especificação, uma boa documentação e uma boa organização.

Sobre a especificação nós já falamos bastante.

Quando falo em documentação, refiro-me à documentação externa, que consiste nos documentos de especificação; nas anotações feitas durante o desenvolvimento; e em um bom ChangeLog, que é um arquivo onde são anatadas as alterações efetuadas, quando, como porque e por quem.

Refiro-me também à documentação interna, ou seja, nos comentários colocados diretamente junto ao código. Quem trabalha em Java, por exemplo, conta com uma poderosa ferramenta para fazer isso que é o JavaDoc. E o Linux conta com uma ferramenta muito boa chamada doxygen. Sugiro a todos que aprendam a usar bem essas coisas. Creio que elas serão tema de um dos artigos que darão continuidade a essa série.

Finalmente, a organização abrange coisas como a nomenclatura dos fontes, a estrutura de diretórios onde eles são colocados e até a velha indentação do código, que é o (bom) hábito de colocar as linhas dentro de uma estrutura hierárquica de blocos dentro do programa.

b) Seu programa será flexível?

A boa estruturação de um programa deve permitir que ele seja alterado sem que haja necessidade de um esforço sobrehumano para isso.

Um dos segredos para a isso é a modularização, ou seja, quebrar o programa em pequenas partes bem específicas (módulos), de modo que esses módulos possam ser substituídos por outros similares sem impacto no funcionamento ou na performance do programa como um todo.

Para ter um bom exemplo de modularização basta pensar no kernel do Linux (que segundo Linus Torvalds é tão bom que faz loopings infinitos em 5 segundos...). Quando você usa o modprobe ou o insmod, está acrescentando funcionalidades ao seu kernel que foram compiladas separadamente, como módulos, para maior flexibilidade.

Para projetar bons módulos é necessário estar atento a algumas coisas: o PRINCÍPIO DA CAIXA PRETA, o ACOPLAMENTO, a COESÃO, o FAN-IN e o FAN-OUT. Esses critérios serão o tema do próximo artigo, que vai tratar de Modularização.

c) Como seu programa vai se comportar quando não funcionar?

Será que seu programa vai ter mensagens inteligentes e úteis nas situações de erro? Ou irá apenas travar ou finalizar?

Um das coisas que irritavam muito os usuários das antigas versões do Microsoft Windows (entre eles este que vos escreve) eram as parcas e porcas mensagens de erro. Você estava lá trabalhando e de repente aparecia uma janela cinza dizendo: GENERAL FAILURE ERROR, e aí tudo travava e você tinha de reiniciar, xingando com todos os palavrões possíveis a pobre da progenitora do Bill Gates. Hoje temos de admitir que com o XP as coisas melhoraram muito. Não usei o Vista ainda, portanto não posso declarar nada sobre ele.

Sempre que aparecia esse GENERAL FAILURE ERROR eu pulava da cadeira e fazia continência. Fiz meu serviço militar ainda nos tempos da ditadura e naquela época quando se falava em general todo mundo morria de medo!

Deixando as brincadeiras de lado, um bom programa deve funcionar bem até quando não funcionar, ou seja, até quando encontrar situações de erro. Nesses casos ele deve ser comunicativo, explicando o erro ao usuário e oferecendo alternativas.

Essas são algumas (não todas) as coisas nas quais você deve pensar para fazer bons programas.