Faça o que eu digo, mas não faça o que eu fiz.

Todo mundo comete erros, isso é normal.

O que observei é que desenvolvedores Juniors, em geral, cometem os mesmos tipos de erro quando estão começando.

Se você se identificar com alguma das situações abaixo, calma, é normal!

A ideia aqui é fazer você perceber que está errando, e ajudar a resolver estes problemas, porque afinal, eu ja passei por tudo isso.

Não testar o próprio código

Esse é o de longe o erro mais comum de todos. Parece um erro besta mas eu já vi acontecer tantas vezes que nem me surpreendo mais.

O que geralmente acontece é que programadores iniciantes querem mostrar serviço — outro erro que vou comentar abaixo — e na hora de entregar uma melhoria ou uma correção eles estão tão apressados que não testam o código que eles mesmos fizeram.

E quando falo sobre testes aqui, não me refiro a testes de aceitação ou testes unitários, mas simplesmente testar o que foi feito.

E ai o que acontece?

Outro desenvolvedor vai fazer o review do código e BOOM , bug, erro 500. Não funciona.

Como parar de fazer isso

Só porque seu código parece estar certo, não significa que está . Por mais simples que seja, teste o que foi feito. Sempre que modificar o código teste o que seu PR está se propondo a fazer.

Ficar apegado ao código

Outro erro comum, muito visto em reviews de código.

Você faz uma classe que é de dar orgulho. Sensacional, você nunca viu uma classe tão bonita assim.

Quando chega a hora do review de código, outro programador chega a conclusão que essa classe é desnecessária. Existe uma solução mais simples , e que já está na base de código, ou seja, você precisa deletar sua classe.

Aí vem a hora do mas, mas, mas . O programador procura qualquer motivo para tentar manter a tão maravilhosa classe na base de código.

Ele está pensando apenas no trabalho que ele fez, mas não em como a base vai ficar com aquele código extra.

Como parar de fazer isso

Como diz o OLX, desapega .

O código não é seu, ele é da equipe .

Você precisa se preocupar em como a base de código vai ficar com aquela modificação, ou seja, o que é melhor pra todo mundo, e não só pra você.

Tentar "mostrar serviço" demais

Vish , esse é complicado.

Um comportamento muito comum em desenvolvedores iniciantes é tentar mostrar serviço demais .

Você chega em um novo emprego e começa a querer resolver tudo que vê pela frente.

Procura por problemas a serem resolvidos, faz código pra tudo e não entende que existe um processo de desenvolvimento , onde problemas a serem resolvidos são listados , descritos e planejados.

As vezes quando você tenta fazer coisa demais está na verdade fazendo coisa de menos, ou seja, atrapalhando a equipe.

Um bom desenvolvedor é aquele cara que você pode contar com que algo vai ser feito no tempo X.

Ou seja, se eu sou um gerente de um time, estou contando que a tarefa Y vai ser feita no tempo esperado, e não que A,B,C que eu não são prioridades estão sendo desenvolvidas enquanto o que é mais importante não está tendo a devida atenção porque você está tentando mostrar serviço fazendo A,B e C.

Como parar de fazer isso

Aderente ao programa.

Acredite no processo e faça o que foi planejado. Não tente fazer mais do que é necessário porque no fim das contas você vai perceber que em software, menos é sempre mais.

Entregar a primeira solução

Outro erro comum, este que também acontece com desenvolvedores mais experientes.

Ontem mesmo eu estava fazendo uma melhoria na base de código onde trabalho. Eu precisava adicionar uma lógica para verificar se um usuário ainda faz parte do projeto.

Antes de fazer o que era necessário eu gastei uns 45 minutos entendendo esta parte do código, que eu não tive muito contato ainda.

Depois disso fiz a primeira solução, que por sinal já estava funcionando e com seus respectivos testes.

Quando revisei meu próprio código — a sacada está aqui — vi algo na arquitetura que não estava legal, então modifiquei.

Olhei novamente, e ainda não estava bom. O que eu fiz? Mudei novamente .

A terceira "modelagem" me agradou, e só assim coloquei o código pra review.

Se eu tivesse entregado a primeira solução, tenho certeza que meus colegas programadores apontariam os mesmos erros que percebi ao fazer o review do meu próprio código.

Como parar de fazer isso

Quando terminar uma solução, saia da mesa e vá tomar um café. Estique as pernas e depois volte para a mesa.

Olhe novamente a solução que você está propondo e faça uma revisão, como se estivesse vendo o código de outro programador.

Veja se aquele código faz sentido, se está fácil de ler, se ele é necessário e se poderia ser mais simples.

Como disse no começo do texto, se você se identificou com alguma situação, essa é a hora de parar de fazer o que está errado.

Tenho certeza que se você parar de fazer tudo isso, será reconhecido como um desenvolvedor mais experiente e, consequentemente, vai subir de nível :)

Fonte: Medium

Link: Clique aqui