Pare de programar em primeira pessoa

Em nossa vida diária, estamos realmente sendo bons desenvolvedores? Primeiro, devemos deixar claro que ser um desenvolvedor qualificado não significa necessariamente ser um bom desenvolvedor.

Observe que aqui me refiro especificamente à capacidade técnica de programar e não ao papel de solucionador de problemas que todo desenvolvedor deve desempenhar.

Freqüentemente, as soluções aparecem fora do escopo do cronograma. Tem um texto muito bom do nosso amigo Paulo Silveira sobre o assunto, a matéria pode ser encontrada aqui: https://blog.caelum.com.br/voce-nao-e-pago-para-programar/

Com isso em mente, temos que um desenvolvedor habilidoso conhece diversas técnicas / truques que podem acelerar o desenvolvimento de um projeto na hora da codificação, porém, somente ele é capaz de suportar ou adicionar novos recursos em tal sistema de forma eficiente.

Por outro lado, um bom desenvolvedor escreve código sustentável, ou seja, ele escreve o código para outros programadores e não apenas para si mesmo, o que facilita o desenvolvimento ágil da equipe e a evolução do produto.

Em um mundo perfeito, seríamos todos bons e habilidosos programadores, mas como nem sempre essa é a realidade, devemos ter em mente que ser um bom programador é infinitamente melhor do que ser habilidoso, principalmente quando se trabalha em equipe. Quanto maior for a equipe, maiores serão os benefícios de um código bem escrito.

Mas o que faz com que alguns desenvolvedores não dêem a devida importância ao código que está sendo escrito ou acabem não pensando no médio ou longo prazo? Ou se quisermos colocar o dedo na ferida, podemos perguntar: O que nos torna profissionais tão egoístas?

Um dos principais motivos é que programamos na primeira pessoa. Quando programamos na primeira pessoa, assumimos o papel de quem entende tudo o que está acontecendo no projeto, conhecemos as tecnologias, sabemos onde estão as funções mais importantes, encontramos facilmente os scripts, executamos a ordem das rotinas corretamente porque não temos dúvidas, somos nós os “donos” do código.

Por que eu deveria pensar em um nome legal para uma função que acabei de gerar ou extrair vários métodos menores de um método gigante? Se eu sou o criador, isso por si só pressupõe que eu conheço o sistema perfeitamente, então não há razão para tais ações…

E é aí que está a armadilha! Quando estamos desenvolvendo na primeira pessoa, não nos preocupamos em olhar para fora e acabamos deixando nosso código em um estado de difícil manutenção / modificação por um segundo programador, ou no futuro, por nós mesmos.

Daí a importância de se tentar sempre programar na terceira pessoa, no papel de quem não conhece a tripa do sistema. Isso ativará um gatilho em nosso cérebro para que possamos criar métodos mais coesos, definir nomes de variáveis ​​mais objetivos e produzir códigos mais sustentáveis.

Os três pedreiros! Ops… Os três desenvolvedores!

Se pararmos para pensar, muitas vezes acabamos caindo na velha e conhecida fábula dos três pedreiros: (https://www.metaforas.com.br/2007-06-16/tres-pedreiros.htm)

Da mesma forma que o primeiro pedreiro da fábula, cuja visão do que fazia se limitava ao facto de estar apenas a preparar a argamassa e o segundo a construir um muro, podemos pensar que estamos apenas a construir uma função, e essa é a maneira que pode nos levar a escrever um código ruim.

Devemos ter uma visão ampla do terceiro pedreiro, que, quando questionado sobre o que estava fazendo, respondeu: Estou construindo uma catedral!

No nosso caso, não estaremos criando apenas uma função, estaremos desenvolvendo uma função que faz exatamente o que se propõe, devidamente testada e documentada para que possa contribuir diretamente para um produto de alta qualidade e do qual ambos somos fornecedores e consumidores!

Um código sustentável e bem escrito, além de gerar um produto de maior qualidade para o cliente, também ajudará o próprio programador e sua equipe no trabalho diário com o mesmo.

Humildade

Um dos ingredientes fundamentais para desenvolver um bom software com certeza é a humildade. Conseguiremos lembrar ou confiar naquele método duvidoso que criamos 2 ou 3 anos atrás apenas para fazer uma entrega rápida?

Provavelmente não… Tem hora em que esquecemos o que comemos no almoço do dia anterior (em alguns casos até no mesmo dia), imagine lembrar-se de linhas e mais linhas de código? Nessas horas, um bom código pode ajudar até mesmo o criador.

O código que estamos escrevendo, além de poder ser usado por outros programadores, também será usado por nós mesmos. Você conhece aquela máxima de que devemos tratar nosso próximo como gostaríamos de ser tratados? Bem, quando paramos de escrever um código limpo, deixamos de tratar bem a próxima pessoa, que neste caso pode ser um amigo, um colega de trabalho ou nosso próprio “eu no futuro”.

Durante esses anos trabalhando como desenvolvedor, vi blocos e blocos de código sendo perdidos (e consequentemente o tempo que poderia ser economizado com eles) devido ao fato de que seria mais fácil reescrever blocos do zero, do que tentar entender o que ele fez. Isso inclui meus próprios códigos! Mas essas são águas do passado … Espero!

É uma coisa tão bonita quando olhamos para um código bem escrito que até procuramos a linha que informa o autor, não é? Procuremos sempre ser como este autor.

Por hoje é isso, espero ter contribuído de alguma forma para o seu trabalho!
Abraços e até breve!

Autor: Augusto Mesquita
Revisor: José Gilson