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

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

soaresinfo wrote: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.

Dica: Tome muito cuidado com essas palavras: "organizou a TI da empresa".

Para você "organizar" é uma coisa, para seu gestor e seus superiores "organizar" é outra.

JWizard Membro desde: 01/10/2006 15:29:40 Mensagens: 2047 Offline

Não sei se sou o único maluco do mundo, mas minha dica é pra pular fora desse barco...

Não existe manutenção de avião em vôo, da feita que o Sistema lá em cima para de funcionar, a merda cai...

Produto ou empresa quem mantém Sistemas na base do apagar incêndio, tendem a terem os seus projetos fracassados.

Hoje trabalho em projeto assim e testifico 100% do que todos falaram aqui, mas não me conformo com isso, pode até "ser a música que toca atualmente", mas com certeza não é a que quero dançar. Tanto que toda e qualquer manutenção minha, sempre vai um pequeno Refactor da solução, como não concebi a bagaça, não me sinto culpado pelo ato, mas minha chefe está ciente de que sempre que codifico, faço algum refactor, ela quis argumentar comigo quando começamos o Projeto, mas eu não arredo o pé. Código limpo hoje, embora demore mais, evita que eu apague o mesmo incêndio umas 30 vezes...

Essa semana peguei um código que estava repetido em 6 métodos diferentes dentro da mesma classe.. Ou seja, 6 caras que deram manutenção no código, cada um criou o seu próprio, da forma que achava melhor, sem sequer se preocupar se já havia algo pronto no Sistema... Caracaaaaaaaa véio, nunca que vou concordar com isso, perdi 1 dia de trabalho a mais da minha tarefa colocando isso em 1 só lugar e avaliando os impactos da mudança no Sistema inteiro.... ai de quem discordar... heueheuehueehu

Amanhã, serei eu de novo que vou dar manutenção nessa merda. Portanto concordo que o mercado é assim, mas cabe a nós mudarmos essa cultura...

Como o amigo acima falou, os caras estão cansados de ouvir blá blá de programador sobre refatoração e design patterns e blá blá blá... que na verdade só atrasa o projeto e não melhora em nada, mas se você sabe o que está fazendo, faça, sem medo, eu ganhei coragem e comecei a fazer, depois disso, ví que dá certo, o dia que parar de dar, parto pra outra...

Sempre haverá alguém com a cabeça igual a sua, disposto a lhe contratar... na pior das hipóteses, volte para sua antiga empresa, que é pequena, mas trabalha certo. Trabalhando certo, logo deixará de ser pequena.

É nisso que eu acredito.

Abs []

adriano_si wrote:Não sei se sou o único maluco do mundo, mas minha dica é pra pular fora desse barco...

Não existe manutenção de avião em vôo, da feita que o Sistema lá em cima para de funcionar, a merda cai...

Produto ou empresa quem mantém Sistemas na base do apagar incêndio, tendem a terem os seus projetos fracassados.

Abs []

Depende irmao. Conheco uns Sistemas "zumbis" assim que sobrevivem a mais de 5 anos e nao tem data pra acabar.
Se o cliente ta pagando, e pagando MUITO, e vc recebendo bem, quero ver largar mao disso pra ganhar MENOS por algo LINDO, com designs perfeitos num mundo Orientado a Objetos Perfeitos.

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

YvGa wrote:....

Concordo com quase tudo o que disse, menos com esse trecho:

YvGa wrote: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.

Acho que as empresas que valorizam qualidade de código não querem saber se você sabe lidar com aplicação ruim, querem saber se você consegue produzir qualidade.

A questão principal para mim não é nem a qualidade do código atual, mas a filosofia da empresa para o desenvolvimento dos produtos.

Apesar do código porco ser realmente culpa do programador, geralmente vem de cima uma cultura para melhorar a qualidade do código/produto.

Implantar revisão de código, teste automatizado, entre outros é visto por muitos gerentes por aí como perda de tempo.

