Desabafo de um dev cansado do código atual.
Bom, eu resolvi fazer esse post mais como uma forma de desabafo e até saber se mais pessoas já tiveram esse sentimento... Mas eu basicamente trabalho em uma empresa aonde a base de código é bem antiga e então quaisquer conceitos que atualmente se tornaram "normais" talvez nem existiam.
Nem to falando só de Clean Code ou algo do tipo, mas quase sempre me pego resolvendo os mesmos problemas devido a "idade" da base de código, zero separação de responsabilidades, funções repetidas que se altera em um local, impacta no outro e por ai vai...
Como essa foi a minha primeira oportunidade e to a alguns anos, no começo eu achava besteira aquelas regrinhas de boas práticas quando ia estudar algo novo, achava que atualmente estavámos virando meros organizadores de pastas, pq parecia mais tempo separado arquivo do que escrevendo código.
Porém depois que comecei a trabalhar e estudar novas tecnologias/arquiteturas, eu vi que toda essa aparentemente "complexidade" inicial era algo extremamente necessário, pois tornava um código muito mais seguro e te deixa até com menos ansiedade de mexer em x função sem quebrar a y.
Esses tempos achei que eu não gostasse mais de codar, porém eu notei que isso aconteceu depois que comecei a estudar novos conceitos e evoluir meus conhecimentos, notei que com o tempo foi ficando repetitivo resolver os mesmos problemas e quando era pra resolver algo em outra codebase, eu ficava muito mais animado.
Mexer em código legado cansa infinitamente mais, isso me faz enxergar que esses conceitos são tão importantes no dia a dia e só melhoram o nosso trabalho, tanto agora quanto no futuro quando alguém precisar dar manutenção, afinal o próximo coleguinha pode ser você!
Alguém já chegou nesse estágio de estar resolvendo as mesmas coisas diariamente e sente que parou de evoluir ?
Fui programador COBOL, BASIC, DELPHI, C++, etc... Hoje sou aposentado e brinco com Python. Ou seja, depois de tanto tempo continuo um neofito.
O que percebi é o código atual é mais complexo. Mas ao mesmo tempo possuimos mais ferramentas para organizar o código. Em passado recente não tinhamos esses recursos para organizar o desenvolvimento, controlar versões, cuidar de sintaxes, cuidar de testes.
Apenas para ilustrar a precariedade do passado, em algum momento da minha carreira tínhamos que dividir tempo de máquina disponível. Compilávamos durante a noite para não competir com a produção durante o dia.
O que eu penso é que tanto o código quanto as ferramentas que auxiliam o programador evoluiram muito. E isso é MUITO bom. Agora temos melhores ferramentas para construir coisas melhores. Mas lembrem-se: na medida que trouxemos facilidades para os usuários criamos dificuldade para os desenvolvedores.
Opa, Marcos!
vou transcrever aqui uma fala de um vídeo do Fábio Akita que me ajudou bastante a mudar minha percepção quando trabalhamos com legado, e talvez possa ajudar porque eu acredito que essa fase que você relatou é muito importante na carreira de um Dev, e ajuda a construir uma característica que qualquer profissional deveria buscar:
"Deixa eu te contar um dos grandes segredos da nossa área: Qualquer imbecil consegue começar um projeto novo do zero, mas só os caras realmente bons conseguem melhorar sistemas legados. A característica mais importante de qualquer profissional não é saber só usar bem suas ferramentes — isso é o básico. É a capacidade de absorver o ambiente, entender as limitações desse ambiente e tomar as melhores decisões o mais rapido possível e executar. Quem consegue fazer isso sempre vai estar à frente do rato de laboratório(...) que não consegue avaliar a situação real e toma decisões caras e de pouco resultado prático"
Fábio Akita
Cara acho que tive um experiência parecida com a tua, eu trabalhei em um banco onde usavamos muita coisa antiga pra ter uma ideia tinha rotina que rodava em vb3 sendo que o vb já tinha morrido a muito tempo.
Nesse período eu pensei em desistir de codar e fazer gastronomia, porém como tinha o desejo de trabalhar fora do pais seria mais facil continuar sendo analista de sistemas, isso foi lá por 2013.
O que eu fiz? Aprendi python e ruby, e seus frameworks mais populares na época que eram o django e rails expecificamente. Comecei a procurar alguns trabalhos paralelos que me ajudassem a por em prática essas novas tecnologias pra mim. Essa época estava no boom das startups e eu ia em co-workings e deixava um cartão falando que fazia MVPs, ai comecei a pegar vários trabalhos no qual decidi ficar como freelancer no qual eu fiquei 1 ano e foi bem louco pois tinha que aprender muita coisa pra ontem. Mas, foi bom pra mim.
Se me permite, de uma olhada nessa playlist talvez possa te ajudar, ali foi um curso que mostrava como começar a reestruturar um codigo legado criando pequenos pontos de refatoração, mesmo que não use python como no vídeo o conceito se aplica em qualquer linguagem.
Entendo que a maior parte do nosso dia passamos trabalhando, e acredito que nossa área de TI é uma das poucas em que podemos trabalhar e estudar ao mesmo tempo. Mas, mesmo lidando com coisas chatas no trabalho, como arquiteturas ou código legados e atuais, chega um dia que o trabalho se torna repetitivo de qualquer jeito.
E quando percebi isso, comecei a desenvolver projetos paralelos sem ter a certeza de que poderiam dar certo, mas eram algo real e meu. Eu podia usar ferramentas e tecnologias que estava aprendendo, sem burocracia, e isso com certeza foi contribuindo para a minha evolução. Hoje posso dizer que meu dia a dia começou a ficar mais empolgante, mesmo que eu ficasse ansioso para dar 18h e focar no meu projetinho kkkk
Cara! Eu tive essa experiência quando eu fui fazer um projeto no inicio do ano, não só pelo fato da stack ser bem defasada e eu não gostar dela por si só, mas também toda a codebase da empresa que eu estava mexendo era enrolada parecendo uma bola de ligas, tudo era interligado, todas as funções faziam mil coisas ao mesmo tempo e acabava que qualquer alteração que eu fizesse, resultava em horas refatorando o resto inteiro do código, acho que a melhor coisa é conversar com a empresa ou com o techlead, ou seja lá quem esteja dirigindo pra conversar sobre a possibilidade de um rebranding total, mas caso não seja possível, procurar novos ares realmente é o melhor a se fazer.
Os conceitos "atuais" são os conceitos "antigos" agrupdos de forma diferente. Um livro que eu sempre recomendo é o "Thinking Forth" de 1984. São 40 anos de idade. Não, eu não programo em Forth nem pretendo te empurrar a linguagem.
https://thinking-forth.sourceforge.net/
Apenas baixa o livro, olha as ilustrações e leia os quadro com as dicas (tem algumas partes do texto que também são importantes). Tudo isso era conhecido há 40 anos. Então, o problema doi de quem escreveu os programas ou de como foi a pressão para odesenvolvimento.
Eu sei como é, tenho um erp em Delphi que algumas coisas são tranquilas de resolver devido a forma como foi programada, mas outras são complexas.