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: 27.689 ]

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


Saiba onde quer chegar



Antes de iniciar um programa qualquer certifique-se de que sabe o que se espera desse programa.

Pode parecer absurdo dizer isso, mas tenho visto muita gente codificando sem ter uma ideia clara de onde quer chegar. E sem saber onde se quer chegar, fica muito difícil chegar lá, não é mesmo?

Uma das minhas experiência mais deprimentes como programador ocorreu em 1991. Nesta época eu trabalhava para uma empresa de desenvolvimento de software e birô de serviços.

Recebemos a encomenda de um software para gerenciamento de hotel, para o que era na época um dos maiores (se não o maior) hotel de Natal, no Rio Grande do Norte.

A nossa equipe tinha seis pessoas, sendo dois analistas e quatro programadores. Todo o software seria desenvolvido em COBOL para IBM/PC (não como os PCs de hoje, mas computadores de oito bits com processador 8088 e clock de 10 Megahertz... não riam, pois para nós essas máquinas eram top de linha!).

Sentamos e discutimos entre nós como deveria ser o gerenciamento de um hotel. Nós nos julgávamos pessoas inteligentes e pensávamos que poderíamos imaginar como um hotel funcionava tão bem quanto as pessoas do hotel. Que grande engano!

O resultado foi que quando fizemos a primeira apresentação do software para o cliente, depois de dois árduos meses de trabalho, ele olhou para nós e disse: "Tá tudo muito bonito, mas não tem nada a ver com o que nós fazemos lá no hotel..."

Foi uma decepção geral, pois nós achávamos nossas idéias muito boas. E eram, de fato. Só que não eram o que o cliente queria.

Aqui vai uma regra de ouro para quem quer desenvolver software, em especial software comercial: SEU PROGRAMA NÃO É PARA VOCÊ, MAS SIM PARA O SEU CLIENTE. É por isso que é ele quem deve especificar o que o programa faz no início e ficar satisfeito no final. Até porque se ele não ficar satisfeito, não vai te pagar...

Assim, não pense que sabe de tudo! Houve uma época em que eu já pensei isso, mas hoje sei que não era verdade naquela época e nem é verdade agora, como não será em vinte anos (se eu ainda estiver vivo até lá, é claro...). Converse com os usuários do software e descubra o que eles realmente desejam

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

O "Linux Tinha Chapéu"

Instalando o Fedora Core 5 via NFS

Programação (III) - Programação Orientada a Objetos (POO)

Instalando Slackware "na marra"

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

Leitura recomendada

Traduzindo mensagens no Linux

Configurando o Stardict com dicionário do Babylon

ArchLinux, uma distro de expressão aqui no VOL

MP3 no Linux

Dúvidas iniciais para começar Open Hardware de mouse + GUI

  
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 removido 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

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts