Análise de erros comuns cometidos por programadores novatos, pt. 1

Olá Mundo! Depois de aprender tudo o que você precisa saber e finalmente começar a trabalhar como estagiário ou desenvolvedor júnior, provavelmente você pode relaxar, certo? Não. Tudo está apenas começando para você... Você está cercado por muita coisa nova e incompreensível. Como você não estraga tudo logo de cara? É sobre isso que vamos falar hoje. Neste artigo, quero analisar erros comuns de novatos e dar alguns conselhos, com base em minha própria experiência, sobre como evitá-los. Então, vamos começar sem mais delongas:

1. Medo de buscar ajuda de colegas mais experientes

Somos todos humanos. Todos nós temos medo de parecer estúpidos, especialmente aos olhos de nossos colegas novos e mais experientes. Quando os desenvolvedores aceitam seu primeiro emprego, muitas vezes são guiados por esse medo e, com uma voz pesada, se fecham em si mesmos, tentando descobrir tudo por conta própria. Além disso, alguém pode estar rodeado de colegas mais experientes, que, por sua vez, são capazes de apontá-lo na direção mais promissora, ajudando a evitar mais erros e "bates na cabeça" desnecessários. Portanto, lembre-se: não tenha medo de fazer perguntas. Você é iniciante e todos entendem isso perfeitamente. Quando você pedir, ninguém vai bater em você com paus. Talvez aconteça até o contrário: você se tornará amigo de seus colegas mais rapidamente e começará a ter uma comunicação mais ativa com eles. EU' Direi ainda mais: quanto mais você perguntar e discutir várias questões técnicas, mais rápido será capaz de se livrar de sua pele verde de novato e se tornar um especialista em seu campo. E mais um conselho. Não seja um estranho paraStackOverflow . Estou falando especificamente sobre fazer perguntas sobre este recurso. Por um lado, leva algum tempo para obter uma resposta à sua pergunta. Mas, por outro lado, você pode aprender rapidamente várias abordagens para resolver seu problema e analisá-lo de um ângulo ligeiramente diferente. Também quero observar que há benefícios práticos em escrever comentários/respostas e perguntas esclarecedoras sobre questões do StackOverflow de outros desenvolvedores: você tem a chance de debater e se aprofundar nos problemas, sem mencionar um aumento de carma.

2. Não tentar buscar informações por conta própria

Este erro pode ser considerado o reverso do anterior.Aqui, quero dizer quando você começa a importunar seus colegas e conhecidos sobre todos os problemas ou contratempos que encontra. Perguntar é bom, mas não exagere nas perguntas. Caso contrário, as pessoas podem simplesmente achar você irritante. Se você ficar confuso com alguma coisa, a primeira coisa a fazer é exercitar suas habilidades de pesquisa no melhor mecanismo de busca - o Google. Alguém já encontrou a esmagadora maioria dos erros incompreensíveis e outros problemas. E você ficará bastante surpreso se pesquisar sua pergunta no Google e ver o número de pessoas que estão familiarizadas com um problema semelhante e que já receberam respostas exaustivas que você pode aplicar em seu próprio trabalho. É por isso que você costuma ouvir seus colegas responderem com "Google it". Vestir' Não se ofenda com esta resposta - seu colega não é seu professor pessoal que deve transmitir todas as sutilezas de seu campo de trabalho. As extensões infinitas da Internet serão seu mentor. Às vezes, os programadores também são chamados depessoas com faixa preta na pesquisa do Google . Portanto, se tivermos um "soluço", primeiro pesquisaremos o problema no Google. Se não for possível encontrar uma solução (isso é raro, mas acontece), só então começamos a perguntar aos colegas. As perguntas imediatas são para obter conselhos sobre qual abordagem você deve escolher para resolver um problema mais do que o que você faria quando encontrasse uma lombada ou uma mensagem de erro incompreensível. Afinal, eles podem ver além de sua abordagem preferida e prever imediatamente aonde qualquer abordagem levará a longo prazo.

