6 pecados que os desenvolvedores de back-end não devem cometer

6 pecados que os desenvolvedores de back-end não devem cometer

Um bom desenvolvedor back-end pode ser apenas a diferença entre uma casa que pode resistir a um furacão e outra que desmorona em uma estação de ventos fortes.

desenvolvedores de back-end

Janelas de encaixe

Além disso, eles precisam trabalhar sob pressão para cumprir prazos e refatorar, depurar ou redimensionar rapidamente. Há muito com que lidar, e alguns dos pecados mais comuns cometidos pelos desenvolvedores de back-end podem ter consequências duradouras. Vamos revisar os 6 mais importantes.

#1 Você não deve acumular muitas dívidas técnicas

O primeiro pecado é comum aos desenvolvedores back-end e front-end: ter uma pilha de dívidas técnicas significativa. As equipes ágeis, de fato, dependem de dívida técnica para fornecer soluções mais rápidas e entregar melhores produtos, mas as probabilidades são de que quanto mais você acumular, maior será a chance de ser mais difícil implementar novas soluções ou dimensionar o projeto posteriormente.

A máxima aqui é, não construa código em cima de código ruim, pois assim que você refatorar o novo código provavelmente irá quebrar. Código espaguete, funções/métodos longos, muitos recuos, instruções if/else excessivas e práticas inadequadas de nomenclatura de variáveis ​​podem parecer pequenos detalhes com consequências insignificantes, mas podem gerar muitos problemas.

Com boas práticas de codificação e um bom planejamento, o débito técnico pode ser evitado e, nos casos em que for necessário, um bom protocolo para acompanhá-lo ajudará bastante a evitar que a equipe construa uma montanha no topo de um castelo de cartas.

#2 Você não deve escrever documentação de má qualidade

Uma boa documentação é como um mapa bem desenhado ou uma boa receita: não deixa nada à imaginação. Para pegar uma página do zen do Python, explícito é melhor que implícito. Nesse sentido, um dos maiores pecados dos desenvolvedores back-end é pensar na documentação como uma reflexão tardia.

Documentação deficiente ou ausente causará confusão na melhor das hipóteses ou interromperá completamente um projeto, pois os desenvolvedores terão que revisar manualmente o código linha por linha para descobrir o que está acontecendo.

Com boas práticas de documentação, os desenvolvedores de front-end terão mais facilidade para entender como seu lado do projeto se comunicará com o back-end e aqueles que vierem depois terão uma fonte confiável de informações para recorrer ao procurar bugs ou durante a reestruturação.

Como bônus, podemos acrescentar outro mandamento: você deve comentar seu código. Assim como as documentações limpas, o código comentado ajudará os revisores de código e outros desenvolvedores a compreender a lógica subjacente. Esses comentários podem até ajudar os próprios desenvolvedores quando eles voltam para revisar um código que não tocam há algum tempo.

#3 Você não deve perder provas

Os testes são parte integrante de qualquer ciclo de desenvolvimento. Escrever testes e buscar casos extremos ajuda os desenvolvedores de back-end a detectar bugs e explorar cenários que, de outra forma, poderiam passar despercebidos até que seja tarde demais. Mesmo assim, alguns desenvolvedores optam por pular alguns testes, talvez porque queiram cumprir um prazo apertado ou porque estão confiantes demais.

Portanto, esse pecado geralmente acontece quando os desenvolvedores ficam sem tempo ou quando confiam demais em seu próprio julgamento/revisões de código. Nenhum par de olhos tem experiência suficiente para prever o comportamento de um código em todas as situações possíveis.

Uma maneira simples de evitar esse problema é escrever os testes junto com o código ou compartilhar o pseudocódigo com outro desenvolvedor e fazer com que ele escreva um conjunto de testes. Na verdade, algumas equipes chegam ao ponto de primeiro criar os testes mais extremos possíveis e depois escrever o código. Dessa forma, eles estão se desenvolvendo efetivamente para resolver casos extremos.

Os testes são uma forma confiável de garantir que o código esteja funcionando conforme o esperado e que a lógica por trás dele seja flexível o suficiente para se adaptar e escalar conforme exigido pelo projeto.

#4 Você não deve usar muitas tecnologias para a mesma solução

Um dos maiores trunfos de trabalhar com linguagens de programação populares como Python ou node.js é a quantidade de recursos disponíveis. Então, por que escrever algo do zero quando você pode simplesmente importá-lo?

Mas isso abre a porta para o seu próprio conjunto de problemas. Depender demais de software e bibliotecas externas significa, antes de mais nada, que você está lidando com várias APIs ao mesmo tempo, e isso por si só já é um desafio.

Mas, fora isso, as tecnologias são constantemente atualizadas, o que pode trazer alterações indesejadas ou bugs que podem quebrar o seu próprio projeto. Além disso, os projetos ficam obsoletos e aquela biblioteca incrível que você encontrou pode desaparecer repentinamente em um piscar de olhos.

Isso não quer dizer que se deva limitar-se a uma solução, mas sim uma palavra de cautela: a introdução de novas tecnologias em um projeto deve ser sempre uma decisão bem pensada e que, às vezes, caminhar um quilômetro extra para fazer isso sozinho evitará dores de cabeça no futuro. linha.

#5 Você não deve esquecer um protocolo de backup

Quase todo desenvolvedor backend tem que lidar com bancos de dados em suas carreiras e, como todos sabemos, se um aplicativo é um corpo, então os dados são o sangue que lhe dá vida. Bons desenvolvedores de back-end mantêm backups extensivos de seus dados, na nuvem, em mídia física, em servidores remotos, em praticamente qualquer lugar. Sem eles, os engenheiros correm o risco de perder todo o seu trabalho devido a um acidente de hardware ou software.

É por isso que os backups devem ser frequentes e confiáveis. Se seus dados são atualizados minuto a minuto, perder alguns dias pode ser catastrófico para um projeto. É melhor investir em uma solução de armazenamento do que perder tudo com um erro.

#6 Você não deve ter um planejamento ruim antes de construir o modelo de dados

Reconstruir um modelo do zero pode ser um pesadelo, portanto, acertar na primeira vez economizará tempo e investimento no projeto. Por vezes, a reestruturação dos modelos de dados é inevitável, mas deixemos que esses momentos sejam o produto de influências externas e não de falta de previsão.

Bons desenvolvedores de back-end obtêm uma imagem muito clara do que o projeto deve fazer e projetarão um modelo que se ajuste ao projeto com escalabilidade em mente, mesmo que o projeto não envolva escalonamento tão cedo.

Projetar um bom modelo de dados é um excelente exemplo de planejamento de longo prazo e evitará os problemas que surgem com bancos de dados que excedem suas capacidades.

Um bom desenvolvedor backend é um estrategista e um jogador de equipe

Habilidade técnica não é a única coisa que um desenvolvedor back-end precisa para ser bom. O que realmente faz um especialista brilhar é que ele entende o papel que desempenha na equipe de desenvolvimento e o quanto o projeto depende do seu trabalho. Contratar um bom desenvolvedor back-end pode ser apenas a diferença entre uma casa que pode resistir a um furacão e outra que desmorona em uma estação de ventos fortes.

Conteúdo Relacionado

Retour au blog

Laisser un commentaire

Veuillez noter que les commentaires doivent être approuvés avant d'être publiés.