Se essa filosofia imediatista de "faz funcionar" incomoda, recomendo sim procurar um lugar com outra cultura.

A minha esperança é que essas consultorias que ganham no projeto e na manutenção (do projeto que não funcionou) fechem as portas por falta de desenvolvedores.

Infelizmente, sempre terá aqueles que preferem ganhar o seu salário independente da qualidade do que produz.
Para mim isso é equivalente ao médico que por desleixo deixa bisturi dentro do paciente após operação...
Ou engenheiro que aceita construir prédio com areia da praia e depois vê o negócio cair.

Enquanto não formos mais críticos com relação aos empregos que escolhermos ou ao modo de desenvolvermos a realidade continuará sendo essa: código mal feito funcionando a base de remendos.

Eu lido da seguinte forma: não choro e resolvo

Simples assim.

This message was edited 2 times. Last update was at 06/12/2011 08:50:59

boone wrote: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.

Eu ia escrever um monte de coisas explicando o porquê de chamar o gerente de projeto de "engenheiro" e o programador de "pedreiro" é a coisa mais absurda q eu já vi, mas só vou escrever isto: é muito triste ouvir isso de um programador.

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.

Quanto as respostas anteriores, nunca ouvi tanta besteira assim na minha vida toda. É por isso que vejo tanto código maluco, projetos de R$800 mil afundando e toda sorte de maluquices nas empresas onde trabalho.

Você deve tentar convencer os gerentes que um código melhor resulta em manutenções mais rápidas, e que você vai embutir um tempo para refatoração em todas manutenções que você vai fazer. Se o gerente aceitar, ótimo. Caso contrário, encontre um outro emprego primeiro, depois pule fora. Dê preferencia a projetos onde você terá que desenvolver coisas novas, e não onde há apenas manutenção. Veja bem, eu disse preferência, sempre haverá manutenção. Normalmente as más empresas, geralmente consultorias e agências de publicidade, vendem o sistema com um prazo absurdo, entregam e depois contratam programadores para consertarem a cagada que fizeram.

Caso você consiga convencer seus superiores de que há necessidade de refatorar, vou dar algumas dicas. A primeira, e a mais importante: refatorar um sistema não é fácil. Pelo contrário, é bem difícil. Não é qualquer zé mané que conserta um sistema médio. É preciso técnica especializada e unidade da equipe em atingir esse objetivo.

Se o sistema for pequeno, a refatoração será mais fácil. No caso de um sistema médio, a mesma pode se tornar um pesadelo se as técnicas corretas não forem usadas. Primeiramente, você vai precisar do básico: sistema de controle de versão, um ambiente de homologação, etc. Depois, você vai precisar de técnica. Você vai precisar fazer testes unitários e de aceitação automatizados para garantir que você não quebre nada no sistema. Aconselho os livros abaixo:
Test Driven Development: By Example
The Art of Unit Testing: With Examples in .Net
Working Effectively with Legacy Code
Há outros, mas esses são fundamentais.

Os testes unitários servem para você fazer o sistema crescer saudavelmente, permitem que você refatore e tenha uma resposta rápida, mas não 100% precisa, da alteração que você realizou. Os testes de aceitação servem para você testar o sistema como um todo, uma funcionalidade do início ao fim. Geralmente eu escrevo testes de aceitação e depois testes unitários.

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

neófito wrote:

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.

Quanto as respostas anteriores, nunca ouvi tanta besteira assim na minha vida toda. É por isso que vejo tanto código maluco, projetos de R$800 mil afundando e toda sorte de maluquices nas empresas onde trabalho.

