Gabriel / Ramos

⟨ pintor de pixel ⟩

Não se apegue

Código bom é aquele que vai mudar (e muito) ao longo do tempo

2 min. de leitura

Foto por Stephen Radford

É completamente normal e em algum ponto da sua carreira você vai ficar muito orgulhoso de um projeto que você entregou.

Seja aquela reestruturação maneira, implementação de nova funcionalidade num sistema legado ou criação de uma ideia totalmente nova do zero, você deve ter algum projeto que se lembra com carinho e pensa: "aquele dia foi massa", não é?

E é com esse sentimento zeloso que muitas vezes acabamos fugindo da realidade e esquecendo o simples fato de que todo esse seu esforço, um dia, será substituído.

Isso não quer dizer que seu esforço foi em vão ou que você não deve se orgulhar da sua entrega, muito pelo contrário, sensações de "trabalho bem feito" devem ser o mais recorrente possível. Isso te faz bem!

Mas negar a realidade de que, culturalmente, estamos num ambiente onde tudo muda muito rápido, é o caminho mais fácil para a decepção (e, muito provavemente, criação de infinitos debates tendenciosos sobre decisões técnicas).

#Sem papo de coach sobre "sair da zona de conforto"

Principalmente pelo fato de que quando você muda (ou mudam para você) alguma estratégia que foi tomada ou decisão aplicada em determinado projeto, você é obrigado a repensar essa situação de uma forma totalmente diferente.

Se algum outro time ou desenvolvedor estiver responsável por essa mudança de planos e você estiver envolvido no processo, a situação acaba sendo ainda mais benéfica, já que você pode ter a oportunidade de acompanhar de perto como aquela sua ideia implementada anteriormente irá crescer e se adaptar às novas necessidades do projeto (ou será deixada de lado por uma que faça mais sentido para os novos problemas).

Refatorar, mudar, reescrever e, muitas vezes, jogar todo trabalho feito fora para estruturar uma solução de uma forma mais adequada à um problema é completamente normal e participar desses processos vai te deixar mais confortável e apto a lidar com mudanças e a tomar decisões mais relevantes futuramente.

#Mas uma arquitetura não deveria ser "aberta a extensões, mas fechada a modificações"?

Sim! E conceitos como esse são extremamente válidos e são a base de muitas dessas boas decisões que são tomadas diariamente!

A questão é que nem sempre a arquitetura que foi desenhada está preparada para refletir a necessidade futura de um negócio ou produto daqui há anos (ou qualquer outro período de tempo), simplesmente pelo fato de muitas dessas necessidades ainda nem sequer terem sido descobertas e muitas das decisões que serão tomadas ao longo do projeto ainda nem sequer existirem.

#Não se apegue ao seu código

Assim você evita algumas frustrações durante todo esse processo também.

Seu código será modificado, refeito, reescrito e provavelmente você aprenderá muito mais com isso do que com o momento que o colocou em produção pela primeira fez.

Apegue-se ao que você aprende, não ao que você entrega.


Compartilhe