Dicas para programar melhor

Está começando agora a programar e não sabe como fazer? Precisa de dicas de como executar determinada função ou código e não tem onde achar? Este artigo não responde estas perguntas mas fornece várias dicas para programar melhor em qualquer linguagem.

Há muito tempo recebo mensagens de pessoas que querem começar a programar e desejam dicas de como fazer isso, seja para uma linguagem específica, seja para a área da programação.

Infelizmente não posso dar dicas para todas as linguagens pois não as conheço para escrever sobre. Entretanto, algumas por serem genéricas, podem ser fornecidas e servem como base para toda a área e não somente para esta ou aquela linguagem.  É disto que este artigo trata: dicas de como programar melhor. Vamos lá?

Aprenda com os outros
Existem programadores que não suportam imaginar sua “grande invenção” sendo copiada por outros. Para estes, é uma verdadeira heresia compartilhar o conhecimento e o código com outras pessoas. Infelizmente estes programadores estão, em sua maioria, fadados a fracasssar pois vão viver inevitavelmente em uma ilha, isolados.

O ser humano chegou em seu estágio de desenvolvimento porque compartilha seu conhecimento e descobertas. Isso acontece em todas as áreas, sejam exatas, humanas ou biológicas. Assim é um equívoco gigantesco pensar que a descoberta de uma nova estrela ou ainda de um novo remédio é um fato isolado e feito por uma pessoa. São dezenas de pessoas em dezenas de instituições diferentes que juntas fazem “o sucesso”.

A melhor forma de aprender é tomar exemplos daqueles que já fizeram. Não digo que a criatividade deve ser colocada fora da questão, pelo contrário. Bom é aquele que consegue ver algo e melhorá-lo, levando à excelência. Assim, obtenha código de terceiros e compreenda como o autor chegou em determinado resultado. Compare com o que você já sabe e peneire aquilo que é valioso para você. Muitas vezes a leitura de um código pode resultar na descoberta de uma solução totalmente diferente e que cai como uma tábua de salvação no seu problema.

Lendo o código de outros programadores também aprende-se como NÃO FAZER (inclusive acredito que é por isso que muitos não divulgam o que fazem). Falta de identação, criação sistemática de variáveis, loops infinitos e todo o tipo de aberração pode ser encontrada em códigos mal feitos. Lendo estes códigos e comparando com aquilo que já conhece, certamente poderá identificar o que é utilizável e o que é “> /dev/null”.

Pense antes de fazer
O número de programadores que começa a fazer um software pelo código é tão grande quanto a quantidade de cimento usado para construir as torres Petronas na Malásia. Seja por falta de conhecimento, seja por desespero do cliente ou empregador ou ainda por ego, eles começam a fazer uma casa pelo telhado e não pelo alicerce. Aí meu amigo, a casa cai, literalmente.

Os melhores softwares que conheço são aqueles onde o tempo “gasto” na sua idealização é muito maior que 70% do tempo total para finalizá-lo. Código, qualquer um faz, basta a leitura de um livro, dois tutoriais e um guia de referência à mão que ele sai. Agora, pensar como ele deve ser feito e como ele deve se comportar é algo que poucos fazem mas atitudes que separam o bom do mau software.

Pense no que a aplicação vai fazer. Execute testes de mesa, faça fluxogramas, pense nas tabelas do banco de dados. Considere as variáveis existentes e as não existentes e como a aplicação deve responder para cada uma delas. Imagine o que o usuário é capaz de fazer (cada coisa!) e como contornar as idéias mais mirabolantes possíveis. Levando tudo isso em consideração, seu software está sujeito a ter menos erros e não se tornar uma colcha de retalhos dentro em breve (como alguns sistemas que conhecemos).

