Fala, pessoal! Beleza? Anteriormente eu falei sobre boas práticas de programação para estudantes que estão iniciando seus estudos em Java.
No entanto, hoje nós falaremos de boas práticas para quem está atingindo um nível mais avançado, em um momento onde você já está se preparando para entrar na área de trabalho como desenvolvedor Java júnior!
Vamos lá?
Nomes de Métodos
Primeira coisa que vamos conversar é sobre os nomes.
Os métodos e funções devem ter nomes completamente intuitivos! Sim, você precisa se importar com os nomes!
Uma padronização é completamente obrigatória e fundamental para boas práticas, sendo assim, um exemplo do que não fazer é usar nomes no infinitivo e outro no gerúndio.
Como no dia a dia é mais usado no infinitivo, é o que eu aconselho a ser utilizado. Até coloquei alguns exemplos a seguir:
Correto: public void somarTresValores(){} //Muito bem! Usando infinitivo e mantendo a padronização!
public void somarDoisValores(){} //Muito bem! Usando infinitivo e mantendo a padronização!
public void somarTresValores(){} //Muito bem! Usando infinitivo e mantendo a padronização!
Não recomendável:
public void somandoTresValores(){} //Usando gerúndio, não é tão interessante, mas não é errado.
public void somar(){} //Nome pouco intuitivo, e não seguindo a padronização como o de cima.
public void somarTresValores(){} //Usando infinitivo, porém, não seguindo nenhuma padronização junto dos outros 2 métodos de cima.
Okay, isso não vai afetar o desempenho do seu código. No entanto, é falta de organização, e, quando o sistema ficar grande, prejudicará no entendimento. Ademais é uma boa forma de mostrar maturidade do código.
Responsabilidade Única
Agora partiremos para um tópico essencial, a responsabilidade única, também chamada de The Single Responsibility Principle (SRP).
Ela faz parte de um acrônimo muito conhecido chamado S.O.L.I.D (vale a pena vocês pesquisarem sobre!)
Entrando no que significa tudo isso, é bem simples: uma única função ou método deve conter apenas um único papel a ser cumprido, ou seja, uma única responsabilidade.
Então, se você tiver um método que faz mais de de uma tarefa, ele está ferindo esse principio.
Se você, por exemplo, possui um método que fará a verificação de um tipo de pagamento e se o valor é realmente o necessário pra efetuar o pagamento, o mesmo não deve ser utilizado para receber esse pagamento ou para verificar, receber o pagamento e depois enviar as notificações. Isso realmente não se faz.
Podemos ver isso também no padrão de arquitetura MVC que é um bom exemplo de como se organiza a arquitetura em camadas, sendo cada camada com uma única responsabilidade.
Caso ainda não conheçam esse padrão de projeto tão conhecido que é o MVC, podem ler nosso artigo sobre ele:
Não é necessário que conheçam esse padrão, apesar de ser uma boa ideia estudar sobre ele. Porém, é algo a mais para que possam assimilar a questão de responsabilidade única não servir apenas para métodos e funções.
Problemas
É, sem dúvidas, um fato que no inicio de nossas carreiras nos deparamos com muitos erros, e muitos deles são completamente desconhecidos.
Diversas vezes esses erros acontecem por coisas “bobas”, principalmente quando se tem dúvidas sobre a base do Java.
Chega um determinado momento que está lançando uma NullPointerException, e nós sabemos que isso é gerado muitas vezes, mas você realmente sabe o que significa a NullPointerException? Então, se a resposta for não, precisamos botar em práticas as dicas que vou dar agora.
Primeiro, pesquise, pesquise muito! Essa é uma das boas práticas mais importantes, além de ser uma das maiores tarefas dos programadores, então por que do estudante seria diferente?
Aconteceu algo inesperado? Pesquise! Quer entender algo que não sabe? Pesquise! Quer descobrir como faz determinada coisa? Pesquise!
E se não haver conteúdo em português, basta pesquisar em inglês com o Google tradutor e depois traduzir a página que você cair.
Isso, sem dúvida, isso vai te trazer muito, muito conhecimento mesmo! Você vai aprender a pesquisar por soluções, e essa é umas das habilidades que qualquer desenvolvedor precisa!
Então, em resumo é: se deparou com algo, antes de tudo, pesquise!
Ah, e ultimo, não tenha pressa para achar a solução. Tem tópicos e artigos realmente grandes! Esse imediatismo pode fazer você demorar mais tempo ainda pra encontrar a solução, por passar por onde ela estava e não ter dado a devida atenção.
E não queira descobrir da pior forma possível, passando horas e horas vendo artigos e tópicos, e no fim, voltando ao primeiro tópico que você não achou que tinha a solução por ter feito uma breve leitura.
Bônus – Pequenos Erros Fazem a Diferença
Nomes de Variáveis
Faz parte das boas práticas que nomes de variáveis sejam apropriados para que o significado dela seja intuitivo. Criar variáveis com nomes não intuitivos é um dos grandes erros de iniciantes, e relembrando, nome de variável não começa com letra maiúscula.
Nome de Classes
Os nomes das classes sempre devem começar com letra maiúsculas, não se esqueça disso. É bem comum ver classes criadas com iniciais minúsculas, e isso não é certo.
Preocupação com Desempenho
Diversas vezes a preocupação com desempenho se torna um problema quando há uma preocupação e tempo gasto em relação a pequenas mudanças que realmente não irão trazer um benefício significativo.
O problema em si não é prezar por desempenho, mas no tempo e preocupação gasto nisso, que não faz sentido quando não melhorar o desempenho significativamente.
Pressa por Conhecimento
Quando se é novo na área de programação, geralmente ocorre a frustração por não aprender tudo de primeira ou de uma forma extremamente rápida. Mas isso é extremamente normal.
Todos os programadores passaram por isso, tente não prezar por esse imediatismo, porque isso pode te prejudicar e muito! Deixar de fazer exercícios por “não precisar” ou ser “tempo perdido”, não é uma boa prática.
O complexo de toda linguagem está diretamente atrelada ao básico dela, e se você for estudar o avançado sem ter pleno conhecimento do básico, vai ser um grande problema!
Simples e Funcional
Deixe o código o mais limpo e simples possível, desde que cumpra seu papel de forma certa. Algumas vezes fazer tudo em uma linha por ser mais “enxuto”, complica o entendimento, e depois ler e entender o que está acontecendo se torna uma tarefa difícil.
Então nem sempre que você possa deixar algo curto, como em uma ou poucas linhas, significa que seja uma boa ideia fazer isso.
Reaproveitar Código
Existe uma boa prática que preza pelo reaproveitamento de código. Isso é, sempre que possível, não aproveite código no CTRL + V, e sim crie métodos que façam uma coisa apenas, e então use o método ao invés de ficar copiando e colando linhas de código.
De certa forma isso se encaixa com o SRP, quando você transforma um método com uma única responsabilidade, é infinitamente mais fácil de você reutilizar esse método em outros lugares.
Portfólio
Praticamente todos os estudantes que estão se preparando para a área de trabalho já estão fazendo um portfólio ou pensando sobre ele, e tem alguns detalhes que eu gostaria de abordar sobre isso.
Nesse quesito, uma das boas práticas é não fazer um portfólio apenas com projetos que abordem o mesmo conteúdo, sempre que surgir uma nova “dificuldade”, opte por criar um projeto diferente do que resolver o problema que surgiu.
Chega em um ponto que no GitHub há 5 projetos de Crud, mas a única coisa que muda é regras de negócios e o contexto.
Tente aplicar mais de um conhecimento dentro de um projeto, faça uma cobertura legal de testes, pode tentar usar interfaces funcionais também, e faça autenticações.
O fato é: não crie um aprendizado viciado. E o que eu quero dizer com isso é que você pode programar apenas o básico todas as vezes, mas em uma empresa real com certeza não será assim.
Se desafie, pense em um projeto e vá nele. Se surgir dificuldades, passe por elas. Só assim, em um ambiente mais complexo onde você realmente tem que pensar em soluções fora do seu dia a dia, conseguirá se desenvolver mais e obter mais conhecimento.
Então a mensagem é: não tenha medo de tentar fazer coisas que você não sabe, e tente não adquirir esse conhecimento viciado.
Conclusão
Minha intenção com esse artigo foi passar a visão para que vocês tenham mais facilidade de se preparar e de entrar pra área de trabalho, melhorando seus projetos e sua prática como desenvolvedor.
Espero que vocês tenham gostado das dicas e também agregado algo no conhecimento de todos. Um grande abraço e até a próxima!
