Como vocês lidam com a "herança maldita"?

Thread.start() Membro desde: 12/05/2011 08:50:44 Mensagens: 33 Offline

Boa noite.

Há um mês troquei de empresa. Saí de uma empresa pequena que tem uma preocupação grande com a qualidade (tanto de codificação quanto de "produto final" -- o que o cliente vê) e fui para uma empresa maior, mas menos preocupada com a qualidade do código.

Essa empresa onde estou agora não se importa, por exemplo, se o CSS que está sendo usado na página tem 100 ou 1000 linhas. Não se importa se o projeto está utilizando versionamento ou se foi feito backup. Dá até pra cometer o gravíssimo erro de colocar informações de sessão expostas no cookie que ninguém percebe, pois ninguém valida e revisa o código.

E típica empresa onde os gerentes chegam e cobram resultados que invariavelmente são urgentes. O famoso "faz funcionar". Como estou começando, me dão manutenção pra fazer (em projetos já entregues) e essa manutenção é em cima de um código feio, não documentado (e não comentado)... um código que mistura a view com a regra do negócio, que possui métodos com centenas de linhas... enfim, quase sempre são códigos horríveis de dar manutenção -- e devido a essas características, atrasos são muito frequentes. No entanto as pessoas hierarquicamente acima de mim não estão nem um pouco preocupadas com a qualidade interna do projeto. Querem apenas o resultado e querem que fique bom para o cliente. E no prazo estipulado.

Eu constantemente fico receoso de o meu futuro nessa empresa estar comprometido (leia-se: tenho receio de ser demitido) por conta dessa herança maldita, de metodologias inexistentes, de uma programação às vezes gambiarrenta e outras vezes complicada demais quando deveria ser simples (para terem uma ideia, hoje eu passei o dia todo tentando submeter um conjunto de checkboxes para o controller (tarefa trivial e simples!), porque a forma como a query estava montada... dava vontade de apagar tudo e começar do zero ao invés de implementar em código bagunçado).

Enfim, acho que já passei a mensagem. Gostaria de saber como é o dia-a-dia na empresa de vocês e como lidam com a pressão de pessoas que não sabem nada do aspecto técnico e se preocupam simplesmente em cobrar por erroneamente acharem que a culpa de a coisa andar lentamente é do desenvolvedor atual e não do infeliz que concebeu tudo torto inicialmente.

GUJ Expert Membro desde: 22/01/2007 22:00:53 Mensagens: 4188 Online

Pois é cara, nem todo local se preocupa com o produto mas apenas com o resultado.

Eles querem que esteja pronto mas sem qualidade. Mas também querem que não aconteçam erro algum.

