4 dicas para codificar enquanto superamos nossas próprias falhas psicológicas

Se pudéssemos escolher entre um pedaço de bolo agora ou um bolo inteiro daqui a um mês, provavelmente escolheríamos o primeiro. Esse viés psicológico é conhecido como "Preferência de tempo" ou "Desconto por atraso".

Todos nós vimos este belo exemplo de crianças que tentam se segurar e não comem um marshmallow, na esperança de uma recompensa maior:

Ao escrever código, muitas vezes enfrentamos o mesmo problema, tendo que escolher entre as vantagens de curto prazo das más práticas e os custos de longo prazo que isso gera.

Veja também: IoT e codificação - quais são as linguagens de programação mais populares?

Para ajudar a superar a compulsão por marshmallows ineficientes, aqui estão 4 exemplos de quando e como podemos vencer nossa tendência de ganho a longo prazo.

1. Escreva o teste de unidade, para seu próprio benefício

Todos nós lemos, aprendemos e ouvimos sobre isso. Os testes são um bom exemplo de algo que eu sei que deveria fazer para o benefício de longo prazo, mas está no meu caminho quando tento fazer o trabalho agora.

Aqui estão algumas idéias que podem ajudar a equilibrar esta equação:

• Os testes garantem que nada quebra quando você muda alguma coisa . Isso significa que você pode fazer alterações em seu código e saber na hora se tudo funciona. Isso permite que você trabalhe com mais liberdade, mesmo agora.
• Os testes ajudam a decidir quando algo é “bom o suficiente”. Os testes definem o que significa um trecho de código “funcionar”. Na verdade, isso pode permitir que você gaste menos tempo otimizando coisas que você realmente não precisa otimizar.
• Os testes ajudam a escrever código reutilizável . Você pode compor coisas maiores a partir de peças modulares menores. Lentamente, você está construindo um arsenal impressionante de blocos de construção reutilizáveis ​​prontos para serem usados ​​sob seu comando.

Além disso, orgulhe-se dos testes que escrever. Veja todos os indicadores verdes pairando sobre seu código. Saiba que sua prática e ética são excelentes. Não há vergonha nisso.

2. Torne o código reutilizável enquanto você trabalha

Escrever código reutilizável tem muitas vantagens de longo prazo, bem como algumas imediatas. Sempre que possível, projete seu código para ser reutilizado. Em seguida, publique / exporte-o para o código-fonte aberto.

Você não precisa gastar horas publicando pacotes. Em vez disso, você pode exportar esses pequenos componentes para o Bit. Aqui está uma postagem do blog de Ran Mizrahi explicando por que e como você pode exportar pequenos componentes em segundos.

Muito rapidamente, você pode criar um arsenal de componentes React ou Angular reutilizáveis ​​ou um bom escopo de funções de utilidade.

O esforço é baixo e a exibição da Web do hub da comunidade da Bit oferece uma visão rápida dos documentos, testes, downloads e muito mais de seu componente, proporcionando satisfação imediata com seu trabalho agora disponível para o mundo. Você também pode compartilhá-lo com sua equipe ou comunidade.

3. Não copie e cole. Simplesmente não faça.

Um exemplo clássico. Copiar e colar torna o trabalho muito mais rápido agora, mas as duplicações tornam nossa base de código mais difícil de manter amanhã, criando uma dívida tecnológica cada vez maior.

Cada pequena mudança terá que ser feita em vários lugares e os problemas serão encontrados apenas ao rolar para a produção.

O que podemos fazer? bem, não copie e cole o código! Apenas não faça. Em vez disso, encontre / crie / compartilhe componentes reutilizáveis. Sindre Sorhus lançou mais de 1.000 pacotes minúsculos. Os pacotes são difíceis e 1.000 é muito.

Podemos usar o Bit para tornar esse processo fácil (exportando componentes em segundos) e definir uma meta alcançável, como tornar 100 componentes reutilizáveis. Você descobrirá que cerca de 100 pode ser o suficiente para reduzir drasticamente o número de duplicações e, em breve, verá que reutilizar é muito mais rápido do que duplicar.

4. Documente seu código, conte uma história

Uma boa documentação significa que se eu fosse comido por coiotes selvagens amanhã, outra pessoa poderia me substituir. Importante, sem dúvida, mas não minha principal preocupação agora. Eu prefiro fazer o trabalho do que me preocupar com o "futuro eu" ou aqueles que irão me seguir. Vou me preocupar com eles mais tarde, se chegar a tempo. Esse tipo de priorização (muito humana) leva a lacunas e desleixo na documentação.

No entanto, há outro ponto de vista que posso adotar para ajudar a garantir que não negligencie minha documentação.

Tanto o código em si quanto sua documentação são representações da história lógica que estou contando. Escrevendo o que cada parte do meu código faz, adicionando os argumentos que recebe, seus retornos, adicionando alguns exemplos e assim por diante, também tenho uma boa visão do enredo do código que estou escrevendo. Eu entendo como isso funciona como parte do quadro geral.

Bons documentos mostram que você entende perfeitamente o que está fazendo e como está fazendo. Se a história não faz sentido, é melhor descobrir por meio dos documentos do que pelo próprio código.

No final do dia, nossa força de vontade é um recurso limitado. Obrigar-nos a lutar contra nossa própria psicologia a cada hora de cada dia é uma batalha difícil de vencer. No entanto, abraçar boas práticas é uma rotina e dar a nós mesmos recompensas imediatas por fazer isso pode nos ajudar a ganhar muito mais no final do dia.

Afinal, um marshmallow de cada vez não é suficiente.