Você deve tentar convencer os gerentes que um código melhor resulta em manutenções mais rápidas, e que você vai embutir um tempo para refatoração em todas manutenções que você vai fazer. Se o gerente aceitar, ótimo. Caso contrário, encontre um outro emprego primeiro, depois pule fora. Dê preferencia a projetos onde você terá que desenvolver coisas novas, e não onde há apenas manutenção. Veja bem, eu disse preferência, sempre haverá manutenção. Normalmente as más empresas, geralmente consultorias e agências de publicidade, vendem o sistema com um prazo absurdo, entregam e depois contratam programadores para consertarem a cagada que fizeram.

Caso você consiga convencer seus superiores de que há necessidade de refatorar, vou dar algumas dicas. A primeira, e a mais importante: refatorar um sistema não é fácil. Pelo contrário, é bem difícil. Não é qualquer zé mané que conserta um sistema médio. É preciso técnica especializada e unidade da equipe em atingir esse objetivo.

Se o sistema for pequeno, a refatoração será mais fácil. No caso de um sistema médio, a mesma pode se tornar um pesadelo se as técnicas corretas não forem usadas. Primeiramente, você vai precisar do básico: sistema de controle de versão, um ambiente de homologação, etc. Depois, você vai precisar de técnica. Você vai precisar fazer testes unitários e de aceitação automatizados para garantir que você não quebre nada no sistema. Aconselho os livros abaixo:
Test Driven Development: By Example
The Art of Unit Testing: With Examples in .Net
Working Effectively with Legacy Code
Há outros, mas esses são fundamentais.

Os testes unitários servem para você fazer o sistema crescer saudavelmente, permitem que você refatore e tenha uma resposta rápida, mas não 100% precisa, da alteração que você realizou. Os testes de aceitação servem para você testar o sistema como um todo, uma funcionalidade do início ao fim. Geralmente eu escrevo testes de aceitação e depois testes unitários.

É...infelizmente essa não é a minha realidade. Tenho familia para sustentar. Já pensei igual a você. Se não tenho chances de "modificar" a arquitetura de desenvolvimento na empresa que trabalho (refatorar, testes unitarios, etc..etc...) vou tentar arranjar outro emprego. Porém, a maioria das empresas que eu achava que tinha o "perfeito" ambiente de trabalho, não pagavam muito bem. Por isso, estou na empresa que estou hoje e trabalhando de "bombeiro". Mas..todo ano tenho um reajuste e em Fevereiro estarei mudando de cargo. No meu caso, veja bem, no meu "momento" hoje...não sairia daqui...só por que tem uma empresa aqui do lado...que tem a "Fantastica Fabrica de Chocolate" la dentro. Mas não é por isso...que não estudo as boas praticas e concordo com elas...caso "apareça" uma melhor oportunidade, sim...claro que gostaria de tentar.

O problema é: Ate quando você vai fazer isso ? Pular de "galho em ganho" ? Sera que isso é bem visto no mercado ?

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.

também achei isso muito bem escrito.. acostume-se com isso por que é o que mais se tem no mercado mesmo, e acrescentando, é bom para você ser o detetive no inicio de projetos, é um bom privilegio que alguns conseguem ser o detetive (alguns que não precisam se sujeitar a serem bombeiros), mas além de detetive, é bom para a sua carreira ser bombeiro, então sempre que puder esteja preparado para ser os dois.

bestlinux wrote:O problema é: Ate quando você vai fazer isso ? Pular de "galho em ganho" ? Sera que isso é bem visto no mercado ?

E quem disse que eu pulo de galho em galho? E quem disse que não tenho família? Bom profissional, profissional com técnica, é valorizado. Veja bem, o tipo de empresa que faz o que está descrito neste tópico são consultorias, agências de publicidade, etc. Geralmente as empresas que desenvolvem para seu uso estão interessadas em qualidade, porque o sistema delas faz parte do próprio negócio. Se o sistema falha, há prejuízo. É tudo uma questão de decidir em qual lado você vai ficar.

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

neófito wrote:

bestlinux wrote:O problema é: Ate quando você vai fazer isso ? Pular de "galho em ganho" ? Sera que isso é bem visto no mercado ?

