9 minutos de leitura
Como você escreve seu código?
Você segue boas práticas?
Tem um pensamento a longo prazo?
Se preocupa com seus colegas de time?
E com seu eu do futuro, que vai precisar fazer uma manutenção no código que está sendo escrito hoje?
Neste texto, vamos dar dicas sobre como escrever um código mais sustentável. De dev para dev 🙂
Se você já se preocupa com isso, pode ser uma oportunidade para descobrir práticas que ainda não conhece. Caso contrário, não se preocupe, você pode evoluir muito nas suas práticas de desenvolvimento de software.
Acompanhe tudo que você deve levar em conta para escrever um código com mais qualidade. Vem com a gente!
Não tinha como começar esse texto de outra forma, se tem um mantra que você deveria levar para sua vida como pessoa desenvolvedora, é esse!
Talvez no início da carreira como dev, a gente pense que só escreve código para a máquina e que não faz muita diferença se nomeamos uma variável como x ou com um nome que realmente indique o que ela armazena. Achamos que o que importa é o código funcionar, o como não faz tanta diferença assim.
Mas esse pensamento passa rápido, ou pelo menos deveria passar rs, e vamos nos dando conta que no fim do dia tudo se resume a pessoas. Sejam as que trabalham com você hoje, as que irão trabalhar no futuro ou até mesmo você daqui alguns meses tendo que modificar um código que escreveu no passado.
As boas práticas de desenvolvimento, sem dúvida, tornam a qualidade do software melhor, o deixam mais robusto, mais seguro, com menos falhas.
Mas, no fim do dia, acreditamos que o maior impacto é deixar as pessoas que desenvolvem mais produtivas e aptas a escrever features com mais qualidade, além de manter uma aplicação com menos dor de cabeça.
A seguir vamos ver algumas dessas práticas que vão te ajudar a escrever códigos melhores.
Se você trabalha ou já trabalhou em um time que não tem padrões de código bem estabelecidos, sabe a confusão que é. No começo, pode não parecer um problema, mas o tempo vai passando e a qualidade do código ficando comprometida.
Sem a definição de padrões, algumas coisas começam a acontecer. Por exemplo, uma pessoa usa aspas simples, a outra duplas, uma coloca ponto e vírgula no final de cada linha, a outra não (se for uma linguagem que permite isso, se não seu problema vai ser bem maior), uma usa dois espaços para indentação, a outra quatro.
Esses são só alguns exemplos de coisas que acontecem e que vão dificultando a leitura do seu código.
Uma forma de evitar que isso ocorra é conversar com seu time e definir as regras que vocês querem seguir.
Feito isso, uma excelente opção é utilizar ferramentas que ajudam a seguir o que foi definido, como as de lint, que fazem uma análise estática do código e indicam problemas que possam existir; as que te ajudam com a formatação, então basta salvar seu arquivo e tudo que está fora das regras é corrigido!
E também as que criam uma configuração padrão para diferentes editores de texto. Aqui na BossaBox usamos o combo ESLint + Prettier + EditorConfig e tem funcionado super bem <3
Novamente vamos falar sobre quem desenvolve software. Afinal somos nós que passamos boa parte do nosso tempo lendo código. É aí que dar bons nomes para variáveis, classes, métodos, arquivos, etc, faz toda a diferença.
Quando encontramos nomes de variáveis como x e y ou com abreviações, temos mais dificuldade para entender o propósito daquele elemento.
Pense no caso em que você quer armazenar a data de nascimento de uma pessoa: alguns nomes não tão interessantes seriam d, date, bd (eles não deixam o cenário explícito), já birthDate deixa claro o valor armazenado.
Abreviações também abrem espaço para ambiguidade, pense na variável intTemp: o que será que ela significa? O int vem de integer, internal, interesting, intern? E o temp, de temperature, temporary? Vale mais a pena utilizar um nome mais extenso, do que abrir espaço para tantas dúvidas.
Para ter um código com boas nomenclaturas, é interessante que você e seu time decidam qual convenção vocês desejam seguir, algumas opções são PascalCase, CamelCase e SnakeCase.
Vale também dar uma olhada se a linguagem que você utiliza já tem algum padrão de nomenclatura definido, assim você não precisa criar algo do zero e segue as boas práticas da comunidade.
Aah os testes, ainda há quem não veja valor nessa etapa tão importante do desenvolvimento, mas temos certeza que quem escreve testes sabe o quanto eles contribuem para a construção de um código mais sustentável e com mais qualidade.
Uma coisa que percebemos ao escrevê-los é que eles nos tiram do automático, nos forçam a pensar mais sobre o que estamos desenvolvendo, sobre os diferentes cenários que podem ocorrer. E até, se alguma coisa que fizemos poderia ser construída de uma forma diferente, principalmente quando os testes estão ficando complexos demais.
Ter testes na aplicação também facilita, e muito, fazer alterações no código.
Sem dúvida as chances de inserir um bug em um código com boa cobertura de testes é muito menor.
Testes te ajudam a:
Esse tópico é bem vasto e vale se aprofundar, pois existem diferentes tipos de testes, como unitários, de integração, end-to-end, entre outros.
Se o seu projeto ainda não tem testes automatizados, converse com seu time e tentem começar a implementá-los desde já. Assim você garante uma maior qualidade nas novas funcionalidades. Sempre que possível, olhe para o que já foi feito e ainda não tem testes.
Já perdemos bastante tempo por não aplicar essa prática no dia a dia e acreditamos que você também! rs
Muitas vezes, temos a tendência de logo de cara já querer escrever a solução perfeita. Em casos mais simples ou com problemas que já resolvemos várias vezes isso até funciona bem: “sei o que precisa ser feito e a melhor forma de fazer”.
Mas, quando me deparo com um novo desafio ou um problema mais complexo, tentar fazer tudo da melhor maneira de primeira geralmente me faz levar mais tempo para finalizar a tarefa.
Nesses casos, um bom caminho é só tentar resolver o problema no início (claro que você já pode tentar seguir alguns padrões, evitar as variáveis x, y da vida, mas tudo bem se os nomes e a lógica não ficarem tão bons). Ao chegar na solução, você passa a fazer iterações no que escreveu para deixar a nomenclatura mais assertiva.
Se possível simplificar a lógica: criar funções menores, que juntas resolvem o problema, e assim por diante. Ir fazendo iterações no código vai lhe permitir chegar em uma solução mais limpa, com mais qualidade, que segue boas práticas de desenvolvimento e está alinhada com os padrões definidos pela sua equipe.
Dica de amiga: dificilmente sua primeira versão de um código será a melhor que ela poderia ser. Então itere, itere, itere!
Sempre que você for utilizar um padrão novo no seu projeto, que implica em mudanças no código que já estava feito, faça aos poucos.
Tente encaixar em alterações que você já irá fazer até ter o padrão implementado em todos os lugares. Como, por exemplo, se decidiram alterar a maneira como escrevem testes de integração, a refatoração pode ser feita a cada vez que precisarem alterar parte da aplicação, que possui um ou mais testes.
Mas cuidado: não trate todos os padrões da mesma forma. Há algumas refatorações que precisam e devem ser feitas de uma só vez, o importante é ter uma visão crítica para entender quando realmente essa necessidade existe.
Mais uma dica de amiga: anote todas as refatorações que estão rolando no seu projeto em algum lugar onde todas as pessoas desenvolvedoras tenham acesso, para que sempre saibam o que está sendo feito e o motivo.
Aqui na BossaBox, temos uma lista no nosso template de Merge Request. Assim, toda vez que alguém disponibiliza uma feature para revisão, a pessoa consegue dar uma olhada e checar se não deixou passar alguma refatoração.
Ao escrever uma função nova, cheque se existe no código uma outra que já faz o que você precisa (mesmo que parcialmente). Se sim, tente extrair o máximo possível. Deixe a nova função o mais abstrata que conseguir, para poder utilizá-la não somente no que você está escrevendo agora, mas também em partes do código no futuro.
Além disso, tente sempre deixar suas funções pequenas, sem muitas linhas de código. Isso facilita a leitura e o entendimento, pois como já citamos, você não escreve código somente para a máquina, mas sim para pessoas (e o seu eu do futuro).
Você já ouviu falar sobre acoplamento e coesão? Esses são dois conceitos extremamente importantes para o desenvolvimento de software e que estão super relacionados. Os dois contribuem para manter o código bem feito e ajudam em um caso de possível manutenção futura.
Assim, caso seja necessário, é possível trocar alguma das duas partes sem que a outra pare de funcionar.
As escoteiras e escoteiros tem uma ótima regra: sempre deixe o acampamento mais limpo do que você o encontrou.
Ela pode ser aplicada na vida como um todo, e não seria diferente no nosso dia a dia como devs.
Então, sempre que for escrever uma funcionalidade nova ou fazer uma refatoração, dê uma olhada ao redor, será que não tem nada que poderia ser melhorado?
“Uma variável que não tem um nome muito claro, uma função que poderia ser dividida em duas, um padrão de código que poderia ser adicionado” – são várias as possibilidades.
O importante é ter essa ideia em mente e sempre tentar melhorar o código, deixando-o mais explicativo, com uma melhor leitura para as outras pessoas, e seguindo os padrões escolhidos pelo time.
A revisão de código, comumente chamada de code review, é uma excelente prática para estimular dentro da sua equipe, ela faz com que as pessoas desenvolvam senso crítico a respeito do código das outras e do seu próprio.
Durante esse processo, além de acabar aprendendo e ensinando novas formas de fazer o mesmo pedaço de código, contribuímos para que o resultado final tenha mais qualidade.
É importante lembrar que a pessoa que codou pode não ter visto algo (uma repetição desnecessária, uma função com lógica errada, uma refatoração que poderia ter sido feita, etc). Na Code Review, isso pode ser visualizado por outra pessoa que não ficou imersa naquela parte da aplicação por longos períodos de tempo.
Lembre-se também de fazer um auto code review quando for abrir uma merge request. Às vezes, enquanto estamos codando deixamos passar pequenas coisas no código (como um console.log, por exemplo) que se você parar para ver quando abrir a MR, já otimiza tempo do review de outra pessoa.
Como vimos até aqui, trabalhar com outras pessoas requer que diversos acordos sejam estabelecidos, para garantir que estamos construindo um software de qualidade e escalável.
Para manter esses acordos sempre vivos e fazendo sentido, é importante criar espaços para conversar sobre boas práticas de desenvolvimento de software, revisão dos padrões utilizados e também para promover o entrosamento da equipe.
Algumas cerimônias legais que temos no time de tecnologia aqui na BossaBox são:
Lembre-se de sempre anotar as decisões tomadas e repassar para todas as pessoas. Principalmente as que não estavam presentes nessas cerimônias, para que elas estejam cientes e consigam aplicar em suas rotinas.
—
Obrigada por chegar até aqui.
Essas são algumas sugestões de práticas que você pode aplicar no seu dia a dia e no do seu time para construir softwares melhores.
Com certeza, existem vários outros pontos que ficaram de fora. Então conta pra gente se tem algo que você acha muito importante e que nós não falamos sobre. Não deixe de compartilhar com a gente quais práticas você já usa.
Até a próxima!
3 minutos de leitura
Ler artigoTransformação Digital e Inovação
4 minutos de leitura
Ler artigo