Você não é um mal desenvolvedor, apenas possui maus hábitos

Esse artigo é uma tradução livre de 4 Habits That Make You an Inefficient Developer por Daan.

Todos nós temos. Maus hábitos. Nenhuma pessoa nesta terra é perfeita.

Um desenvolvedor com maus hábitos pode ser ter sua eficiência seriamente prejudicada, e eles podem afetar as pessoas que estão a sua volta.

Seus hábitos determinarão seu futuro. - Jack Canfield

Se você quer ser um desenvolvedor melhor, acabe com os maus hábitos. Se assim o fizer, garanto que sua eficiência aumentará drasticamente.

Vamos lá ver esses maus hábitos que você deveria corrigir.

Dizer “sim” pra tudo

Deixe-me começar dizendo que é admiravelmente humilde e altruísta dizer sim a tudo. Isso significa que você está disposto a ajudar outras pessoas, provavelmente às suas próprias custas.

Mas o problema de dizer “sim” pra tudo, é que você mata a sua produtividade. No final do dia, provavelmente você precisará entregar algum código.

Entenda… eu não estou dizendo para você não ajudar outros devs. Eu só estou dizendo que você não deve destruir sua produtividade. Alguns desenvolvedores têm a tendência de fazer perguntas demais — pra qualquer coisinha a pessoa já vem na sua mesa pedir ajuda.

Paulo Coelho acertou em cheio quando disse:

Quando você disse “sim” aos outros, tenha certeza que de que não dirá “não” a você mesmo.

Se você encontrar dificuldades em falar “não”, talvez ajude em permitir que as pessoas venham falar com você diretamente apenas algumas vezes — conseguindo um tempo pra se focar, para concluir seu trabalho.

Isso também força as pessoas que procurem uma solução por elas mesmas, antes de irem correndo falar com você. Se elas realmente não conseguirem uma solução, elas poderão escrever a pergunta ou problema. Eventualmente, elas aparecem com uma lista de perguntas em sua mesa. Isso economiza muito tempo, pois você será interrompido apenas uma vez em vez de ser interrompido por cada pergunta da lista.

Sua definição de “Pronto” provavelmente não é “Pronto” de verdade

Porque a palavra “pronto” diverge tanto entre os devs e outras pessoas, é que elas tem outras 10.000 coisas para fazer. Quando trabalhamos em um time ágil, por exemplo, os devs precisam finalizar a sprint. Isso é feito em um período fechado. Eles sentem que não podem perder seu tempo com nada.

Apesar da definição de “pronto” divergir, provavelmente deve incluir mais do que escrever um código bonitinho pra uma funcionalidade bacana. Sempre que você pensar em “pronto”, você deveria pelo menos levar os seguintes pontos em consideração:

• Você refatorou o código? E se você tiver um olhar crítico no código que produziu, você julga que outros desenvolvedores conseguirão entendê-lo? Se para alguma dessas respostas por “não”, corrija;

• E sobre documentação? Você precisa documentar essa feature? Você disse ao tester como testar essa funcionalidade? Existe algum pré-requisito que o tester deve saber? Dizer ao tester como uma funcionalidade deveria funcionar acaba poupando muito tempo de ambas as partes.

Você sabia que de acordo com Gloria Mark, que estudou sobre “distração digital” na Universidade da Califórnia, demora cerca de 23 minutos para uma pessoa voltar para suas tarefas após ser interrompida?

• Por último, mas não menos importante: você testa o que desenvolve? Por teste eu não estou falando apenas do caminho feliz. E falando em testes, isso nos leva ao próximo mau hábito.

Não testar seu código

A parte mais legal da profissão de desenvolvedor sem dúvida não é o teste. A maioria dos desenvolvedores é um pouco preguiçosa quando se trata de testar seu próprio código. Seguir os cenários de caminhos felizes é provavelmente tudo que você obtém da maioria deles.

Esse mau hábito acarretará um tempo ainda maior gasto para entregar a funcionalidade solicitada. Se você não testar seu código, provavelmente o tester achará um bug rapidinho, o que poderia ter sido descoberto se você tivesse testado seu código.

Quando o tester reportar um bug, você precisará mexer no código novamente. Depois disso, ele precisará testar a funcionalidade novamente, até que você tenha corrigido o bug. Isso é péssima forma de perder tempo.

Mas testar faz com que eu gaste mais tempo — algum dev

Não, não aumenta. Isso é pensamento equivocado. Fazer testes apenas aumenta o tempo de desenvolvimento inicial, quando você está aprendendo a como testar sua aplicação de forma apropriada. Você deve ficar o hábito de teste na sua mente e tornar isso parte do processo de desenvolvimento, para que isso vire um bom hábito. Tenha certeza que testar vai te deixar mais feliz, por ter menos dor de cabeça no futuro.

Criar commits que são muitos grandes

Um hábito bem ineficiente é criar commits muito grandes. Fica difícil entender o que foi alterado, pois, tantas coisas foram mudadas em um único commit, que não fica claro o que realmente mudou.

Além disso, se coloque como a pessoa que revisará seu código: como você se sentiria ao revisar um commit com mais de cem arquivos alterados? Você provavelmente estaria muito. Você provavelmente se sentiria desmotivado ao revisar completamente o commit.

Commits pequenos são amigáveis. Eles permitem que o dev dê uma mensagem clara e descritiva na mensagem. Desculpa, mas o texto “corrigido alguns erros” não é uma boa mensagem de commit.

Fazer a análise do código(code review) fica muito, mas muito mais fácil com commits menores. Você bate o olho em cada mudança e vê o que foi feito ali, qual foi a linha de raciocínio do dev, e o que ali pode ser melhorado.

Ah, e commits menores também facilitam no debug. É fácil dar um rollback pra um certo commit para testar se um bug existe naquele ponto. Assim que você descobrir em que parte da história dos commits o bug apareceu, perceberá que não tem tanto código que pode tê-lo gerado, já que cada commit terá pequenas alterações.

Isso o tornará muito mais eficiente, sem muito esforço.