Infelizmente é assim em muitos lugares. O jeito é tocar a vida e continuar estudando. [=

Para um dia tu pegar um lugar melhor. [=

tenta refatorar alguma coisas, vai demora mais pra vc organizar o codigo e tal ja outras tem q se reescitas mesmo. haha vc trabalha com asp classico?

Virtual Machine Man Membro desde: 04/08/2010 09:37:57 Mensagens: 543 Offline

É dificil mudar a mentalidade das pessoas.

Se seus chefes acreditam que essa é a melhor forma de desenvolver, sobra pouco que você possa fazer.

Recomendo que troque de empresa novamente.
E dessa vez você já tem um item a mais na hora de escolher.

Virtual Machine Man Membro desde: 07/03/2007 15:58:16 Mensagens: 518 Offline

Bom, esse eh o mundo real para a maioria de nos.

AbelBueno wrote:É dificil mudar a mentalidade das pessoas.

Se seus chefes acreditam que essa é a melhor forma de desenvolver, sobra pouco que você possa fazer.

Recomendo que troque de empresa novamente.
E dessa vez você já tem um item a mais na hora de escolher.

Discordo completamente. A culpa nao eh dos chefes, a culpa eh nossa, desenvolvedores, que fazemos porcarias de codigo pra todo lado e temos o habito de por a culpa nas pancadas dos gerentes nas mesas.

Codigo bom eh mais rapido, mais produtivo, mais eficiente e mais lucrativo do que codigo ruim. Entao nenhum chefe/diretor/gerente prefere codigo ruim.

O ponto eh que eles ja estao fartos de ouvir essa conversa de codigo bom, codigo bonito, design patterns, blablabla, e na hora do pega pra capar, a produtividade eh baixa e a resultado pessimo.

O ponto eh, se voce mudar de empresa, muito provavelmente vai cair em outra como essa, e depois outra e outra e outra e assim por diante. Nenhuma empresa das que dao valor a qualidade de codigo e todas essas coisas darao chance a alguem que nao sabe como fazer quando pega uma aplicacao ruim.

O meu conselho é: relaxe, faça seu trabalho, voce nao foi o primeiro, nem será o ultimo a mexer nessa aplicacao ai, entao eles ja tem uma boa nocao de quanto tempo leva pra alguem se adaptar a ela. Se voce nao esta conseguindo, procure ajuda, pergunte aos outros, nao assuma a posicao: "ah eu nao vou mexer nessa porcaria." Nao me leve a mal, mas voce ja deveria saber o que fazer quando pega codigo ruim pela frente, ja devia saber como refatorar e trabalhar nele aos poucos para melhorar a qualidade. E mesmo assim nao deixar a produtividade de lado.

Continue estudando, sempre, porque vai precisar. Se eles te demitirem, paciencia, voce arruma outra coisa, mas tente.

This message was edited 2 times. Last update was at 03/12/2011 16:55:05

Código ruim tem em todo projeto trabalhado por vários programadores e com certa complexidade e prazo apertado. Acostume-se com isso. Dificilmente alguém vai fazer o código ideal de primeira quando está programando algo que nunca fez antes. E aí se ele não tem tempo pra refatorar depois fica o código feio lá...

Tem tempo disponível? Refatore. Não tem? Faça mais um POG que faça funcionar oq vc quer. Importante é deixar o cliente ou gerente feliz. Pelo menos eu penso assim...

Se não quer enfrentar isso vai ter que procurar uma empresa onde os projetos não tenham prazo apertado, os programadores já tem experiência no que fazem e se preocupam com a qualidade do código. Mas isso é difícil achar...

Código ruim tem em todo projeto trabalhado por vários programadores e com certa complexidade e prazo apertado. Acostume-se com isso. Dificilmente alguém vai fazer o código ideal de primeira quando está programando algo que nunca fez antes. E aí se ele não tem tempo pra refatorar depois fica o código feio lá...

++!

Não adianta ficar reclamando do codigo ruim.E muitas vezes, quando se faz algo novo, o codigo e de pessima qualidade.Acabei de refatorar um codigo de uma importação de dados que tinha quase 3mil linhas.Com as 100 atuais ja acho grande o bastante.

htraos,
as situações por descritas são mais do que normais.E não reclame de codigo CSS com 1000 linhas.Quer algo pior?Pegue esse mesmo codigo CSS, e ao inves de por num arquivinho isolado, o cara copiou e colou em 200 paginas html....imagine que seu gerente quer a mudança do design em 1 hora...

JWizard Membro desde: 21/09/2003 16:01:35 Mensagens: 2140 Offline

htraos wrote:Boa noite.

Há um mês troquei de empresa. Saí de uma empresa pequena que tem uma preocupação grande com a qualidade (tanto de codificação quanto de "produto final" -- o que o cliente vê) e fui para uma empresa maior, mas menos preocupada com a qualidade do código.

Empresa pequena normalmente é mais fácil manter a qualidade do código pq os sistemas são poucos, a equipe é pequena, e as folgas que aparecem ou cobrança por prazo não é tão grande assim.

htraos wrote:
Essa empresa onde estou agora não se importa, por exemplo, se o CSS que está sendo usado na página tem 100 ou 1000 linhas. Não se importa se o projeto está utilizando versionamento ou se foi feito backup. Dá até pra cometer o gravíssimo erro de colocar informações de sessão expostas no cookie que ninguém percebe, pois ninguém valida e revisa o código.

Temos programadores pra que ? Se eles já não implementam direito, a culpa não é da empresa...
Quem tá com a mão na massa é o pedreiro (programador). Se ele vê que determinado bloco está ruim, que coloque outro e continue a levantar o muro (projeto).
Agora esperar que o engenheiro fique monitorando isto e tenha esta obrigação é demais.
Da mesma forma o CSS ou outra peça de software. Todo o código é de responsabilidade do programador. Se está uma merda, a culpa é dele.

htraos wrote:
E típica empresa onde os gerentes chegam e cobram resultados que invariavelmente são urgentes. O famoso "faz funcionar".

Mas isto é assim na maioria dos lugares, inclusive onde trabalho. É coisa natural, não sei pq vc estranha. Imagino q deve ter pouca idade e pouca experiencia profissional.
Se meu gestor me pede algo, ele vem, combina comigo o prazo e sou responsável por dizer quanto tempo vai levar.
A partir daí ele está certo em me cobrar pelo prazo, pois combinamos juntos, portanto não foi imposto, mas tb não foi definido por mim.
Cabe a mim, fazer o melhor dentro deste prazo que combinamos, pois existem outros na equipe que também dependem do meu trabalho e se eu atraso, atraso os outros.

htraos wrote:
Como estou começando, me dão manutenção pra fazer (em projetos já entregues) e essa manutenção é em cima de um código feio, não documentado (e não comentado)... um código que mistura a view com a regra do negócio, que possui métodos com centenas de linhas... enfim, quase sempre são códigos horríveis de dar manutenção -- e devido a essas características, atrasos são muito frequentes. No entanto as pessoas hierarquicamente acima de mim não estão nem um pouco preocupadas com a qualidade interna do projeto. Querem apenas o resultado e querem que fique bom para o cliente. E no prazo estipulado.

Novamente te digo, isto é o comum por aí. Pegar projeto já feito para dar manutenção e achar que vai encontrar 15 design patterns implementados é ser muito inocente.
Te digo mais...já vi programador que odeia comentar código e programa assim, sem nada mesmo, apenas código.
Ele e somente ele é responsável por deixar isto para as gerações futuras.Quer brigar com alguém de ter que enfretar o inferno para entender a lógica da app ?
Busca esse safado no inferno !
Eu sou a favor do código comentado, mas tem gente que não é e estes quando pegam sistemas que mantenho, adoram, pq o código + comentários ajudam em muito a eles não terem que ficar perguntando o que é o que no projeto.

htraos wrote:
Eu constantemente fico receoso de o meu futuro nessa empresa estar comprometido (leia-se: tenho receio de ser demitido) por conta dessa herança maldita, de metodologias inexistentes, de uma programação às vezes gambiarrenta e outras vezes complicada demais quando deveria ser simples (para terem uma ideia, hoje eu passei o dia todo tentando submeter um conjunto de checkboxes para o controller (tarefa trivial e simples!), porque a forma como a query estava montada... dava vontade de apagar tudo e começar do zero ao invés de implementar em código bagunçado).

Dica: Só tente consertar o que está cagado se você tiver tempo no seu prazo ou se isto decididamente não oferece risco ao cumprimento do cronograma.
Se vc não se acostumar a consertar o avião durante o voô, não só seu futuro ai na empresa estará comprometido como em qualquer outro lugar!
Volto a te dizer: De nada adianta código lindo se o prazo foi estourado. O custo do seu atraso em entregar a tarefa pode ser muito maior que vc pensa.
Não necessariamente, os seus pares ou chefe irá querer conversar abertamente sobre isto com vc, mas com certeza vc perceberá o efeito quando alguém for fired.
Pra chegar no ponto do burn, o programador já deve ter pisado na bola algumas vezes.

htraos wrote:
Enfim, acho que já passei a mensagem. Gostaria de saber como é o dia-a-dia na empresa de vocês e como lidam com a pressão de pessoas que não sabem nada do aspecto técnico e se preocupam simplesmente em cobrar por erroneamente acharem que a culpa de a coisa andar lentamente é do desenvolvedor atual e não do infeliz que concebeu tudo torto inicialmente.

Dica 2: Manda quem pode, obedece quem tem juízo.
Eu não questiono meu chefe sobre algumas coisas pois confio e acredito que suas decisões são as melhores com o conjunto de informações que tem.
Cabe a você tb não ficar pelos cantinhos reclamando e chorando e conversar com a chefia quando possível.
Se vc não mostra adequadamente a situação que tem para consertar, como espera que ele entenda e até rediscuta prazos ?
Quando digo mostrar adequadamente, é vc estudar a encrenca antes e na hora de conversar, saber apresentar as informações de forma correta, sem ser tendenciosa, sem distorcer e sabendo do que está falando. Olha, tem muitos por aí que falham miseravelmente nesta parte e lógico, jogam a culpa no gerente que não lhes ouve, é autoritário, não lhe entende e todo blá-blá-blá já conhecido.

Imagino que algum aprendizado vc está tirando desta situação, até para corrigir certas idéias suas que por ventura achava que tinha razão.
Existe lugares melhores bem como piores deste que vc está. Aproveite este e siga em frente.

JavaEvangelist Membro desde: 30/06/2008 13:18:23 Mensagens: 359 Offline

Sinceramente: Isso é a coisa mais normal do mundo (infelizmente)

Engraçado...você lê diversas coisas que devem ser aplicados em um projeto: testes unitarios, verificação constante da qualidade do projeto, documentação, feedback, refatoração, etc..etc...etc..e mais um monte de coisas que quando você lê parece um mundo da "Disney" em relação ao mundo que você trabalha.

Você chega pela manha para trabalhar, liga seu computador, abre sua caixa de email, e olha um email do cliente com este assunto:

(URGENTE) - Precisamos corrigir isso

Seu gestor olha para você....você olha para ele e vem a famosa frase:

"Quanto tempo demora para corrigir isso ? A mulher ta soltando fogo pela boca."

Você pensando: "Bom, aquele código ta um lixo, vou corrigir agora, e essa merda vai dar problema de novo. Ou se alguém pegar no futuro, ta ferrado. Acho que vou levar no minimo umas 8h para refatorar aquilo e resolver o problema de uma vez por todas."

Você falando com o seu gestor: "Ah cara, para ficar certinho...teriamos que gastar umas 8h nisso, fazer uma refatoração (jogando seu peixe para o gestor tentar engolir e aceitar a refatoração e você se sentir como um "bom profissional"), mas se for para corrigir nessa "correria" ai...umas 4h e ta resolvido (jogando seu peixe para se manter no trabalho e ganhar a estrelinha de "bom menino" com o Cliente e o com o Gestor)"

Gestor: "Blz, corrige rápido, depois a gente ve essa refatoração. Por que a mulher ta cuspindo fogo pela boca e já ta ameaçando procurar outro fornecedor"

Bom...você arruma o problema em 3h. O Gestor fica feliz, o Cliente fica feliz. O Gestor fala para o Diretor que conseguimos apagar o "Incêndio" com o Cliente.

Conclusão: Você resolveu o problema em 3h. Deixou todos os seus superiores felizes. E principalmente: Deixou o cliente feliz. E eles nem ao menos sabem o que você fez. Se você se manter assim, deixando o tempo todo o "Gestor" e "Cliente" feliz, provavelmente você ira receber um reajuste ou talvez sera promovido de cargo.

Essa é a "dura" realidade de "algumas" empresas. Mas arrisco dizer: As empresas hoje em dia buscam "bombeiros" e não "detetives" para analisar e investigar a melhor solução para o problema.

O problema é: Nessas condições que coloquei acima, quem futuramente ira ter mais beneficios($$$) dentro desta empresa: O "bombeiro" ou o "detetive" ?

Obs: Todo esse texto acima, foi um caso real.

HelloWorld Membro desde: 05/12/2011 07:24:04 Mensagens: 11 Offline

liga no 0800

Thread.start() Membro desde: 20/10/2011 07:53:07 Mensagens: 49 Offline

victorcosta wrote:Código ruim tem em todo projeto trabalhado por vários programadores e com certa complexidade e prazo apertado. Acostume-se com isso. Dificilmente alguém vai fazer o código ideal de primeira quando está programando algo que nunca fez antes. E aí se ele não tem tempo pra refatorar depois fica o código feio lá...

Tem tempo disponível? Refatore. Não tem? Faça mais um POG que faça funcionar oq vc quer. Importante é deixar o cliente ou gerente feliz. Pelo menos eu penso assim...

Se não quer enfrentar isso vai ter que procurar uma empresa onde os projetos não tenham prazo apertado, os programadores já tem experiência no que fazem e se preocupam com a qualidade do código. Mas isso é difícil achar...

Isso é fato, código ruim tem realmente em todo projeto trabalho por vários programadores, pois mesmo que exista um padrão de codificação na empresa, muita gente tem "preguiça" de seguir esse padrão e simplesmente faz funcionar de qualquer maneira, afinal, em empresa grande a preocupação é em entregar para o cliente o mais rápido possível..

Refactoring nao é algo que vc faz pq a empresa determina. É algo que vc faz em benefício proprio.
Semana passada refatorei uma classe de 2700 linhas em 800. Tive aquele feeling de que num futuro proximo isso seria alterado.

Resultado: hoje chegou manutencao nela. Quem ganha com isso: EU.
Consigo fazer tudo em 40% do tempo e ainda da pra vir no guj responder alguns topicos

JWizard Membro desde: 21/09/2003 16:01:35 Mensagens: 2140 Offline

bestlinux wrote:Sinceramente: Isso é a coisa mais normal do mundo (infelizmente)

....
..
...

Gestor: "Blz, corrige rápido, depois a gente ve essa refatoração. Por que a mulher ta cuspindo fogo pela boca e já ta ameaçando procurar outro fornecedor"

Bom...você arruma o problema em 3h. O Gestor fica feliz, o Cliente fica feliz. O Gestor fala para o Diretor que conseguimos apagar o "Incêndio" com o Cliente.

Conclusão: Você resolveu o problema em 3h. Deixou todos os seus superiores felizes. E principalmente: Deixou o cliente feliz. E eles nem ao menos sabem o que você fez. Se você se manter assim, deixando o tempo todo o "Gestor" e "Cliente" feliz, provavelmente você ira receber um reajuste ou talvez sera promovido de cargo.

Essa é a "dura" realidade de "algumas" empresas. Mas arrisco dizer: As empresas hoje em dia buscam "bombeiros" e não "detetives" para analisar e investigar a melhor solução para o problema.

O problema é: Nessas condições que coloquei acima, quem futuramente ira ter mais beneficios($$$) dentro desta empresa: O "bombeiro" ou o "detetive" ?

Obs: Todo esse texto acima, foi um caso real.

Parabéns !
Conseguiu passar fielmente como é realmente a vida.
Detetive precisamos sim, mas na maior parte do tempo é o bombeiro que entra em cena. Vai depender do prazo e urgência.
Essa é a vida. Ou ele acostuma-se ou morre perante o mercado.

No teu caso, eu seria pro-ativo e nas reunioes com os programadores eu falaria de fazer uma reuniao de boas praticas, clean code etc. Quando sobrar tempo, refatorar os codigos

Senao daqui 5/10 anos, esse sistema vai estar totalmente "imanutenivel" (nao sei se isso existe, mas da pra entender huaiehe)

Cara, já que você é novo na empresa, não nade contra a maré. Feito isso, você tem uma ótima oportunidade nas mãos e que pode impulsionar sua carreira. Você pode tentar mudar o paradigma da empresa e criar uma organização de todo o processo de desenvolvimento. A sugestão é ir sugerindo pequenas mudanças. Assim você vai puxando a responsabilidade para você. Depois de algum tempo, se não houver muita resistência, você será o cara que organizou a TI da empresa.

Notícias, artigos e o maior fórum brasileiro sobre Java