Magno Machado Paulo

Quando você está codificando, quais são os fatores que você leva em consideração para decidir como implementar uma determinada situação?

Vamos clarear mais. Considere os seguintes pontos:

• Legibilidade
• Performance / Consumo de memória
• Manutenabilidade (em outras palavras: O quão fácil ou difícil será dar manutenção naquele código futuramente)
• Tempo de desenvolvimento
• Quantidade de código

Peço que quem estiver lendo este post, dê uma pausa e faça uma lista destes items partindo do que você acha mais importante até o menos importante, antes de prosseguir.

Agora vamos discutir cada um:

1. Quantidade de código
   Muitos programadores acreditam que uma solução é melhor que outra apenas por envolver menos linhas de código. Eu digo que este fator, por si só, está entre os menos importantes para mim. Pense: Que vantagens isso tras? Você paga imposto de acordo com o tamanho dos seus fontes? E de que adianta gastar menos tempo digitando o código, se toda vez que você precisar fazer alguma alteração você perder o dobro de tempo pra entender o que o código faz?
2. Tempo de desenvolvimento
   O cliente está te cobrando a cada cinco minutos, o seu prazo já estourou, e então você implementa a coisa do jeito mais rápido possível, o que quase sempre significa ignorar toda e qualquer boa-prática.

   Ok, mas saiba toda vez que você precisar dar manutenção no código, vai levar mais tempo do que levaria se tivesse gasto um pouco mais de tempo no inicio para fazer algo melhor. Então eu pergunto: Será que o lucro de hoje não se transformará em uma série de prejuízos amanhã? Não seria melhor ter um prejuízo hoje para ter uma série de lucros amanhã?

   Se situações assim são frequentes, sugiro maior atenção na hora de definir prazos. É melhor dar um prazo de 20 dias e entregar o produto em 15, do que dar um prazo de 10 dias e entregar o produto nos mesmos 15 dias. Sempre inclua nos seus prazos um tempo a mais para cobrir imprevistos.

3. Performance / Consumo de memória
   Sério, vamos deixar as previsões sobre o futuro com os místicos, ok? Não há nada pior do que o programador que fica fazendo previsões sobre se uma determinada rotina ficará muito pesada, pois é bem provável que nossos palpites não causem nenhuma melhora significativa no produto. Estamos na era dos gibabytes de memória RAM, processadores com diversos núcleos, etc, então não adianta muito gastar horas/dias otimizando rotinas para salvar alguns quilobytes ou megabytes de memória RAM, ou alguns ciclos de processamento, por que isso não fará absolutamente nenhuma diferença para o usuário final.
   Se for comprovado, na prática, que uma determinada parte do sistema está consumindo recursos de forma realmente excessiva, você deve encontrar o gargalo com a ajuda de profilers, e só então você dará um jeito de resolver o gargalo.

   Leve em consideração o Princípio de Pareto, que diz que 80% dos problemas se originam em apenas 20% das causas. Trazendo isso para o assunto em questão aqui, podemos dizer 20% do código do seu sistema é responsável por 80% do tempo de execução do mesmo. Ou seja: Por mais que você otimizar esses 80% de código restante, o ganho no final das contas será mínimo.

4. Manutenabilidade
   Pense no quão facil ou dificil será dar manutenção no código que você está escrevendo. Veja não pelo seu ponto de vista, mas no de algum outro desenvolvedor que eventualmente ficará responsavel por manter este código. De que adianta fazer algo rapidamente hoje, se você se vir no inferno cada vez que precisar alterar algo no código (e isso significa perder muito tempo)? Talvez seja necessário até mesmo refazer tudo, então teria sido melhor fazer algo bom desde o inicio.
5. Legibilidade
   Quando codificar uma rotina, imagine-se tendo que entende-la depois de um ano inteiro sem olhar para ela. Imagine outro desenvolvedor tendo que entende-la. O seu código deve ser fácil de ler nestas situações

Quando priorizamos performance, quantidade de linhas de código e tempo de desenvolvimento, a tendência é uma redução na legibilidade e na manutenabilidade. Acho que um bom profissional deve ser capaz de balancear tudo isso da melhor forma possível, mas nunca deixando de lado a preocupação com a qualidade do projeto. Muitos dizem que o cliente não vê o código fonte e que o importante é o produto funcionando. Eu não discordo, mas temos que considerar o seguinte: O produto pode estar funcionando e atendendo com maestria as necessidades do cliente, mas se o projeto não foi estruturado de uma maneira saudavel, então essa qualidade deixará de existir cedo ou tarde devido às dificuldades de manter e expandir o projeto e o produto não mais atenderá às necessidades do cliente.

Agora vos apresento a minha lista de prioridades:

1. Legibilidade
   Se o código não é legível, não poderei trabalhar com ele e entregar um produto de qualidade.
2. Manutenabilidade
   Se tenho dificuldades de manter o código já escrito, estarei sempre estourando prazos, entregando requisitos mal implementados, bugs, etc.
3. Performance
4. Tempo de desenvolvimento
5. Quantidade de código

Isso quer dizer que eu não me importo em escrever centenas ou milhares de linhas de código? De forma alguma, só quer dizer que eu não abro mão de fatores mais importantes apenas para economizar linhas de código. Mas se for possível escrever menos, sem prejudicar a legibilidade ou a manutenabilidade, é claro que eu prefiro!

Como eu disse antes, se for constatado que o sistema está consumindo muitos recursos, utilizamos um profiler para identificar o gargalo e trabalhamos para resolver este gargalo. Nesse caso, possivelmente terei que abrir mão de fatores mais importantes como a legibilidade do código pois, como eu disse antes, o que importa é ter um produto de qualidade que satisfaça ao cliente.

Filed under:
Desenvolvimento by magnomp