3. Copiar e colar cegamente

Mas pesquisar problemas e suas soluções no Google tem suas armadilhas. Por exemplo, copiar e colar cegamente .Isso geralmente acontece quando você encontra um problema semelhante (mas talvez não exatamente o mesmo) e uma solução associada, por exemplo, no StackOverflow. Você pega esta solução e copia e cola sem se aprofundar nos detalhes. E então você ou seus colegas de trabalho descobrem alguns bugs estranhos ou comportamento incorreto em seu código. E ninguém pode adivinhar imediatamente de onde eles vieram. Eventualmente, é claro, o local com o código copiado será encontrado e você definitivamente não será elogiado por sua solução. Portanto, ao encontrar uma solução pronta no StackOverflow (ou em qualquer outro lugar), você deve primeiro entender completamente o quê, como e por quê. Talvez pesquise no Google a funcionalidade relevante e leia a documentação dela. E somente depois de fazer isso você deve adicioná-lo ao seu projeto.

4. Ficar com a solução errada

Ao escrever uma solução, às vezes você descobrirá que ela está se tornando cada vez mais complicada, chegando a um beco sem saída. E então você tenta tornar a solução ainda mais elaborada para de alguma forma fazê-la funcionar, em vez de procurar outra alternativa mais adequada. Talvez você sinta que investiu muito tempo e esforço e, portanto, decidiu que, não importa o que aconteça, você não desistirá e resolverá o problema com sua abordagem existente. Essa não é a atitude certa. Pelo menos na programação. Quanto mais cedo você tentar uma abordagem diferente, mais tempo economizará no final. Portanto, não tenha medo de experimentar e tentar outras abordagens, independentemente da quantidade de tempo que você investiu na atual. Além do mais, ao tentar várias abordagens e mergulhar mais profundamente no assunto, você

5. Medo de fazer perguntas sobre sua tarefa atual

Trabalhar em um projeto de desenvolvimento de software geralmente se resume a executar tarefas específicas. Por exemplo, em Jira. Essas tarefas nem sempre são delineadas de forma clara e detalhada. As descrições de tarefas geralmente são escritas por líderes de equipe, que também são meros mortais. Eles podem se esquecer de adicionar algo ou não levar em conta o fato de você não estar familiarizado com esta ou aquela funcionalidade. Ou talvez você não tenha acesso ao projeto (por exemplo, acesso ao banco de dados, servidor de log e assim por diante). E agora, você recebeu a tarefa, estudou-a por mais de duas horas, mas ainda está sentado lá, olhando para a tela em perplexidade. Em vez de continuar tentando entender isso sem sucesso, você deve começar a pedir esclarecimentos ou orientações de quem criou a tarefa. Por exemplo, no aplicativo que sua equipe usa para comunicação (por exemplo, Microsoft Teams), você pode fazer perguntas ou comentários diretos sobre a tarefa. Por um lado, se você escrever sua pergunta em uma mensagem pessoal, provavelmente obterá uma resposta mais rápida, pois a pessoa verá sua pergunta imediatamente. Por outro lado, ao fazer uma pergunta no Jira, você estabelece uma prova de que está fazendo algo, ou seja, analisando o problema. Existe uma maneira de acelerar esse processo: faça sua pergunta em um comentário no Jira e depois em uma DM, coloque um link no seu comentário e peça para dar uma olhada.

6. Colocar expectativas irrealistas no líder da equipe

Novamente, este é o outro lado do ponto anterior. O líder da equipe é o chefe de uma equipe de desenvolvimento. Como regra, o líder de sua equipe passa a maior parte do tempo em vários tipos de comunicação. No entanto, ele também escreve código para não esquecer tudo sobre programação. Como você pode entender, a vida de um líder de equipe é muito ocupada. Puxar a manga do líder da equipe toda vez que você precisa espirrar obviamente não será agradável. Imagine cada membro da equipe bombardeando o líder com um monte de perguntas. Isso poderia deixar qualquer um louco, certo? E se você acumular muitas perguntas, o líder de sua equipe terá que gastar muito tempo respondendo a você. O que pode ser feito para reduzir o número de perguntas direcionadas ao líder da equipe:

