8 erros que todo programador já cometeu

Dia após dia, nós cometemos erros – não só na vida, como no trabalho. Logo, na programação isso fatalmente iria acontecer também. Alguns são triviais, outros são graves. Mas eles sempre acontecem.

E isso é algo positivo. Como disse Eleanor Roosevelt: “a vida é muito curta para ser gasta em repetir os erros de outras pessoas”. Portanto, o melhor é aprender – e crescer profissionalmente – a cada erro.

Salvar incorretamente mudanças no projeto

Todo mundo já enviou um commit para a branch errada do repositório ao menos uma vez. Por vezes pode levar um bom tempo para corrigir esse erro. Mas se você perceber a tempo, nada de grave vai acontecer. A situação pode ficar cada vez pior caso você continue a carregar o código para a branch errada, então tenham isso em mente e sempre prestem atenção.

Confundir qual commit enviar

Muitas vezes há arquivos extras ou que algo está faltando no repositório. Isso acontece quando muitas alterações são feitas de uma vez. Não é de admirar que você adicione algo extra ou esqueça de algo de que precisa.

O primeiro, geralmente é feito por desenvolvedores apressados ​​ou descuidados. Por exemplo, perdi a conta de quantas vezes vi arquivos IDE nos repositórios. Adicionar sem pensar todos os arquivos em uma linha ao commit não vai terminar bem.

Por outro lado, existem arquivos que frequentemente são esquecidos – por ignorância ou não compreensão de sua finalidade. Por exemplo, o arquivo yarn.lock. Os desenvolvedores não entendem porque precisam dele e, portanto, tem medo de adicioná-lo ao repositório. Ou pensam que este arquivo é importante apenas em seu ambiente local.

Na maioria das vezes, algo dá errado devido à falta de um arquivo, mas o que exatamente depende do arquivo. Por exemplo, se o yarn.lock estiver faltando, você acabará com dependências diferentes para todos os seus ambientes, o que irá gerar facilmente os bugs mais idiotas.

Corrigir o código aleatoriamente

Os desenvolvedores geralmente corrigem bugs casualmente, apenas para serem rápidos. Essa abordagem leva rapidamente ao débito técnico . E isso desmotiva não só quem é obrigado a modificar seu código, mas também toda a equipe.

Claro, às vezes é normal codar “dirty”, quando o objetivo é ter resultados rápidos. Por exemplo, se o código for necessário por um curto período de tempo ou de uma só vez. Mas se o código, que é mantido com muletas, e for usado constantemente, ele voltará para assombrá-lo.

Fonte: Unsplash

Não checar o código sempre

Você já deve ter feito um código de apenas algumas linhas ao menos uma vez na vida. Parecia que simplesmente não havia nada para quebrar. E é verdade: não quebrou aqui, mas em algum outro lugar e estas duas linhas eram as culpadas.

Dito isso, a maioria dos desenvolvedores odeia verificar seu código. Eles não veem o sentido disso, pois consideram uma perda de tempo. Eles estão confiantes de que o código funcionará perfeitamente. Porque é uma pergunta sem resposta.

Não faça isso. Construa fé em seu profissionalismo com testes rigorosos. Isso o ajudará a solucionar erros críticos e a confirmar se seu código funciona exatamente como pretendido.

Fonte: Shutterstock

Inherit with or without

Não há nada de errado com inherit, mas os desenvolvedores estão muito viciados nisso. Este é um erro comum porque fica fácil cair na armadilha da reengenharia. Assim, seu código será tão versátil que você se esquecerá o motivo principal para o qual foi criado. Portanto, lembre-se: a inherit não é um salva-vidas.

Não aprender coisas novas

Não se aprimorar é o erro mais irritante de um desenvolvedor. É claro que para isso é preciso ter tempo, mas dedicar ao menos uma horinha para investir em conhecimento não é pedir muito, certo? Encare como um investimento em si mesmo.

A chave da excelência está na prática, todos sabem disso. Sem isso você não terá habilidades úteis ou não dominará outras linguagens de programação, novas tecnologias e assim por diante.

Subestimar a quantidade de trabalho

“Em poucas horas eu resolvo isso”, você pensou. Mas deu tudo errado e levou mais tempo do que o esperado. Subestimar a quantidade de trabalho é um erro comum, especialmente em equipes com gerenciamento de projeto flexível (como Scrum).

Portanto, se você for um líder de equipe, reserve um tempo não apenas para o desenvolvimento do produto, mas também para estágios adicionais, como testes.

Excesso de confiança

A autoconfiança é ótima quando não o impede de ouvir a opinião de outras pessoas.

Os desenvolvedores super confiantes acabam esquecendo que também cometem erros. Começam a tomar decisões por conta própria, sem consultar ninguém – o que um dia certamente vai acabar mal para eles: ou a qualidade das decisões diminuirá ou os colegas começarão a se sentir desnecessários.

Um desenvolvedor não pode entender tudo de uma vez e fazer tudo igualmente bem. Vale a pena pensar sobre isso.

Resumindo: pense sobre os erros que cometeu nos últimos tempos e aprenda a partir deles. Mas isso não quer dizer para ser um perfeccionista ou ter medo de arriscar, pelo contrário: permita-se errar.

Já pensou em aprender novas linguagens de programação?

Na EBAC você aprende em um curto espaço de tempo SQL, a linguagem de programação mais usada para extrair e analisar informações de bancos de dados. Saiba como escrever queries, realizar consultas, simples e complexas, e modelar dados estruturais de sua empresa sem a ajuda dos desenvolvedores.

Ao fim do curso, você terá domínio em SQL. O projeto final desenvolvido irá enriquecer seu currículo, aumentando as chances de você crescer na carreira. O professor do curso é André Perez, engenheiro de dados na Stone onde atua no desenvolvimento e manutenção de pipeline de dados. Trabalhou na Serasa Experian, onde liderou a modernização da infraestrutura computacional da concessão de crédito, e na Amdocs, onde conduziu projetos de ciência de dados em Tel-Aviv, Israel. Atualmente é aluno de mestrado no Instituto de Ciências Matemáticas e Computação (ICMC/USP) e tutor do MBA em ciência de dados da mesma instituição.