Dúvidas sobre carreira e comportamento

Boa tarde Pessoal,

Preciso de uma ajuda ou opinião de alguém que talvez possa ter passado por isso.

Tenho pouca experiência com desenvolvimento, fiz um estágio no longínquo ano de 2020 numa empresa de software durante 7 meses.

Essa empresa tem uma aplicação bem grande com muitas classes, pacotes e componentes, é um projeto bem grande e ao meu ver, com minha pouca experiência, acho o projeto bem organizado, não chegava ser mvc, mas havia separação da parte de negócio da parte de apresentação e um bom time que tentava na medida do possível escrever código para que possa ser de melhor entendimento e fácil manutenção, contudo esse estágio acabou e fui atrás de uma oportunidade que me foi apresentada a pelo menos um ano atrás, mas por circunstâncias da vida não pude investir nela naquele momento, mas como a terra é redonda e dá voltas, cá estou nesse trampo.

Mas explicando a atual situação, aqui é uma fábrica e o dono chamou um dev para fazer um ERP voltado para indústria, até aí tudo bem, hoje o sistema tá em produção o pessoal da fábrica tá usando e vida que segue…

Contudo, por favor pessoal, não quero parecer que sou um puta programador pq realmente não sou, e tenho muito o que aprender e estudar mesmo, mas o código desenvolvido por ele vai totalmente na contramão do que vi na outra empresa e também do que escuto em podcasts sobre tecnologia, tem alta complexidade, é procedural (palavras do desenvolvedor), não tem versionamento, em resumo, é um sistema de uns 2 - 3 anos, mas pelo que andei lendo já nasceu legado…

E isso de certa forma me preocupa, pois tenho medo de sugerir melhorias, pois semana passada ele havia me dito que tem interesse em transformar o código em orientado a objeto para melhorar na hora de dar manutenção por outras pessoas pois ele desenvolveu da forma que ele consegue trabalhar melhor e nesse caso foi fazendo de forma procedural. Tenho ideias para tentar “melhorar” o código, no sentido de começar a separar as entidades em classes, separar os forms da regra de negócio, começar a escrever testes, fazer refatoração e tal, mas me bate esse medo, de tentar sugerir algo e talvez não ser bem recebido e talvez ele acabar entendendo como uma crítica a forma de trabalho dele, ou o que pode ser ainda pior, sugerir algo e não dá conta de fazer, uma vez que sou bem novo no mercado e inexperiente.

Há também outra coisa, esse desenvolvedor mora em outro estado e trabalha durante o dia, o que deixa minha comunicação com ele bem falha, pois fico durante o dia na empresa e quando me surge alguma dúvida penso em mandar mensagem para ele, mas devido à agenda dele fico com medo de estar incomodando ele durante o trabalho.

Me desculpem escrever tanto, mas de certa forma foi também um desabafo.

Vlw galera!

Ou seja, o cara não tem experiência em desenvolvimento, foi fazendo do jeito que ele achava que se fazia e agora não consegue mais dar manutenção no monstrinho que criou.
É uma situação triste, mas que acontece muito.
Esse é um dos preços que se paga por não seguir boas práticas de desenvolvimento, que podem parecer burocráticas e pouco produtivas no início, mas que evitam o software de chegar ao ponto que esse aí chegou.

Geralmente existe resistência quando se sugere refatorações, pois a maioria dos gestores entende que a refatoração é uma “perda de tempo e dinheiro”, já que serão investidas muitas horas de desenvolvimento para no final o produto continuar com as mesmas funcionalidades, para a maioria dos gestores é difícil entender a importância de ter um código bem organizado e coeso, eles se preocupam só com a funcionalidade.

Esse risco sempre vai existir, principalmente se foi seu chefe quem programou o que você está dando manutenção. Há alguns anos eu passei por uma situação parecida e o que eu fiz foi o seguinte:
Em casa, nas horas vagas, montei uma estrutura de classes parecida com o que tinha na empresa, só não tinha as regras de negócio e o banco de dados, pois o intuito era só remodelar o sistema para apresentar a sugestão de melhoria.
E foi o que fiz, criei um novo projeto refatorando os relacionamentos criando novas classes, realizando as dependências somente com interfaces, fazendo algo decente do ponto de vista da POO, padrões de projeto e princípios SOLID.
Aí preparei uma apresentação mostrando a estrutura atual, os impactos que aconteciam a cada manutenção e confrontei com o modelo novo que havia bolado mostrando as vantagens.

1 curtida

Entendi, muito boa essa sugestão, farei algo parecido tbm, pq realmente é um sistema relativamente novo, tem uns 3 anos, mas parece legado, não sei quanto tempo passarei aqui, mas a intenção é organizar e deixar de modo que outras pessoas que passarem se sintam menos perdidas que quando comecei.

Ele mesmo já fez questão de me lembrar que tem 25 anos de experiência em ERP, mas de toda forma, pelo que vejo, foi isso mesmo, ele trabalha em outra empresa durante o horário comercial e foi fazendo esse sistema da maneira que achou mais produtiva em suas horas vagas. só que como vc comentou, tá ficando feio o monstrinho…

Mas seguimos na luta e espero ajudar no desenvolvimento de um código mais coeso e seguindo POO.

Muito obrigado pela resposta!

1 curtida