Documente
A esmagadora maioria dos programadores não consegue criar um parágrafo de texto com nexo. Conheço vários exímios programadores que não se aventuram em escrever um livro ou um artigo sobre o que conhecem por não conseguirem ser expressar além de parênteses, colchetes e sinais de igualdade. Outros até tentam e depois que percebem o erro que fizeram, abominam a idéia e fogem dela como o diabo da cruz.

Mas feliz ou infelizmente (para você), mais cedo ou mais tarde terá que parar e escrever a documentação do que está fazendo. Ela é imprescindível não somente para aquele que paga pelo seu trabalho, mas também para que você possa, em caso de necessidades futuras, saber o que foi feito, como foi feito e onde está cada parte de seu software. É trabalhoso, é cansativo, é chato e principalmente, maçante. Mas acredite, tem que ser feito e o quanto antes. Se no meio do caminho você se perder, poderá saber onde está e para onde vai.

O método correto é começar a documentação ANTES do desenvolvimento do software. Fluxogramas, dicionários e modelos de dados são o mínimo esperado de um programador que vai começar a fazer um sistema. Se começa sem isso, já começa errado e vai certamente dar com os burros n’água logo adiante.

Arme-se com ferramentas produtivas
Em minha última viagem comprei um daqueles afamados canivetes suíços. Uma ferramenta que acho imprescindível em todos os sentidos. Mas ao contrário do que pode pensar, não comprei um “turbo canivete” com mais de cem funções. Comprei um que possui somente aquilo que preciso, ou seja, duas lâminas de corte, uma tesoura, uma pinça, um alicate e uma chave com pontas intercambiáveis que retira qualquer parafuso dos computadores e notebooks atuais, inclusive aqueles com cabeças em estrela usados em disco rígidos. Poderia comprar um super canivete? Sim, mas para quê? Carregar peso desnecessário, pagar mais caro e nunca usar a maioria de suas funções?

Na programação acontece a mesma coisa. Existem ferramentas e “ferramentas” para tudo. Editores de código, gerenciadores de bancos de dados, documentadores e assim por diante. Uns melhores que os outros, sejam em recursos, em funcionalidades e também em preços.

Um bom editor que faça highlight de código, uma identação decente e que forneça acesso rápido à sintaxe das linguagens que usa é extremamente útil e produtivo. Da mesma forma, gerenciadores de bancos de dados são extremamente importantes a fim que possa executar comandos diretamente no mesmo para comparar os valores com o que obtém no código e também, vez em quando, alterar suas propriedades.

Fuja de ferramentas com muitos recursos ou “gordas”. A maioria destes recursos você nunca irá usar e se tornarão um peso em sua máquina, além de deixá-lo frustrado por não saber usar tudo o que existe. Prefira uma ferramenta que faz efetivamente o que deseja e que você se sinta confortável com ela. É muito melhor saber usar completamente uma ferramenta mais simples do que não saber usar uma com todos os recursos possíveis e imagináveis.

Não teste, peça para outros testarem
Tudo o que fazemos repetitivamente torna-se mecânico e não percebemos. Exemplos são: dirigir, andar de bicicleta e respirar (ou você pensa para respirar?). Com o teste de software acontece a mesma coisa. Estamos tão inseridos em seu desenvolvimento e conhecemos todas as vírgulas que elas se tornam um problema para o programador que, na hora dos testes, passa por cima de pequenos erros sem perceber e libera uma versão “bugada”, ou ainda perde horas para descobrir que falta um ponto dentro de uma operação matemática.

Sempre peça para terceiros testar o que está fazendo e, preferencialmente, que seja um futuro usuário do software. Como ele não está inserido no processo de desenvolvimento e na maioria das vezes pouco conhece de programação, poderá encontrar erros que você simplesmente não percebeu, seja uma imagem deslocada, um pixel a mais numa área da tela ou ainda uma mensagem sem motivo de lá estar (principalmente quando é um palavrão). Fazendo isso, as chances de erros é muito menor (por isso existem beta testes).