E quem disse que eu pulo de galho em galho? E quem disse que não tenho família? Bom profissional, profissional com técnica, é valorizado. Veja bem, o tipo de empresa que faz o que está descrito neste tópico são consultorias, agências de publicidade, etc. Geralmente as empresas que desenvolvem para seu uso estão interessadas em qualidade, porque o sistema delas faz parte do próprio negócio. Se o sistema falha, há prejuízo. É tudo uma questão de decidir em qual lado você vai ficar.

Desculpe....já trabalhei como CLT em um setor de desenvolvimento de uma grande empresa no qual utilizava o "proprio" software 24x7. Não era assim, infelizmente, bem que eu gostaria que fosse. Creio que não podemos "generalizar".

bestlinux wrote:

neófito wrote:

bestlinux wrote:O problema é: Ate quando você vai fazer isso ? Pular de "galho em ganho" ? Sera que isso é bem visto no mercado ?

E quem disse que eu pulo de galho em galho? E quem disse que não tenho família? Bom profissional, profissional com técnica, é valorizado. Veja bem, o tipo de empresa que faz o que está descrito neste tópico são consultorias, agências de publicidade, etc. Geralmente as empresas que desenvolvem para seu uso estão interessadas em qualidade, porque o sistema delas faz parte do próprio negócio. Se o sistema falha, há prejuízo. É tudo uma questão de decidir em qual lado você vai ficar.

Desculpe....já trabalhei como CLT em um setor de desenvolvimento de uma grande empresa no qual utilizava o "proprio" software 24x7. Não era assim, infelizmente, bem que eu gostaria que fosse. Creio que não podemos "generalizar".

Realmente, não podemos generalizar. Há casos e casos. Mas continuo com minha opinião, se você procurar, acaba encontrando um lugar melhor.

JWizard Membro desde: 01/10/2006 15:29:40 Mensagens: 2047 Offline

fabim wrote:
Depende irmao. Conheco uns Sistemas "zumbis" assim que sobrevivem a mais de 5 anos e nao tem data pra acabar.
Se o cliente ta pagando, e pagando MUITO, e vc recebendo bem, quero ver largar mao disso pra ganhar MENOS por algo LINDO, com designs perfeitos num mundo Orientado a Objetos Perfeitos.

Bom, repito, acho que sou o único doido do mundo, porque já larguei, e acredite, pra ganhar 50% a menos...

Ah, com família e tudo... minha forma de pensar é esta (que não quer dizer que é a mais correta do mundo): um ambiente assim, me deixará ferrado e destruído, como PJ se eu deixar chegar a esse ponto, quem se ferra sou eu. Logo, todo dinheiro ganho, será gasto com recuperação da saúde. Fazendo a matemática, saio para um lugar onde me satisfarei e viverei em paz. Não gastarei horrores com patologias adiquiridas... heuehueehuehe

Agora claro galera, isso vai de perfil pra perfil. Tenho conhecidos que conseguem e gostam de viver no meio do incêndio... realmente no meu Post anterior eu me equivoquei ao não citar os perfis... Ao colega criador do tópico, basta você achar o seu perfil.

Abs []

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

Nao Adriano, voce nao eh o unico, eu tbm ja fiz isso e fiz recentemente. Nao era 50%, mas sai pra ganhar menos. Os motivos nao sao por codigo ruim, mas porque eu estava de saco cheio das disputas politicas dentro da empresa.

Acho que as empresas que valorizam qualidade de código não querem saber se você sabe lidar com aplicação ruim, querem saber se você consegue produzir qualidade.

A questão principal para mim não é nem a qualidade do código atual, mas a filosofia da empresa para o desenvolvimento dos produtos.

Apesar do código porco ser realmente culpa do programador, geralmente vem de cima uma cultura para melhorar a qualidade do código/produto.

Implantar revisão de código, teste automatizado, entre outros é visto por muitos gerentes por aí como perda de tempo.