• Explore a documentação do projeto com mais profundidade para reduzir o número de pontos cegos.
• Direcione suas perguntas para os outros membros da equipe. Eles podem estar tão familiarizados com essa funcionalidade quanto o lead, ou possivelmente até mais, já que a funcionalidade provavelmente foi escrita por um deles.

Como alternativa, você pode consultar as anotações no IDE para quem e quando o código em uma linha específica foi alterado pela última vez. É exatamente assim que você pode descobrir quem é a pessoa mais adequada para fazer sua pergunta. Como você provavelmente já percebeu, quando se trata de perguntas para o líder da equipe, assim como para perguntas aos colegas, você precisa tentar encontrar um meio-termo — não tenha medo de fazer perguntas, mas também não faça muitas deles.

7. Medo de revisões de código

Uma revisão de códigoé um estágio que acontece antes de você enviar seu código para um aplicativo comum (para uma ramificação compartilhada, por exemplo, master ou dev). Essa verificação é realizada por um desenvolvedor que não está envolvido na tarefa, cujos novos olhos podem detectar erros, imprecisões ou falhas em seu estilo de código que passaram despercebidos quando você escreveu seu código inicialmente. Se houver críticas, elas são deixadas como comentários em algumas partes do código. Nesse caso, o desenvolvedor que escreveu o código deve corrigir os erros identificados na revisão (ou discutir suas decisões com o revisor, possivelmente convencendo-o de que elas estão corretas). Em seguida, o código é enviado para revisão repetidas vezes até que o revisor não tenha mais comentários. O revisor atua como um "gateway" antes que o código seja confirmado. O desafio é que muitos programadores iniciantes percebem a revisão de código como crítica e condenação. Eles não gostam de revisões de código e têm medo delas. Eles não deveriam. As revisões de código são exatamente o que nos permite melhorar nosso código. Afinal, recebemos informações importantes sobre o que estamos fazendo de errado e no que vale a pena prestar atenção. Você deve considerar cada revisão de código como parte da curva de aprendizado, algo que pode ajudá-lo a melhorar. Quando alguém comenta sobre seu código, ele ou ela está compartilhando experiências e práticas recomendadas com você. Pessoalmente, não acredito que você possa se tornar um bom programador sem obter revisões de código. Porque você nem está ciente da qualidade do seu código e se um estranho experiente apontaria erros. Não apreciam revisões de código e têm medo delas. Eles não deveriam. As revisões de código são exatamente o que nos permite melhorar nosso código. Afinal, recebemos informações importantes sobre o que estamos fazendo de errado e no que vale a pena prestar atenção. Você deve considerar cada revisão de código como parte da curva de aprendizado, algo que pode ajudá-lo a melhorar. Quando alguém comenta sobre seu código, ele ou ela está compartilhando experiências e práticas recomendadas com você. Pessoalmente, não acredito que você possa se tornar um bom programador sem obter revisões de código. Porque você nem está ciente da qualidade do seu código e se um estranho experiente apontaria erros. Não apreciam revisões de código e têm medo delas. Eles não deveriam. As revisões de código são exatamente o que nos permite melhorar nosso código. Afinal, recebemos informações importantes sobre o que estamos fazendo de errado e no que vale a pena prestar atenção. Você deve considerar cada revisão de código como parte da curva de aprendizado, algo que pode ajudá-lo a melhorar. Quando alguém comenta sobre seu código, ele ou ela está compartilhando experiências e práticas recomendadas com você. Pessoalmente, não acredito que você possa se tornar um bom programador sem obter revisões de código. Porque você nem está ciente da qualidade do seu código e se um estranho experiente apontaria erros. o que está fazendo de errado e no que vale a pena prestar atenção. Você deve considerar cada revisão de código como parte da curva de aprendizado, algo que pode ajudá-lo a melhorar. Quando alguém comenta sobre seu código, ele ou ela está compartilhando experiências e práticas recomendadas com você. Pessoalmente, não acredito que você possa se tornar um bom programador sem obter revisões de código. Porque você nem está ciente da qualidade do seu código e se um estranho experiente apontaria erros. o que está fazendo de errado e no que vale a pena prestar atenção. Você deve considerar cada revisão de código como parte da curva de aprendizado, algo que pode ajudá-lo a melhorar. Quando alguém comenta sobre seu código, ele ou ela está compartilhando experiências e práticas recomendadas com você. Pessoalmente, não acredito que você possa se tornar um bom programador sem obter revisões de código. Porque você nem está ciente da qualidade do seu código e se um estranho experiente apontaria erros.

