O uso racional de recursos só é possível se você conhece bem o sistema para o qual está programando. Conhecer bem o sistema não quer dizer que você precise entrar nos detalhes do kernel. Basta, para isso, entender quais são os recursos que estão disponíveis e como fazer para gerenciá-los.

O uso de recursos em computação exige mais do que o simples conhecimento da plataforma. Também exige conhecimentos específicos como algoritmos e estruturas de dados. Os algoritmos são essenciais para minimizar o uso de processamento e as estruturas de dados são essenciais para descrever a informação de maneira mínima e racional.

Eu sempre bato nesta mesma tecla: algoritmos e estruturas de dados. Os estudantes de computação são levados a crer que é importante conhecer uma linguagem de programação em detrimento do conhecimento de algoritmos e estruturas de dados. Infelizmente, não poderiam estar mais enganados. Sem o bom conhecimento de algoritmos e estruturas de dados o resultado sempre é um programa excessivo: excesso de consumo de recursos, excesso de código desnecessário, etc.

Sou de opinião que a programação deve sempre orientar-se ao uso racional de recursos, ou seja, nunca partir da suposição que os recursos necessários estarão sempre disponíveis. Essa forma de pensar leva ao desenvolvimento de aplicações eficientes. Não basta apenas ser bonitinha: a aplicação precisa, também, ser rápida e responder prontamente ao usuário. Quanto mais uma aplicação demora, menor será a possibilidade de permanecer em uso. Afinal, o principal motivo das aplicações existirem são os usuários.

Não é incomum ver código de produção que quando compilado apresenta uma quantidade enorme de advertências geradas pelo compilador.  Normalmente este é  primeiro teste que executo quando estou avaliando a qualidade de um código: a quantidade de advertências que este gera ao ser compilado. Advertências deixadas para trás denotam duas coisas: negligência por parte do programador e baixa qualidade do código final.

As advertências existem para demonstrar que há pontos de problemas potenciais no seu código. Estes problemas não são suficientemente graves para impedir a geração do código executável, mas são problemas ainda assim. O fato do executável final ser gerado não significa que ele presta. As advertências são um aviso sobre a má qualidade do executável final.

O código precisa compilar sem nenhuma advertência. Ponto final. O programador que deixa advertências no código que escreve é negligente. Os problemas estão lá. E vão acontecer quando forem para a produção. O primeiro teste que precisa ser feito é a compilação do código. Código com advertências não pode, jamais, ir para a produção. Nunca!

Até hoje não entendo por que os programadores, principalmente os mais inexperientes, ignoram as advertências acreditando que seu código é livre de suspeitas. A advertência, em si, já é um indício de que algo não vai bem.

A palavra de ordem é objetividade. O grande desafio de qualquer programador é escrever código que seja objetivo, ou seja, a menor quantidade de código possível que resolva um problema proposto. Sem frescura, sem invenção de moda, sem a preocupação de demonstrar conhecimento. Curto e grosso. No entanto, não é sempre assim na área de computação. É comum encontrar engenharia de foguete onde deveria ter, no máximo, uma casinha de sapé.

Design Pattern à força

Há programadores que querem usar design patterns de qualquer maneira em seus códigos. É bonito, é elegante, mas em grande parte do tempo desnecessário. Você deve usar design patterns onde eles são necessários e não por que você os conhece. Infelizmente há programadores que forçam o uso de design patterns para a resolução de problemas de programação. O efeito colateral é código complexo, altos footprint e consumo de recursos.

O resultado é apenas um: código desnecessariamente complexo, de difícil manutenção e com problemas que não acabam mais. Não é incomum ver software coberto de defeitos sem fim que nunca são totalmente consertados.

Desenhe antes de programar!

Gaste todo o tempo do mundo desenhando e planejando o que você vai fazer antes de sair programando como um animal de carga que não olha para os lados. É possível fazer desenvolvimento e design incrementais, mas isso exige muita disciplina. Desenhe antes! Faça esquemas, use papel, lápis, caneta, faça disso uma arte. Não comece a programar a menos que você já tenha estruturado tudo o que você vai fazer antes.

A falta de desenho antes de iniciar a programação leva a código confuso, principalmente para programadores sem muita experiência. Código sem desenho é altamente acoplado, com falhas de encapsulamento e com problemas tais que chegam a ser gritantes. Desenhe antes, programe depois. E entenda que mesmo depois de haver desenhado o que você vai fazer, você precisará ajustar seu desenho durante a escrita do código. É um trabalho interativo.

Leia e pesquise

Pesquise sobre a linguagem e o ambiente que você vai utilizar antes de sair programando. Por que isso? Para evitar quer você saia escrevendo código que já existe. Não acredite e não seja pretensioso de achar que seu código é melhor do que o código de um SDK ou biblioteca. O seu código nunca foi testado pois você o está escrevendo agora. O código do SDK ou biblioteca já foi muito testado, consertado, alterado e evoluído. Programe com humildade.

Replicar em código o que já existe é comum de quem sai programando com viseira, sem olhar para os lados, preocupado apenas com o prazo final. Sim, o prazo de entrega é importante. Mas é importante, também, que o software chegue lá funcionando. Não adianta nada atingir um prazo final com um software cheio de problemas. Isso irá te ocupar desnecessariamente e consumirá os recursos do projeto a ponto de levá-lo ao prejuízo. Dependendo do tamanho do prejuízo seu emprego estará em xeque.