Se essa filosofia imediatista de "faz funcionar" incomoda, recomendo sim procurar um lugar com outra cultura.

A minha esperança é que essas consultorias que ganham no projeto e na manutenção (do projeto que não funcionou) fechem as portas por falta de desenvolvedores.

Infelizmente, sempre terá aqueles que preferem ganhar o seu salário independente da qualidade do que produz.
Para mim isso é equivalente ao médico que por desleixo deixa bisturi dentro do paciente após operação...
Ou engenheiro que aceita construir prédio com areia da praia e depois vê o negócio cair.

Enquanto não formos mais críticos com relação aos empregos que escolhermos ou ao modo de desenvolvermos a realidade continuará sendo essa: código mal feito funcionando a base de remendos.

Nao discordo de voce, o que eu quis dizer com a minha frase é que eu acho que muitos dos que vivem chorando porque pegam codigo ruim pela frente, na verdade nao sao capazes de produzir codigo decente. Entao chora porque nao entende o codigo, mas nao consegue arrumar. É obrigação do bom programador arrumar o que esta errado e existem tecnicas e ferramentas que possibilitam isso, cabe a nós aprender com quem ja passou por isso e usá-las.

As empresas que exigem que voce produza qualidade muito raramente vao te ensinar a fazer isso, a nao ser que voce aceite ganhar pouco, elas vao querer que voce ja seja capaz de produzir codigo de qualidade, o que é muito raro entre os que costumeiramente reclamam de codigo ruim.

Nao me entenda mal, eu tambem nao gosto de codigo ruim, mas cada vez mais eu tenho aprendido a lidar com eles.

Você deve tentar convencer os gerentes que um código melhor resulta em manutenções mais rápidas, e que você vai embutir um tempo para refatoração em todas manutenções que você vai fazer. Se o gerente aceitar, ótimo. Caso contrário, encontre um outro emprego primeiro, depois pule fora. Dê preferencia a projetos onde você terá que desenvolver coisas novas, e não onde há apenas manutenção. Veja bem, eu disse preferência, sempre haverá manutenção. Normalmente as más empresas, geralmente consultorias e agências de publicidade, vendem o sistema com um prazo absurdo, entregam e depois contratam programadores para consertarem a cagada que fizeram.

É justamente esse o ponto, voce nao tem que convencer ninguem de nada, voce tem que fazer e pronto. Se algo precisa ser refatorado voce tem que refatorar e ponto. E nao é aceitavel que voce demore mais do que 10% (ok, 20% em alguns casos) a mais do que demoraria pra fazer sem refatorar. Se alguem disser que vai levar 2 dias pra fazer algo que poderia ser feito em quatro horas, em nome de uma suposta melhoria de design, ninguem aceita. Se disser que vai levar 5 ou 6 é obvio que qualquer gerente vai concordar. Voce vai perder muito tempo de qualquer jeito até entender o que o código de fato faz e depois pra descobrir todos os efeitos colaterais que pode causar. Ora, entao porque ja nao comeca aplicando testes em cima do legado? Alem de proteger as falhas que voce pode causar, ele te ajuda a entender o que o codigo faz e uma vez que voce entendeu e pos testes, fica bem mais facil refatora AQUELA AREA (e nada mais) em que voce esta mexendo.

Dê preferencia a projetos onde você terá que desenvolver coisas novas, e não onde há apenas manutenção.

Nao sao todos que podem escolher onde vao trabalhar, mas sao muitos os que leem blogs sobre codigo bonito e acham que as empresas tem ter a base de codigo limpinha, certinha, só esperando por eles.

Sobre os livro que voce citou sao extraordinarios, (Refactoring, TDD e Working Effectivelly with Legacy Code, Clean Code, entre alguns outros) Ninguem deveria se dizer programador enquanto nao os conhecesse ainda que superficialmente. Claro, o dominio do que esta ali so vem com a pratica, mas o conceito bem formado todos deveriamos ter.

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