Skip links

Programação eficiente: Não queime a largada

Você recebeu uma nova tarefa de desenvolvimento. Qual a primeira coisa a se fazer? Você começa a programar, certo? Errado. Você vai escrever o que se nem sabe o que precisa fazer?

Entenda o problema

Inúmeras vezes eu vejo colegas de desenvolvimento (ou mesmo alunos na faculdade) pegarem um problema/tarefa, mal terminarem de ler, e já começarem a programar. Como espera resolver um problema se não entendeu ele?

Leia com atenção, pense, questione

Seja simples ou complexa, nenhuma tarefa merece ser rejeitada e deixada sem ser lida cuidadosamente. Algumas tarefas que possam parecer simples à primeira vista, podem-se mostrar bem mais trabalhosas ou problemáticas. Entenda a tarefa, pense nas consequências das suas alterações e não avance no desenvolvimento sem antes fazer uma série de perguntas a si mesmo, como “O que eu preciso para concluir a tarefa?”, “Minha solução pode trazer consequências em segurança ou desempenho?”, “Quais são os fluxos alternativos (exceções) que podem acontecer?”, dentre tantas outras perguntas plausíveis para o problema.

Após analisar cuidadosamente a tarefa, alguma dúvida surgiu? Questione seu analista, scrum master ou mesmo cliente até que não haja nenhum ponto em aberto. Seja chato, mas tenha certeza de que você tenha todas as informações pertinentes para realizar sua atividade. Obviamente novas dúvidas podem surgir durante o desenvolvimento, mas você já vai ter adiantado a maioria delas antes mesmo de escrever uma linha sequer de código.

Não abandone as exceções


Se alguma coisa pode dar errado, dará. E mais, dará errado da pior maneira, no pior momento e de modo que cause o maior dano possível.

Lei de Murphy

Sabe aquele caso específico que você pensa enquanto estava escrevendo o código, mas acredita que ele nunca irá acontecer? Se tem algo que aprendi durante minha vida como desenvolvedor foi que sim, um dia irá acontecer. Não importa o quão específico ele é; se há possibilidade de acontecer, então irá se concretizar.

Lembro agora de uma tarefa que tive no passado, que envolvia conferência de itens de notas fiscais recebidas após envio do pedido ao ERP. A validação que tinha que fazer era relacionado à falta de algum item, possivelmente por falta de estoque, e precisava tomar algumas providências quando isso acontecia. Ao escrever o código, me deparei exatamente com o caso oposto. E se eu mandar quantidade 1 e me retornarem quantidade 2? Na hora pensei que não haveria como esse cenário acontecer mas, mesmo assim, resolvi fazer uma ajuste simples para que alguém pudesse detectar essa falha (até porque não fazia sentido despender muito tempo em algo que não deveria acontecer) . E não é que mais de 1 ano depois, esse cenário realmente aconteceu? E não foi um caso isolado, mas diversos de uma só vez!

Planeje seu trabalho

Atividades pequenas podem até não demandar muito tempo de análise, mas não caia na ilusão de que não precisa planejar o que e como irá resolver seu problema. Planejamento é extremamente importante e a falta dele é possivelmente um dos erros mais comuns, especialmente quando se está começando na programação. Veja sua atividade em uma perspectiva alto nível (big picture), tendo o entendimento de quais tarefas são necessárias e uma ideia de como irá desenvolvê-las.

Quando você vai falar alguma coisa, você precisa pensar nisso antes, certo? [espero que sua resposta seja sim]. Para não falar o que não devíamos ou nos arrependermos das palavras que saem da nossa boca, costumamos parar e pensar sobre o que iremos falar. Na programação não é muito diferente; pense antes de fazer besteira no código e ter vergonha do que acabastes de escrever.

Não planeje demais

Sim, planejar antes de escrever código é imprescindível, mas planejar demais também pode vir a ser. Não procure a solução perfeita para o seu problema; até porque provavelmente ela nem exista. Encontre um plano bom o suficiente para iniciar e comece a lapidar ele enquanto desenvolve.

Desenvolver envolve aprender a se adaptar rapidamente à mudanças; uma tarefa que você estava desenvolvendo pode acabar nem sendo mais útil, seja porque você evoluiu sua solução, ou por mudança de alguma regra de negócio. Sem contar que novas tarefas podem, e vão surgir enquanto sua atividade ainda está em desenvolvimento. Portanto, planejar demais é perda de tempo.

Mas quanto tempo eu devo planejar? A resposta é: depende de cada tarefa. Acredito que após o entendimento do problema, planejamento de dados/estruturas de dados a serem usadas, e uma visão geral do que precisa ser desenvolvido, já seja o suficiente. Você tem um plano traçado, e já pode ir desenvolvendo as tarefas a partir desse plano.

Pense para programar e não pare para pensar

Enquanto que pensar antes de iniciar seu desenvolvimento seja importante, parar no meio do desenvolvimento para pensar pode significar que algo esteja errado. Normalmente, se você precisa parar durante o desenvolvimento, é porque alguma coisa não ficou clara e precisa rever e voltar à fase do planejamento. Ou mesmo tenha parado para pensar no email, no skype, whatsapp ou qualquer outra distração. Toda vez que você para de desenvolver, precisa mentalmente rever o que fez e o que deve ser feito.

Inúmeras vezes preciso ignorar o skype, finalizar meu raciocínio e terminar uma tarefa/lógica. Ou mesmo fazer sinal para o colega ao lado que está me chamando para aguardar um minuto. Programação exige concentração, exige construir mentalmente fluxos, interações e ligações que, em um segundo de distração podem simplesmente desaparecer [como bem exemplifica a imagem abaixo].

Programação não é somente escrever código

Ser um programador não é passar o dia inteiro escrevendo código, como muitas pessoas podem achar. O tempo que passo realmente escrevendo código é muito menor do que o tempo necessário planejando a solução, testando, e depurando código. Programação exige criatividade lógica que precisa ser constantemente aperfeiçoada, seja através de prática, aprendizado de técnicas, ou mesmo leituras de outros códigos.

Concluindo

Este post me lembra de duas frases que meu pai sempre dizia quando era criança: “Apressado come cru” e “boi lerdo toma água suja”. Ou seja, não esqueça de dedicar tempo para planejar seu trabalho, mas não deixe o tempo passar e o planejamento acabar matando seu tempo.

Leave a comment

Name*

Website

Comment