Existe um tipo de desenvolvedor que muitas empresas valorizam.
Não é o dev ninja.
Não é o dev sênior poliglota.
É o desenvolvedor jardineiro — aquele que pega um legado cheio de problemas e começa, pouco a pouco, a colocar flores no cocô.
E tudo começa pela base: melhorar a experiência de desenvolvimento.
Antes de tocar em código, o jardineiro organiza a casa. Configura ambientes locais com Docker, atualiza processos de instalação e execução, revisa README e documentação, ajusta scripts, pastas e fluxos de onboarding.
Esses primeiros passos tornam o projeto mais fácil de rodar e trabalhar no dia a dia. Só depois disso começa a segunda fase: cuidar do código em si.
Aqui entram as pequenas grandes melhorias. Refatoração pontual, remoção de duplicidades, extração de classes, aplicação de herança quando faz sentido, melhor uso de recursos já existentes, nomes mais claros e um fluxo mais fácil de entender. Aos poucos, aquele trecho de código que ninguém queria encostar se torna mais limpo, mais organizado e mais saudável.
A terceira fase vem com os testes e a evolução contínua. Criar testes de unidade para partes novas, melhorar trechos críticos, ajustar performance e eliminar comportamentos inconsistentes. Cada melhoria reduz riscos e aumenta previsibilidade.
E tem um ponto importante: nem todo mundo quer trabalhar no legado, mas faz parte da rotina de um desenvolvedor. Quanto mais você melhorar o ambiente, o código e o fluxo de desenvolvimento, melhor será a sua própria experiência no dia a dia.
Uma coisa é fato: você pode encontrar resistência no começo. E não só da gestão ou dos pares, mas do famoso “pai da criança”, aquele dev que tem apego ao código que escreveu e fica contrariado com qualquer mudança. Isso acontece mais do que deveria.
Mas nada que uma boa conversa não resolva. E, sinceramente, se o pai da criança ficar chateado, o problema é dele. Você precisa pensar no que é melhor para o time, para o projeto e para o futuro da aplicação.
Pode parecer pouco. Pode até parecer que você está “só arrumando cocô”. Mas na realidade, esse é o tipo de trabalho que traz benefício real a longo prazo e que gera visibilidade para quem faz.
Claro, existe um limite. É preciso analisar até onde vale a pena investir no legado e quando é hora de reescrever, dividir em serviços menores ou migrar para algo novo. Jardinagem é boa, mas deve ser estratégica.
Ainda assim, enquanto aquele código existir, cada melhoria incremental ajuda. Reduz bugs, melhora performance, acelera o desenvolvimento e diminui a carga mental do time.
Nem todo mundo quer trabalhar no legado. Mas quem aprende a cuidar dele, cresce. E quem faz isso bem, vira essencial.
No fim, jardinagem no código não é sobre flores.
É sobre responsabilidade.
É sobre maturidade.
É sobre deixar o sistema melhor do que você encontrou.
Top comments (0)