Programação (I) - Planejamento e Otimização

Este é o primeiro de uma série de artigos sobre programação. Não se trata de um manual e nem de conhecimento sobre uma linguagem específica. São tópicos que podem contribuir para uma melhor qualidade dos programas, de uma forma geral. Espero que a série venha a ajudar de alguma forma, em especial aos novatos na área.

[ Hits: 26.185 ]

Por: Edvaldo Silva de Almeida Júnior em 11/04/2008 | Blog: http://emeraldframework.net


Planeje seu programa pensando em várias coisas



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.

Página anterior     Próxima página

Páginas do artigo
   1. O porquê desta série de artigos
   2. A importância do planejamento
   3. Saiba onde quer chegar
   4. Faça uma especificação do seu programa
   5. Planeje seu programa pensando em várias coisas
   6. Pesquise sempre a melhor forma de fazer
Outros artigos deste autor

Como a Tecnologia pode ajudar a Democracia?

O "Linux Tinha Chapéu"

Livre não precisa ser gratuito

Instalando Slackware "na marra"

Programação (II) - Modularização

Leitura recomendada

Relato: Instalação mista dos sistemas Linux, MacOS e Windows na mesma rede

Como fazer o seu servidor Linux enviar avisos em seu celular Claro sem custo

Servidor de Icq em uma rede local

Sabayon 5.0 - Uma nova distro multimídia (parte 1)

LPIC-1 - Guia de Estudos

  
Comentários
[1] Comentário enviado por eversonamancio em 11/04/2008 - 10:36h

Edvaldo,

Seu artigo está ótimo.

Pretendo ingressar nessa área, e essas informações me foram preciosas.

[2] Comentário enviado por kabalido em 11/04/2008 - 11:20h

Muito bom cara. Parabéns;

[3] Comentário enviado por foguinho.peruca em 11/04/2008 - 14:24h

Olá!

Mto bom artigo. aborda aspectos importantissimos na área de engª de sw...

[4] Comentário enviado por ssdeassis em 11/04/2008 - 17:05h

muito bom artigo, vou ler todos os outros da continuação

[5] Comentário enviado por elionw3 em 11/04/2008 - 17:58h

Otimo, em 15 minutos de leitura conseguiste resumir o q os professores tentam nos ensinar por 5 anos na facul, heehauhuh

principalmente em "Engenharia de Software", o problema é q pelo fato de ser uma materia muito teorica o pessoal não da credito, e depois acaba "se quebrando" pra consertar os furos, q poderiam ser evitados no Planejamento :)

Cumprimentos,
e...
quando sai "Programacao (II)" ?

[]'s

[6] Comentário enviado por raci0nal em 14/04/2008 - 00:28h

Muito bom o artigo e aliás muito bem estruturado.
Só queria deixar registrado, que por causa de vários problemas citados no artigo é que surgiram outras metodologias de desenvolvimento, como XP e SCRUM por exemplo, conhecidas como metodologias ágeis.
Um contato direto com o cliente, mostrando os resultados gradativos, torna a resolução de problemas muito mais rápida e menos "dolorosa".
Como no primeiro caso que você citou, onde após 2 meses apresentaram o projeto e estava tudo errado, se na primeira semana fosse apresentado algum material para o cliente, este poderia detectar diferenças de pensamento no ato, poupando muito tempo (e tempo = dinheiro).
O modelo abordado no artigo, que é conhecido como waterfall (em cascata) tem suas vantagens, mas fazer todo o planejamento antes de iniciar com a mão na massa também acarreta vários problemas, afinal quase todos (para não dizer todos) os projetos estão sujeitos a mudança de escopo no decorrer da implementação ou em um tempo muito curto após ela.

Bom, finalizando gostaria de salientar que não é uma crítica, apenas queria mostrar que existem outras possibilidades nas metodologias de desenvolvimento.

Abraços,

Marcos Antonio Campos Jordão''

[7] Comentário enviado por agk em 14/04/2008 - 16:41h

Muito bom, gostei das explicações, parabéns pelo artigo.

Meu byte de contribuição: no teu shell script pode utilizar o time, fica mais fácil para saber os tempos de execução de cada script.

man time

[ ]'s.

[8] Comentário enviado por EdDeAlmeida em 15/04/2008 - 14:33h

Obrigado pelos comentários! Programação II sai em breve, estou dando meus últimos retoques. Valeu pela dica, agk. Eu já usei o time, mas não sei porque resolvi usar esse método do script. Com certeza o time é mais eficiente.

[9] Comentário enviado por marcio_paim em 14/02/2012 - 20:49h

Muito bom! Acho que a maioria do pessoal que está começando não nota a importância das dicas por que ainda não se deparou com o desenvolvimento de um software cujo tamanho mostre que elas são realmente úteis.

[10] Comentário enviado por MrCrawl3r em 02/05/2016 - 20:26h

Excelente!

Parabéns pelo artigo que já tem um bom tempo e mesmo assim continua ajudando iniciantes como eu rs.

--------------------------------------------------
Att,
Mr Crawler.

O mundo depende dos computadores. Tenha total domínio sobre os computadores e domine o mundo!


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner
Linux banner
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts