Análise de erros típicos de programadores iniciantes: parte 1

Olá Mundo! Depois de aprender tudo o que precisa e finalmente ser contratado como estagiário ou júnior, provavelmente você poderá relaxar, certo? Não importa como seja! Tudo está apenas começando... Há muitas coisas novas e incompreensíveis ao seu redor, e como não estragar assim logo de cara? É sobre isso que falaremos hoje. Neste artigo, quero examinar os erros comuns cometidos por iniciantes e dar algumas dicas de minha própria experiência sobre como evitá-los. Então, vamos começar sem mais delongas:

1. Medo de pedir ajuda a colegas mais experientes

Somos todos humanos e todos temos medo de parecer estúpidos, especialmente aos olhos dos nossos colegas recém-formados e mais experientes. Depois de conseguirem seu primeiro emprego, os desenvolvedores muitas vezes cedem a esse medo e se fecham inconsolavelmente em si mesmos, tentando descobrir tudo por conta própria. Ao mesmo tempo, uma pessoa pode estar rodeada de colegas mais experientes, que, por sua vez, poderão orientá-la inicialmente pelo caminho mais correto, o que ajudará a evitar mais erros e “solavancos” 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 seja até o contrário: você fará amizade com seus colegas mais rapidamente e começará a se comunicar mais ativamente com eles. Direi mais: quanto mais você perguntar e discutir várias questões técnicas, mais rápido você poderá sair do lugar de um iniciante verde e se tornar um especialista em sua área. E mais um conselho. Não negligencie StackOverFlow . Neste contexto, quero dizer fazer perguntas sobre este recurso. Por um lado, leva algum tempo para obter uma resposta à sua pergunta. Mas, por outro lado, você pode aprender imediatamente sobre diversas abordagens para resolver o problema atual e observá-lo de uma perspectiva ligeiramente diferente. Gostaria também de ressaltar que escrever comentários-respostas, esclarecer dúvidas sobre StackOverFlow de outros desenvolvedores, além de um plus no carma, tem um benefício prático: você tem a oportunidade de discutir e entender esse assunto mais profundamente.

2. Não tente procurar informações por conta própria

Talvez este erro seja o reverso do anterior. Quero dizer, quando você começa a atacar seus colegas e conhecidos com cada problema ou problema. Perguntar é bom, mas você não deve exagerar nas perguntas, caso contrário você pode ficar entediado. A primeira coisa a fazer caso surja algum ponto incompreensível é aplicar suas habilidades de busca no melhor mecanismo de busca - o Google. Alguém já encontrou a grande maioria de erros incompreensíveis e outros problemas. E você ficará bastante surpreso se pesquisar no Google e ver quantas pessoas estão familiarizadas com um problema semelhante e que já receberam respostas abrangentes e adequadas para uso em seu trabalho. Com base nisso, muitas vezes você pode ouvir um colega responder a uma pergunta - “Google it”. Você não deve se ofender com esta resposta, porque afinal seu colega não é um professor particular que deveria transmitir todos os meandros da sua área de trabalho. As extensões infinitas da Internet irão ajudá-lo com essa orientação. Às vezes, um programador também é chamado de faixa preta na pesquisa do Google . Portanto, quando ficamos presos, primeiro pesquisamos o problema no Google e, se nenhuma solução for encontrada (raramente, mas acontece), começamos a perguntar aos nossos colegas. Vale a pena perguntar imediatamente, não quando houver algum tipo de falha ou erro incompreensível, mas na hora de escolher uma abordagem para resolver um problema. Afinal, eles podem ver além da sua e dizer imediatamente como esta ou aquela abordagem pode resultar no longo prazo.

3. Copiar e colar às cegas

Mas pesquisar o problema no Google e, consequentemente, sua solução tem suas armadilhas. Por exemplo, copiar e colar às cegas . Isso geralmente acontece quando você encontra um problema semelhante (mas talvez não exatamente o mesmo) e abaixo dele, por exemplo, no StackOverFlow existe uma solução. Você pega essa solução, copia e cola você mesmo, sem entrar em muitos detalhes. E então você ou seus colegas de projeto descobrem alguns bugs estranhos ou comportamento incorreto de sua funcionalidade. E imediatamente ninguém tem ideia de onde vêm as pernas. Então, é claro, um local com esse código será encontrado e você definitivamente não será elogiado por essa decisão. Portanto, ao encontrar uma solução pronta no StackOverFlow (ou em outro lugar), antes de tudo você deve analisá-la detalhadamente, o que é, como e por quê. Talvez pesquise no Google essa funcionalidade e consulte a documentação dela. E só depois implemente-o em seu projeto.

4. Lançar a solução errada

Ao escrever uma solução, às vezes acontece que ela se torna cada vez mais complexa e acaba chegando a um beco sem saída. E você está tentando complicar cada vez mais para de alguma forma resolver esse problema usando essa abordagem, em vez de tentar procurar outra alternativa mais viável. Talvez você simplesmente sinta pena da energia e do tempo que gastou e então decida: não importa o que aconteça, não desista, mas resolva o problema desta forma. Esta não é totalmente a abordagem correta. Pelo menos na programação. Quanto mais cedo você tentar uma abordagem diferente, mais tempo acabará economizando. Portanto, não tenha medo de experimentar e tentar outras abordagens, apesar da quantidade de tempo que você investiu nesta. Além disso, esses serão pontos para sua experiência, já que você experimentará diversas abordagens e estudará melhor essa área.

5. Medo de fazer perguntas sobre a tarefa atual

O trabalho em um projeto geralmente se resume à conclusão de algumas tarefas (Tarefas). Por exemplo, em Jira . E essas tarefas nem sempre são descritas de forma detalhada e clara. Geralmente são escritos por líderes de equipe, e também são pessoas, se isso acontecer. Eles também podem esquecer de adicionar algo ou não levar em conta que você não está muito familiarizado com esta ou aquela funcionalidade. Bem, ou você não tem acesso ao projeto (por exemplo, acesso ao banco de dados, ao servidor de log e assim por diante). E agora, tendo recebido a tarefa, tendo estudado por mais de algumas horas, você ainda senta e olha para a tela perplexo. E em vez de continuar descobrindo isso sem sucesso, você deve começar a fazer perguntas orientadoras/esclarecedoras ao criador desta tarefa. Digamos, em um aplicativo que você usa para comunicação em equipe (por exemplo, Microsoft Teams) ou diretamente como um comentário nesta tarefa. Por um lado, se você escrever uma pergunta em uma mensagem pessoal, muito provavelmente a resposta será mais rápida, pois a pessoa verá a pergunta na hora. Por outro lado, ao fazer uma pergunta no Jira, você tem evidências de que está fazendo algo, ou seja, analisando o problema. Existe uma maneira de agilizar esse processo: faça uma pergunta como comentário no Jira e envie um link para esse comentário em mensagem privada com um pedido de consulta.

6. Esperar muito do líder da equipe

Novamente, este é o outro lado do ponto anterior. Um líder de equipe é uma pessoa que lidera uma equipe de desenvolvimento. Como regra, esse membro da equipe gasta a maior parte do tempo em vários tipos de comunicação. E ao mesmo tempo, ele também escreve código para não esquecer o que é tudo. Bem, como você entende, este é um personagem muito ocupado. E espasmos excessivos a cada espirro obviamente não o deixarão feliz. Imagine se cada membro da equipe o bombardeasse com um monte de perguntas. Então você pode enlouquecer, certo? E não será surpresa que com muitas perguntas de sua parte ele te responda por muito tempo. O que você pode fazer para reduzir o número de perguntas ao líder da equipe:

• Estude mais a fundo a documentação deste projeto para reduzir o número de pontos cegos.
• Faça perguntas a outros membros da equipe. É bem possível que eles estejam tão familiarizados com essa funcionalidade quanto o líder, ou até mais, porque muito provavelmente um deles escreveu essa funcionalidade.

Alternativamente, no IDE você pode ver as anotações: quem e quando alterou o código pela última vez em uma determinada linha. Assim saberemos quem estaria mais correto em fazer esta pergunta. Como você provavelmente já entendeu, ao fazer perguntas ao líder da equipe, bem como ao fazer perguntas aos colegas, você precisa tentar manter o meio-termo - não ter medo de fazer perguntas, mas também não incomodá-las com um número excessivo.

7. Medo de revisões de código

Revisão de código ou revisão de código é uma etapa antes do upload do código para um aplicativo comum (para uma ramificação comum, por exemplo, master ou dev). Essa verificação é realizada por um desenvolvedor não relacionado a esta tarefa, que pode, com um novo olhar, descobrir erros, imprecisões ou deficiências no estilo do código que passaram despercebidas na fase inicial de desenvolvimento. Se houver comentários, eles serão deixados como comentários em determinadas seções do código. Neste caso, o desenvolvedor que executou esta tarefa deverá corrigir os erros de acordo com a revisão (ou discutir suas decisões com o revisor, talvez convencendo-o do acerto de sua decisão). Em seguida, envie-o de volta para revisão e assim sucessivamente até que o revisor não tenha mais comentários. O revisor serve como um “filtro” antes de enviar o código. Assim, muitos programadores novatos percebem a revisão de código como crítica e condenação. Eles não a apreciam e têm medo dela, e isso é errado. É a revisão do código que nos permite melhorar nosso código. Afinal, recebemos informações importantes sobre o que estamos fazendo de errado e no que devemos prestar atenção. É necessário olhar cada revisão de código como parte do aprendizado, algo que pode te ajudar a melhorar. Quando uma pessoa deixa comentários no seu código, ela compartilha com você sua experiência, suas melhores práticas. Quanto a mim, você não pode se tornar um bom programador sem fazer uma revisão de código. Porque você não sabe quão bom é o seu código e se há algum erro nele do ponto de vista de uma pessoa experiente de fora.

8. Tendência a soluções obscuras

Freqüentemente, diferentes tarefas/problemas podem ter várias soluções diferentes. E de todas as soluções disponíveis, os iniciantes costumam usar as mais complexas e “abstrusas”. E é verdade: se um programador novato ontem estudou muitos algoritmos, padrões e estruturas de dados diferentes, então suas mãos estão ansiosas para implementar um deles. Sim, e quero, por assim dizer, me declarar. Acredite, eu também era assim e sei do que estou falando :) Tive uma situação em que passei muito tempo escrevendo uma funcionalidade que acabou se revelando muito, muito complexa. Em seguida, foi reescrito por um desenvolvedor de nível Sênior+. Claro, eu estava interessado em ver o que e como ele mudou. Observei sua implementação e fiquei surpreso ao ver como ela se tornou muito mais simples. E o código ficou três vezes menor. E ao mesmo tempo, os testes para esta funcionalidade não mudaram e não falharam! Ou seja, a lógica geral permanece a mesma. Disto cheguei à conclusão que: as soluções mais engenhosas são sempre simples . Após essa constatação, escrever código tornou-se muito mais fácil e visivelmente de mais alto nível. Pois bem, quando vale a pena usar padrões e algoritmos, você pergunta? Então, ao utilizá-los será a forma mais simples e compacta.

9. A invenção das bicicletas

Este conceito também é conhecido como a invenção da roda. A sua essência reside no facto de o desenvolvedor implementar a sua própria solução para um problema para o qual já existem soluções, e muitas vezes melhores do que as inventadas pelo programador. Via de regra, inventar a própria bicicleta acarretará perda de tempo e diminuição da eficiência do trabalho do desenvolvedor, pois pode não ser encontrada uma solução que esteja longe de ser a melhor, ou pode nem ser encontrada. Ao mesmo tempo, não podemos descartar a possibilidade de uma decisão independente. O programador deve navegar corretamente pelas tarefas que lhe possam surgir para resolvê-las com competência e tempo hábil, utilizando soluções prontas ou inventando as suas próprias. Por um lado, nas universidades e nos cursos somos bombardeados com vários tipos de tarefas que deveriam nos ajudar a criar bicicletas. Mas isso é apenas à primeira vista. Na verdade, o objetivo disso é desenvolver o pensamento algorítmico e um domínio mais profundo da sintaxe da linguagem. E essas tarefas também ajudam a compreender melhor algoritmos/estruturas e, se necessário, dão-lhes as habilidades para implementar seus análogos avançados (mas isso raramente é necessário). Na vida real, na grande maioria dos casos, não há necessidade de inventar a sua própria roda, uma vez que existem há muito tempo análogos que satisfazem as nossas necessidades. Talvez, pela sua experiência, você não saiba da existência de implementações desta ou daquela funcionalidade de que necessita. É aqui que você precisa aproveitar o primeiro ponto deste artigo, ou seja, pedir ajuda a colegas mais experientes. Eles poderão orientá-lo (por exemplo, aconselhar em que direção o Google) ou sugerir uma implementação específica (determinada biblioteca).

