Assuntos importantes que não foram abordados na minha faculdade

Por mais que na faculdade de análise de sistemas se aprenda muita coisa e se tenha muitas indicações sobre quais caminhos a seguir e quais coisas são importantes, alguns assuntos não foram bem abordados e outros nem foram tocados. Só depois de ter me formado e começado a trabalhar profissionalmente na área é que vi estas deficiências. Se você está cursando uma faculdade que ainda não te ensinou isso e nem há previsão destes assuntos na grade curricular, é bom você começar a buscar informações por conta própria:

Controle de versão
Uma das piores coisas que pode acontecer é você pegar um sistema, modificá-lo, seja para criar uma nova versão, corrigir um bug ou prosseguir com o seu desenvolvimento, fazendo alguma mudança grande que não dê certo para em seguida descobrir que não lembra como estava antes. Ter um backup do código e da documentação anterior para salvar sua pele é uma das finalidades do controle de versão. Não é apenas isso, mas só este exemplo já mostra a grande importância do tema.

Mesmo com tanta importância, o assunto não foi nem mesmo citado durante as minhas aulas. Sei que existem programas que fazem este controle automaticamente, o que é uma mão na roda, mas ainda não aprendi a usá-los, o que é tema de uma série de estudos que quero começar em poucas semanas.

Atualmente, o meu Personal Versioning Controlator funciona da seguinte maneira: cada programa que eu desenvolvo tem, em sua árvore de diretórios, uma pasta chamada Versões. Sempre que eu dou uma versão do sistema como terminada, mesmo que seja uma sub-versão para correção de um bug ou para adequação às minhas convenções de desenvolvimento, eu faço uma cópia compactada de todo o código e de toda a documentação e guardo nesta pasta. O nome do arquivo compactado é o número da versão sendo guardada. Como extra, neste mesmo arquivo eu incluo observações sobre o que foi implementado a mais na versão.

***

Testes
Nós tivemos uma cadeira de testes de software na faculdade, mas foi muito superficial. Eu acho que teria sido muito mais interessante se nós tivéssemos à mão um programa já pronto e cheio de bugs e problemas para que pudéssemos testar de acordo com os métodos que estavam sendo ensinados.

Não é uma questão apenas de rodar o programa e ver se está tudo funcionando direito, mas sim de fazer testes profundos e organizados, seguindo uma metodologia específica e bem explicada.

Hoje eu já descobri que existem programas que testam programas. Ainda não aprendi a usá-los e tampouco vi a cara de algum deles, mas pretendo preencher esta lacuna assim que possível.

***

Criando instaladores
Pois bem, você cria sua bela e bem feita aplicação, faz os testes (mesmo que não de forma profissional) e vê que está tudo pronto para instalar na máquina do seu cliente ou para ser colocada à disposição para download em seu site, mas como fazer com que seu programa tenha, automaticamente, um ícone no menu Iniciar do Windows, uma sub pasta em Arquivos de Programas e apareça na lista de programas que podem ser desinstalados?

Eu também não tinha idéia de como fazer isso quando terminei a faculdade, e até mesmo um professor me deu uma dica que não é das mais bonitas. Assim como nos outros casos citados acima, descobri que existem programas que fazem isso. Um bom exemplo é a dupla gratuita Inno Setup e ISTool.

***

Padrões de acesso a dados
A maioria dos programas que fazemos tem alguma forma de acesso a bancos de dados ou arquivos, mas em momento nenhum da faculdade eu tive alguma orientação sobre qual a melhor maneira de recuperar ou gravar estes dados. Drivers ODBC? Um ou outro padrão de projeto? Nah, nem sombra de alguém comentar sobre este assunto crucial.

Com o passar do tempo fui adquirindo experiência e desenvolvendo uma solução pessoal que, mesmo sendo razoavelmente aceitável, sei não ser a melhor. Recentemente eu comprei um livro sobre o assunto que promete me ajudar bastante. Espero que a pós também dê alguma informação útil também.

***

Ajuda
Todos os programas têm um arquivo de ajuda! Desde colossos gigantescos como o Windows até programas simples como o Bloco de Notas. Mas e o seu? O que acontece quando o usuário aperta o botão F1? Se os seus programas são iguais aos primeiros que eu fiz, com certeza, nada.

Não consigo conceber uma explicação decente para o fato de um assunto tão importante não ter sido sequer mencionado durante as aulas que tive. Há poucas semanas eu descobri um ótimo programa gratuito que gera arquivos de ajuda do Windows, seja em formato CHM, HLP e até mesmo em PDF, que atende pelo singelo nome de Help Maker. Aos poucos estou aprendendo como fazer a ligação entre os arquivos de ajuda que gero e os programas que faço, de forma a exibir alguma de suas páginas quando os usuários apertam F1. Está dando trabalho, mas já é melhor que nada.

***

Diferenciação de UML e projeto orientado a objetos
Por fim, aí está uma das maiores falhas que vi na faculdade: não ensinar aos alunos a diferença entre UML e projeto orientado a objetos, fazendo com que todos os meus colegas digam que programam em UML. O pior é que este é um equívoco que não acontece apenas com eles: até mesmo uma professora da minha pós graduação tem um livro chamado Desenvolvendo Aplicações com UML!

Esta discussão é assunto extenso demais para ficar aqui neste artigo, mas vale comentar que acho triste ver tanta gente confundindo conceitos tão importantes. Craig Larman, autor do excelente livro Utilizando UML e Padrões, escreveu o artigo What UML is and isn't, que é uma ótima explicação desta diferença e merece uma lida. Como não consegui encontrar uma cópia dele na internet, vou preparar uma tradução para colocar aqui no Sarcófago.

***

Pois bem, eis aí os vacilos do meu curso de sistemas de informação. Apesar de ter sido muito bom e eu ter tido excelentes professores, ele, como tudo no mundo, não foi perfeito. Sorte que eu sei quais são as lacunas em branco e posso correr atrás para preenchê-las.

***

Leia outros artigos meus sobre análise de sistemas