8. Propensão para decisões misteriosas

Muitas tarefas/problemas podem ter várias soluções diferentes. E de todas as soluções disponíveis, os iniciantes tendem a usar as mais complexas e misteriosas. E isso faz sentido: programadores novatos aprenderam ontem mesmo muitos algoritmos, padrões e estruturas de dados diferentes, então suas mãos estão ansiosas para implementar alguns deles. Acredite em mim, eu era assim, então sei do que estou falando :) Tive uma situação em que estava implementando alguma funcionalidade por muito tempo. Acabou sendo muito, muito complicado. Então o desenvolvedor sênior reescreveu meu código. Claro, eu estava muito interessado em ver o que e como ele mudou. Eu olhei para sua implementação e fiquei surpreso com o quão simples era. E havia três vezes menos código. E também surpreendentemente, os testes automatizados para esta funcionalidade não foram removidos ou alterados! Em outras palavras, a lógica geral permaneceu a mesma. A partir disso, cheguei à conclusão de queas soluções mais engenhosas são sempre simples . Após essa percepção, a codificação tornou-se muito mais fácil e a qualidade do meu código saltou para um nível significativamente mais alto. Então, quando vale a pena aplicar padrões de design e algoritmos sofisticados, você pergunta? Ao aplicá-los será a solução mais simples e compacta.

9. Reinventando a roda

A roda é uma solução durável que foi inventada há muito tempo. Nesse antipadrão, o desenvolvedor implementa sua própria solução proprietária para um problema que já foi resolvido. Às vezes, essas soluções existentes são melhores do que as que o programador apresenta. Via de regra, reinventar a roda acarretará perda de tempo e diminuição da produtividade, pois a solução que você encontrar pode estar longe de ser a melhor ou, bem, você pode não encontrar nenhuma. Dito isso, não podemos descartar a possibilidade de criar nossa própria solução independente: se o fizéssemos, tudo o que restaria seria a programação de copiar e colar. O programador deve orientar-se devidamente pelas tarefas específicas de programação que se apresentam de forma a resolvê-las com competência e prontidão, quer recorrendo a soluções prontas, quer criando soluções à medida. Por um lado, nas universidades e nos cursos online, somos bombardeados com vários tipos de tarefas que parecem destinadas a nos ajudar a reinventar a roda. Mas apenas à primeira vista: o objetivo real aqui é desenvolver o pensamento algorítmico e um domínio mais profundo da sintaxe da linguagem. Essas tarefas também ajudam você a entender melhor algoritmos e estruturas de dados e fornecem habilidades para implementar contrapartes mais sofisticadas, se necessário (isso às vezes é necessário, mas é extremamente raro). Na vida real, você não precisa inventar sua própria roda na esmagadora maioria dos casos, pois rodas que atendem às suas necessidades já existem há muito tempo. Talvez sua inexperiência o impeça de saber sobre a existência de implementações da funcionalidade de que você precisa. É aqui que você precisa seguir o conselho dado no primeiro ponto deste artigo, ou seja, peça ajuda a colegas mais experientes. Eles poderão orientá-lo (por exemplo, apontar a direção certa em sua pesquisa no Google) ou sugerir uma implementação específica (por exemplo, alguma biblioteca).