10. Não escreva testes

Todos os iniciantes não gostam de escrever testes. E quanto aos novatos: os não novatos também não gostam de escrever testes, mas entendem melhor por que isso é necessário. Quando você está completamente verde, você pensa: por que escrevê-los? Tudo funciona e não pode haver erros. Mas como você pode ter certeza de que suas alterações não danificarão algo em outra parte do sistema? Seus colegas não apreciarão se você promover mudanças que mais atrapalham do que beneficiam. É aqui que os testes vêm em socorro. Quanto mais um aplicativo for coberto por testes, melhor (também chamado de percentual de cobertura). Se a aplicação estiver bem coberta pelos testes, ao executá-los todos você poderá encontrar locais que podem ser quebrados pelas suas alterações. E como disse no exemplo acima, ao refatorar a funcionalidade os testes não falharam, e tudo porque a lógica geral não mudou. Isso significa que os testes também podem mostrar se a lógica de uma determinada funcionalidade mudou ou não. Portanto, mesmo que você não goste de escrever testes, eles trazem benefícios indiscutíveis e valem o tempo gasto neles.

11. Comentários excessivos

Muitos desenvolvedores sofrem de perfeccionismo e os iniciantes não são exceção. Mas às vezes um efeito colateral desse desejo é que eles começam a comentar sobre tudo e todos. Mesmo o que não é necessário, porque é tão óbvio:

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

Nem todos os programadores iniciantes percebem imediatamente que comentar o código nem sempre é uma coisa boa, porque o código ficará muito mais confuso e difícil de ler. E se o código foi alterado, mas não houve comentários sobre isso? Acontece que ele nos enganará e apenas nos confundirá. Por que então tal comentário? Normalmente, um código bem escrito não precisa de comentários , pois tudo nele já é óbvio e legível. Se você escrever um comentário, significa que você já estragou a legibilidade do código e está tentando de alguma forma amenizar a situação. A melhor abordagem seria escrever inicialmente um código legível que não precisasse ser complementado com comentários. Também não pude deixar de mencionar a nomenclatura correta de métodos, variáveis ​​​​e classes, ou seja, uma regra que eu mesmo sigo: O melhor comentário é a ausência de comentário, e em vez disso - a nomenclatura correta que descreve claramente isto ou aquilo funcionalidade em seu aplicativo.

12. Nomenclatura incorreta

Freqüentemente, os iniciantes falsificam os nomes de classes, variáveis, métodos, etc. Por exemplo, quando criam uma classe cujo nome não descreve de forma alguma sua finalidade. Ou uma variável é criada com um nome curto, algo como x , e quando mais duas variáveis ​​chamadas n e y são criadas , fica muito difícil lembrar o que x faz . Nesses casos, você deve pensar cuidadosamente no código e estudar essa funcionalidade sob um microscópio (talvez usando um depurador) para simplesmente entender o que está acontecendo ali. É aqui que a nomenclatura correta no código que mencionei acima vem em nosso auxílio. Nomes corretos melhoram a legibilidade do código, economizando tempo de familiarização, pois é muito mais fácil utilizar um método em que o nome descreve aproximadamente sua funcionalidade. No código, tudo consiste em nomes (variáveis, métodos, classes, objetos de arquivo, etc.), este ponto se torna muito importante na hora de criar um código correto e limpo. Vale lembrar que o nome deve transmitir o significado: por que, por exemplo, a variável existe, o que ela faz e como é utilizada. E observarei repetidas vezes que o melhor comentário para descrever uma variável é seu nome correto. Para um estudo mais aprofundado dos comentários e nomenclatura correta, aconselho a leitura do clássico atemporal: “Código limpo. Criação, análise e refatoração”, Robert Martin . Com esta nota, a primeira parte deste artigo (reflexões) chegou ao fim. Continua…