Quando se fala em código robusto, criação, inovação e técnicas de melhoria de performance de software, raramente é lembrado do básico, do ABC da programação e durante o Capiconf, um evento de desenvolvedores para desenvolvedores, me deparei com a palestra do Matheus Gontijo e fiquei simplesmente perplexa com a obviedade das soluções. Nós como desenvolvedores precisamos parar e olhar o que está em frente aos nossos olhos, muitas vezes a solução para uma aplicação mais eficiente está no básico e não na nova tecnologia, no inimaginável, na tecnologia disruptiva, a solução já está nas nossas mão, mas esquecemos de olhar pra ela com cuidado.
Para começar, códigos mal feitos e não otimizados drenam horas de energia do time, seja do desenvolvedor que o fez ou do desenvolvedor que vai ter que corrigir algum eventual problema causado por esse código. Horas de trabalho perdidas são nada mais nada menos do que prejuízos, para a equipe e para a empresa, além disso, encontrar soluções para um código mal feito é desencorajador para quem precisa fazê-lo, não existe coisa mais chata do que se deparar com um código que não tem nexo e que não é claro na sua função.
Como pode ser solucionado este tipo de comportamento na programação? Com treinamento dos conceitos básicos da programação e lógica. Ok, mas o que isso quer dizer? Precisamos olhar com cuidado as aplicações que temos na mão e precisamos pensar nas soluções objetivas de forma minuciosa para que a solução encontrada seja mesmo a melhor para o caso em questão. Como podemos saber se o código produzido é um código bom e decente ou não? Temos 4 perguntas básicas que precisam ser respondidas: Este código vai ter uma manutenção fácil? Ele é legível? Ou seja, outro desenvolvedor que não seja você vai conseguir entender o que você quis fazer? Este código é facilmente testado? E por fim, este código é compreensível?
Um outro detalhe importante, o código não deve ser extremamente complexo e muito menos incompreensível. Qualquer desenvolvedor que esteja envolvido no projeto precisa conseguir ao menos compreender o seu código, caso contrário, o problema é o seu código, não o desenvolvedor que não entendeu. Imagine, se nem o cara que está envolvido no mesmo projeto que você consegue entender qual a sua intenção com esse código, o que vai acontecer quando alguém for dar manutenção? Com certeza não vai ser rápido e muito menos intuitivo, então é sempre bom pensar nesse aspecto.
Existem alguns conselhos de boas práticas que podem ser aplicados e com certeza vão melhorar o código que está sendo produzido, estes conselhos não vão poder ser aplicados sempre ou serão viáveis, mas sempre que possível, é bom usar:
Use somente um nível de indentação em cada método.
O que isso quer dizer? Para que seu método seja claro, legível e possa ser usado em outros pontos da aplicação, ele precisa ser um método preciso para determinado objetivo, um método que realiza muitas atividades se torna exclusivo para determinado fim e se torna impossível de ser reutilizado.
Não use else.
Como assim “não use else”? Eu sei que muitas vezes não temos outra alternativa se não colocar um else, mas porque não tentar mudar esta abordagem? Usar outros tipos de estrutura? O grande problema do else ou dos elses no meio do código é que esta estrutura pode tomar uma proporção muito grande e praticamente impossível de controlar, onde tudo está com uma dependência muito alta das demais condições, tornando a manutenção extremamente chata e demorada de ser feita.
Encapsule dados.
Quando estamos na cadeira acadêmica ouvimos falar em encapsulamento o tempo todo, por que é que quando vamos aplicar isso, esquecemos desse detalhe? Quando um dado precisa de validação, possui regras de negócio ou comportamentos a serem levados em conta, o encapsulamento é a melhor solução.
Faça coleções de classe.
Arrays separados e bem organizados, com classes específicas para facilitar e tornar mais rápido o acesso à listas.
Um acesso a método por linha.
Este é um dos princípios básicos da programação orientada a objeto. É conhecida como lei de Demeter, o principal objetivo é organizar e reduzir dependências entre classes. Existe uma dependência entre classes quando uma classe faz referência a outra, através de execução de algum método seu. Esta dependência pode causar alguns prejuízos ao projeto. Então a intenção é reduzir ao máximo a complexidade.
Não use abreviações.
Um código claro e limpo pede que os métodos e variáveis tenham nomes compreensíveis, não só para quem os criou, mas também para qualquer um que vá fazer sua manutenção.
Não crie arquivos longos.
Quanto menor for o arquivo criado, menor vai ser a lista de dependências, mais legível se torna e a manutenção se torna mais simples. Este mesmo conselho é válido para métodos. Quanto menor foi o método, mais objetivo ele se torna, a manutenção é direta, simples e o método se torna muito mais legível.
Não use getters e setters.
Por que não usar? A intenção de classes separadas é que o encapsulamento seja consistente, respeitando regras de negócio, quando deixamos o acesso livre, perdemos confiabilidade na nossa aplicação.
Por mais que tudo isso pareça óbvio, recomendo que olhe suas últimas 10 ou 15 alterações em código ou as últimas aplicações criadas. Quantas destas boas práticas você tem levado em conta? Como anda a performance do código que você cria?
