menu

Os programadores não desenvolvem apenas software, eles contribuem para a comunidade. Se estás a ler este artigo, é provável que queiras encontrar um emprego num ambiente profissional onde possas partilhar o teu conhecimento e experiência com outras pessoas. Se sim, estás no lugar certo!

Neste artigo, reuni algumas dicas que considero muito importantes no meu trabalho diário e no dos meus colegas. São alguns princípios básicos que todos devemos tentar seguir para programar como verdadeiros profissionais! Fica ciente de que codificar como um pro não diz respeito apenas a ti ou ao teu código. É sobre o quão bem o tu código está preparado para ser executado por outros colegas. Isto torna tudo mais fácil para ti e para aqueles que seguirem os teus passos, continuando a partir de onde tu paraste. Portanto, aqui, estão algumas das principais coisas que consideramos críticas.


Dica 1: Indenta o teu código

A indentação de código é um dos princípios fundamentais a serem seguidos no desenvolvimento de código. Há uma razão muito simples, mas importante, pela qual devemos de fazer isso: torna o código mais fácil de ler e entender! E visualmente parece melhor também. Sempre que um programador assume uma nova tarefa que envolve a leitura ou modificação de código escrito por outras pessoas, uma boa indentação de código torna o seu trabalho muito mais fácil.

Dica 2: Usa nomes intuitivos e adota convenções de nomenclatura

Às vezes, nomear variáveis ou métodos parece uma tarefa razoavelmente simples, mas devemos sempre de ter em mente que o nosso código pode um dia parar nas mãos de outro programador. Com isto em mente, devemos tentar sempre nomear as nossas variáveis/métodos da forma mais simples possível. Para facilitar esse processo, devemos adotar convenções de nomenclatura, ou seja, uma forma padronizada de nomear variáveis e métodos ao longo do código. Se usarmos essa técnica, o nosso trabalho será mais fácil tanto para nós quanto para os outros programadores.

Dica 3: Comenta o teu código

Existem várias opiniões sobre o tema relativo a comentários de código. Alguns acreditam que comentar o código ocupa muitas linhas e enche a solução de lixo desnecessário. Outros acreditam que o código deve ser comentado de cima a baixo para explicar com clareza tudo o que é feito.

Tenho sentimentos contraditórios sobre essas teorias. Pessoalmente, acho que devemos comentar o nosso código, mas apenas quando for necessário. Existem partes do código que, se receberem um bom nome, são auto-explicativas. Porém, existem alguns métodos que possuem operações complexas e, neste caso, deve ser bem explicado o que eles fazem e como operam. Então o meu conselho é: comenta, mas apenas quando for necessário.

Dica 4: Use cláusulas try/catch 

Ao desenvolver um software, acontece por vezes não considerarmos um possível resultado errado ou uma exceção. Nesses casos, o uso de cláusulas try/catch pode ser muito útil. Por exemplo, se houver um erro na conexão ao banco de dados e essa parte do código não for tratada num bloco try/catch, ele poderá enviar o nome do banco de dados ao utilizador. Este é um comportamento que não queremos. É muito importante lidar corretamente com as exceções para podermos dar um feedback adequado sobre o resultado. Também torna mais fácil para o programador solucionar problemas porque quando usamos a cláusula try/catch, sabemos com precisão onde ocorreu o erro.

Dica 5: Evita a repetição de código

Por vezes, nós, os programadores, temos tendência a escrever o mesmo código repetidamente para realizar uma tarefa semelhante em diferentes partes do nosso projeto. Devemos levar este pensamento a sério: “A terceira vez que escreves a mesma parte do código é o momento certo para extrair essa lógica num auxiliar para uso geral”. Repetir o mesmo código na solução aumenta desnecessariamente a complexidade da mesma. Devemos manter as coisas o mais simples possível de entender e trabalhar.

Dica 6: Escreve código defensivo

Os programadores podem, por vezes, sucumbir à tentação de tentar escrever um código que faça exatamente o que pretendem, mas esquecem que nem sempre ele faz o que se quer. Quando escrevemos o código, devemos de ter sempre em mente onde é que ele pode falhar! Se fizermos isso, certamente evitaremos muitos bugs que serão descobertos posteriormente, poupando tempo e dinheiro.

Dica 7: Evita grandes métodos

Quando temos uma tarefa em mãos que envolve várias operações, é fácil adotar uma abordagem errada e tentar fazer tudo, usando um único método. Isso significa quase sempre que um método extenso será o resultado desse comportamento. Métodos grandes têm muita complexidade cognitiva, o que significa que são difíceis de entender e trabalhar. Quando um método se torna tão grande, é hora de quebrá-lo e dividi-lo em métodos auxiliares menores.

Dica 8: Usa e abusa dos padrões de design

No nosso dia a dia, encontramos problemas que, com certeza, muitos outros programadores pelo mundo fora também enfrentam. Os padrões de design foram desenvolvidos para criar soluções simplificadas para problemas comuns de desenvolvimento. Os padrões de design permitem-nos desenvolver código com mais eficiência e também nos fornecem uma ferramenta que é uma linguagem universal entre os programadores. Essa técnica dá-nos dicas de como criar diferentes tipos de código conforme as suas necessidades. O uso de padrões de design além de tornar o trabalho do programador mais fácil, também permite que qualquer outro programador que perceba de padrões de design aprenda o teu código de uma maneira muito mais fácil. Temos um artigo inteiro que fala deste tópico em particular. Lê aqui.

Dica 9: Escreve sempre testes 

Desenvolver software não deve ser apenas sobre escrever código e fazê-lo funcionar. Trata-se também de garantir que o nosso produto é entregue em excelentes condições. O teste é uma parte importante do processo da garantia de qualidade de qualquer desenvolvimento de software, pois dá-nos a confiança de poder dizer aos nossos clientes que temos um produto estável e totalmente funcional. Garantimos não só a qualidade do nosso produto, mas os programadores demoram menos tempo a corrigir bugs. Quanto mais cedo um bug for identificado, mais fácil será corrigi-lo. É precisamente aí que os testes podem fazer a diferença. É muito mais caro para uma empresa corrigir bugs quando o código já está em produção do que quando ainda está em desenvolvimento.

E Dica Final: Não escrevas código que não precisas imediatamente

Às vezes, um programador escreve código para criar uma funcionalidade, mas já a pensar em novos recursos. Isso pode levar à tentação de escrever um código do qual não precisa agora, mas que poderá precisar no futuro. O meu conselho é: se não precisas agora, não o escrevas. É certo que o teu código deve estar pronto para suportar novos recursos, mas não há necessidade de torná-lo mais complexo escrevendo código desnecessário.

Geralmente, o código escrito antecipadamente torna-se inútil porque, por exemplo, o novo recurso não foi implementado ou precisa de ser alterado por algum motivo. No primeiro caso, é um código morto ou lixo, enquanto no segundo caso a reformulação é tão trabalhosa quanto escrevê-lo do zero. Nenhum dos cenários parece bom.

O mesmo vale para o código comentado. O código comentado deixa de ser necessário em muitos dos casos (exceto em algumas raras exceções). O que acontece frequentemente é que o deixamos lá mesmo assim.

Tens outras dicas que podem interessar-te? Diz-nos onde e como podemos ajudar!

NÃO PERCA NENHUMA HISTÓRIA!Junte-se à nossa comunidade em crescimento e seja inspirado pelo nossos artigos.
Sem brincadeiras, sem jogos, sem publicidade. Somente um clique para subscrever.
ENPT
lang
Load-chatbot