10. Falha ao escrever testes

Todos os novatos não gostam de escrever testes. Mas por que devemos destacar os novatos aqui? Os desenvolvedores mais experientes também não gostam de escrever testes, mas entendem melhor por que os testes são necessários. Quando você está completamente verde, você se pergunta por que deveria escrevê-los. Tudo funciona, então não pode haver erros. Mas como você garante que suas alterações não quebrarão algo em outro lugar do sistema? Seus colegas não vão gostar se você forçar mudanças que causem mais mal do que bem. É aqui que os testes vêm em nosso socorro. Quanto mais o código de um aplicativo for coberto por testes, melhor (isso é chamado de cobertura de código ou cobertura de teste). Se o aplicativo tiver uma boa cobertura de teste, você poderá executar todos os testes para encontrar locais que serão corrompidos pelo seu código. E como eu disse no exemplo acima, quando o desenvolvedor sênior refatorou o código, os testes não falharam. Isso porque a lógica geral não mudou. Usamos testes para demonstrar se a lógica de determinada funcionalidade mudou ou não. Portanto, mesmo que você não goste de escrever testes, eles são definitivamente úteis e valem o tempo gasto neles.

11. Excesso de comentários

Muitos desenvolvedores sofrem de perfeccionismo e os novatos não são exceção. Às vezes, eles manifestam apenas uma faceta dessa propensão quando começam a comentar tudo e todos. Mesmo fazendo comentários desnecessários, porque o código é tão óbvio:

Cat cat = new Cat(); // Cat object

Nem todos os programadores iniciantes percebem imediatamente que comentar o código nem sempre é bom, porque os comentários supérfluos desordenam o código e dificultam a leitura. E se o código mudar, mas os comentários antigos não forem atualizados? Então, eles apenas nos enganarão e nos confundirão. Então, por que fazer tal comentário? Normalmente, um código bem escrito não precisa ser comentado , pois tudo nele já é óbvio e legível. Se você precisar escrever um comentário, já estragou a legibilidade do código e está tentando remediar a situação de alguma forma. A melhor abordagem é escrever um código legível desde o início, ou seja, um código que não precise de comentários. Também não posso deixar de mencionar a necessidade de seguir as convenções de nomenclatura corretas para métodos, variáveis ​​e classes. Aqui está a minha regra: O melhor comentário é nenhum comentário ou nomeação correta que descreva claramente a funcionalidade em seu aplicativo.

12. Nomenclatura incorreta

Os novatos são rápidos e soltos em sua nomeação de classes, variáveis, métodos, etc. Por exemplo, criando uma classe cujo nome não descreva seu propósito. Ou eles declaram uma variável com um nome curto, algo como x . Eles quando mais duas variáveis ​​nomeadas n e ysão criados, lembrar pelo que x é responsável torna-se muito difícil. Diante dessa situação, é preciso pensar bem no código, analisando-o ao microscópio (talvez usando um depurador), estudando a funcionalidade para simplesmente entender o que está acontecendo. É aqui que as convenções de nomenclatura corretas que mencionei acima vêm em nosso auxílio. Nomes corretos melhoram a legibilidade do código, reduzindo assim o tempo necessário para se familiarizar com o código, porque usar um método é muito mais fácil quando seu nome descreve aproximadamente sua funcionalidade. Tudo no código consiste em nomes (variáveis, métodos, classes, objetos, arquivos, etc.), então esse ponto se torna muito importante ao criar um código limpo e correto. Você deve se lembrar que o nome deve transmitir significado, por exemplo, por que a variável existe, o que ela faz, e como é usado. Observarei mais de uma vez que o melhor comentário para uma variável é dar a ela um bom nome. Para um estudo mais aprofundado sobre comentários e nomenclatura correta, recomendo a leitura dos clássicos atemporais:"Clean Code: A Handbook of Agile Software Craftsmanship" por Robert Martin . Com essa nota, a primeira parte deste artigo (minhas reflexões) chegou ao fim. Continua...