Páre e descanse
A programação de software é uma área extenuante. Horas e horas diante de uma tela sentado em cadeiras que não atendem em absoluto a ergonomia de seu corpo. Muitos programadores passam o dia inteiro assim e a grande maioria reclama, depois de alguns anos, que não aguenta mais, seja pela pressão de fazer mais em menos tempo, sejam pelos olhos cansados ou pelas dores nos pulsos.

Se você entrar na onda do “estouro de boiada” e passar dez, doze, quatorze horas diárias sem pausas diante de um código, terá, além dos problemas já citados, um outro comum: lapso de memória. É comum quando estamos em uma situação de estresse psicológico sermos “desligados”. Isso não é seu ou meu, mas sim da genética do corpo humano. Ele se “desliga” para isolar-se de situações que possam causar risco à sua sobrevivência. Exemplos são as pessoas que desmaim diante de um estresse grande como um seqüestro ou ainda a perda de um ente querido. E não adianta ir contra isso, se forçar, vai ter um reboot em breve (só espero que não seja um shutdown!).

Sempre faça pausas durante o trabalho. Levante-se, vá até o bebedouro (ou geladeira), beba água, caminhe, converse com alguém. Claro que não é para fazer isso a cada meia hora e tampouco pausas de duas horas. Mas sempre dê tempo ao tempo e principalmente à você. Use esta dica com regularidade para manter seu corpo e suas faculdades mentais em dia. E por favor, jogue no lixo aquelas bolinhas ridículas usadas para massagear as mãos. Elas servem somente como desculpa para que fique sentado com seu traseiro na cadeira e produza o máximo possível. Lembre-se, produção não é volume, é qualidade.

Não se prostitua
Claro que não estou falando de favores sexuais em troca de qualquer coisa. Não é nada disso. Estou dizendo que você não deve se vender por qualquer coisa, para qualquer um. Infelizmente um dos maiores problemas da área de programação é o ato da prostituição laboral onde o programador, por motivos mil, vende seu trabalho a qualquer preço, fazendo com que ele mesmo toda a categoria seja prejudicada.

Você pode advogar que a vida está difícil ou que precisa comer. Claro que sim, todos precisamos. Mas será que precisa ser tão barato? Muitas vezes os programadores são comparados com pessoas que estão começando na profissão mas levando em conta somente a parte financeira, ou seja, o valor de A é muito menor que B, não mensurando a experiência daquele que está há anos fazendo software.

Seja honesto consigo mesmo. Se você é um iniciante na programação, cobre o que é correto pela sua experiência. Entretanto se você é um “macaco velho”, não se sujeite aos ditames pré-existentes. Na maioria das vezes isso é ruim para você, ruim para o contratante e ruim para todos nós. Acredite, ainda existem contratantes que sabem o quanto vale um bom programador. Se ele te oferece pouco, certamente é porque seu trabalho para ele vale pouco. Se vale pouco, para que ser escravizado?

A melhor forma de escapar desta armadilha é o planejamento. Muitas vezes somos obrigados a aceitar qualquer coisa que colocam em nossa frente porque não temos um planejamento financeiro adequado e nos vemos numa situação que é pegar ou largar. Não vou aqui ensinar regras de economia pessoal para você mas acredito que seria muito bom ler alguma coisa sobre o assunto e praticar. Com isso não precisa passar por apertos e pode ser valorizado como deve realmente.

Finalmente, como última dica; Seja humilde
Ninguém sabe tudo! Quando você toma uma postura como esta, mantém os braços abertos para receber novas informações e aprender mais, principalmente com aqueles que sabem algo diferente de você. Isso inclusive deve ser usado não somente relacionado com a metodologia ou linguagem que usa, mas sim em toda a área da programação. Muitas vezes você pode ter a solução de um problema baseando-se no conhecimento de outra pessoa que programa em linguagem diferente da sua ou que usa métodos diferentes dos seus.

Obs: agradecimentos ao leitor Luiz Pedro Jr. pela pergunta que resultou neste artigo.