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.
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
[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)" ?
[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.
[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.