[quote=Bruno Laturner]O que a gerência diz sobre o assunto? Não. “Não temos recursos para alocar p/ o projeto.” “Não temos tempo.” “Não tá funcionando? Então deixa.”
Nessas horas eu fico no dilema, de uma lado o diabinho fala “Se quem deveria se importar não se importa, por que eu deveria?”, do outro o anjinho “Faça você mesmo, para o bem de todos.”
[/quote]
Cara, IMHO:
Provavelmente, o seu gerente tem essas métricas de 2 semanas em média de manutenção. Refatora os pontos mais críticos do(s) sistema(s) (onde a equipe sempre gasta tempo em manutenção) e anota esses pontos. Quando, na próxima manutenção, a equipe levar 2 dias mostre os dados brutos para os responsáveis. Aos dados brutos, junte os fatos como: mais tempo para conquistar novos clientes, mais tempo para outros projetos do mesmo cliente, mais tempo para tudo, etc.
Se os caras acreditarem em você, maravilha. Será mais uma empresa em que teremos o prazer de trabalhar. Se não, não sei o que propor.
Acho que essa questão impacta a todos nós programadores. Se amanhã alguém que implantou a qualidade na sua atual consultoria sair e arrumar emprego em outra que também se preocupa com a qualidade, teremos, no mínimo, mais programadores felizes. Se, ao menos, plantarmos a semente da qualidade por onde passarmos, com certeza as consultorias do Brasil serão modelo. E com isso ganhamos todos, só depende de nós.
[quote=celso.martins]Concordo com alguns pontos e discordo de outros.
No livro do Fowler existem alguns exemplos que não dizem respeito a responsabilidade de classes, falam de responsabilidades de métodos, por exemplo. Outros pontos falam em “desaninhar” ifs/fors, etc.
[/quote]
Quando disse classe estava incluso os métodos.
Pog não é isso. Assim qualquer código feito pro equipes ageis seria POG já que sempre é feito do jeito mais simples que funciona ( principio da parcimônia). Não. POG é a violação de principios básicos de OO como o Principio de Separação de Responsabilidade, Encapsulamento, IOC e injeção de dependência (o principio, não as ferramentas). Além disso é o não tratamento correto de exceções, o uso abusivo de flags, o uso incorreto dos tipos (String em vez de Date). Existem tb gambiarras de modelagem, mas isso são outros 500.
Por exemplo, um método que para somar de 1 a 100 faz um for não é elegante, mas não é POG. Não viola nenhum principio básico. Método elegante é usar a formula da série e obter a soma algebricamente.
Eu sei que vc está pensando elegante = uso de padrões. Ok, mas padrões não tornam o codigo correto. Existe POG mesmo quando usa padrões (basta usá-los errado).
Bom, então, um codigo que viole os principios básicos, é difícil de refactorar.
Por exemplo, um codigo que use numeros mágicos. Como vai refactorar sem ter a certeza do que está fazendo ?
Mas o uso de números mágicos é um problema de qualidade.
Aplicações de boas práticas, padrões e princípios traz qualidade ao codigo (obviamente, porque é dessa forma que se define qualidade) e de quebra legebilidade. Existe aquela máxima de que codigo bem escrito fala por si mesmo (não é preciso comentários)
Possivel é, mas é demorado e complexo. se o codigo não tiver protegido com testes ( test harness) é ainda mais arriscado.
Mudar codigo legado de baixa qualidade é um risco muito grande. É por isso que os gerentes não gostam de o mudar.
Mas o problema é que o risco vem da falta de qualidade do codigo e não do processo de alteração em si. Alterar é bom e não é arriscado, desde que o codigo tenha qualidade e existam teste. (claro que os testes vc pode adicionar antes de começar a alteração, mas normalmente codigo de baixa qualidade - aka que não respeita os principios de OO - é difícil de testar)
Recostruir (começar do zero) não é possível. Seria escrever outro programa. Sempre tem alteração.
Se vc tiver pro exemplo um serviço com interface e implementação e fizer uma segunda implementação (sem mudar a primeira) isso poderiamos pensar que é uma forma de reconstrução. Mas não é. É refactoração. E repare que só funciona porque vc respeitou o SoC para começo de conversa.
Acertar de primeiro seria perfeito. E ninguém é perfeito. (por isso que as politicas ageis já partem do principio que nunca será bom da primeira vez)
Mas existe uma diferença entre vc tentar desde o principio e só tentar quando dá @#$@#$.
Desde o dia 1 significa que vc esteve tentando desde o primeiro dia.
Qualidade é uma daquelas coisas que nunca é demais. O ponto é que existem dois tipos de codigo: o ruim e o bom.
Existe uma fronteira entre o ruim e o bom. Quando vc passa essa fronteira blz, tá valendo. É claro que vc pode aumentar o bom até ao otimo. Mas quando o codigo é ruim vc deve aumentar até ao bom.
Código ruim é porque não respeita as regras e/ou é gambe ( o tipo “fica assim depois mudo”).
eu acho que qualquer tempo passado melhorando o nivel de qualidade do codigo é bem gasto. Importa-me um pepino o que os gerentes acham. Não são eles que tem a responsabilidade pelo codigo , portanto, não sai nada enquanto não estiver certo.
[quote=Bruno Laturner][quote=sergiotaborda]
A qualidade do codigo tem que estar lá desde do dia 1. E não ha desculpa para não estar. Tudo o resto pode estar errado, excepto a qualidade do codigo. [/quote]
Tudo muito lindo, mas da última vez que chequei ainda não tinham inventado máquina do tempo para corrigir códigos que não tem qualidade desde o dia 1. Por incrível que pareça, nesta realidade que vivemos código ruim é muito mais regra que exceção.
E aí, deixa o lixo ficar um lixo? Deixa os prazos de hoje, amanhã, mês que vem e do resto do ano estourarem por causa desse código?
[/quote]
Sim!!!
Os gerentes são bichos que funcionam na base do susto. Enquanto eles não entenderem que codigo ruim é prejuizo o quadro atual não vai mudar. Vc vê muito codigo ruim porque muitos programadores simplesmente ignoram a qualidade quando o gerente manda “dar um gás”.
È isso que tem que mudar.
O médico aceitaria que o Administrador do hospital mandasse “dar um gás” na operação que o médico está fazendo à sua mãe ? Então porque aceita baixar o nivel de qualidade quando o gerente manda dar um gás ?
É problema cultural. Eu sei. Mas enquanto não responder à altura o problema continua. E é vc que vai ter que viver com eles. Vc e todo o mundo que é programador. É uma questão de respeito pela sua dignidade profissional e da dignidade da propria profissão. Existem muitos programadores fanfarrões embormadores que fazem pog encadeada ( uma atrás da outra) e não recebem nenhum “castigo” aliás são até mais valorizados pelos gerentes porque são rápidos.
RAD é coisa de quem não sabe programar (aka gerente). è vc como desenvolvedor que tem que impor as regras de qualidade.
Se alguem lhe disser que quer mais rápido vc responde que só se diminuir a qualidade. A pessoa vai dizer (se for idiotA) “então diminui” e vc responde “envie-me um email pedindo isso então”. Ninguem vai , cosncientemente, dizer-lhe para diminuir a qualidade. Se o fizer é responsabilidade dele, não sua. Quando o sistema começar a travar daqui a um ano, e vierem encher o seu saco vc mostra os emails pedindo que se diminuísse a qualidade.
Agora vc deve estar pensando “se eu não fizer o que me mandam, despedem-me”
É verdade, mas esse pensamento é de coisa de escravo. O patrão bate mais o cara continua. Diga Não. Manda o cara pastar ( ou cobra extra). Vc não merece trabalhar em uma empresa que não preza pela qualidade.
A resposta é “não, não está funcionando” e enumera uma lista de problemas. Se poder mostrar ums barras vermelhas do junit melhor. Faça um relatório e apresente-o formalmente. Ai o cara tem que viver com a responsabilidade.
Ninguém é santo ou anjo. Vc deve fazer direito porque vc se importa. Isso é a prova que vc é um profissional No dia que vc deixar de importar vc é mais um zé que sabe escrever código mas não sabe programar.
Vc deveria se preocupar para satisfazer a sua própria consciência e a ética profissional Os outros profissionais vão agradecer-lhe e vê-lo como um igual.
Faça vc mesmo para o seu próprio bem e como respeito a todos os outros profissionais que sofrem o mesmo para manter a mesma dignidade profissional que vc tenta.
Não estou dizendo é fácil. Estou dizendo que é certo.
Se nem sequer tentarmos, ai é que nunca vai mudar mesmo…
Isso nao é verdade, qualidade nunca é uma constante por mais controlado que o ambiente seja e sem refatoracao ela degrada na medida que a codificacao evolui. Portanto se vc refatora é pra alcancar uma condicao melhor que anterior, vc esta melhorando a qualidade sim!
Nao é a posteriori, é desenvolvimento incremental!!!
Mas aqui ate concordo contigo, refactoriong sem uma boa cobertura de testes automatizados por exemplo é um tiro no pe. De outra forma como vc pode garantir que novos bugs nao sao introduzidos quando volta alterar aquela parte do codigo?
Então, em Java, qualquer mudança de linha já seria refatoração. =)
Opa, opa. Não falei simples. =)
Algo que foi resolvido com uma solução simples, no meu entender, não quer dizer POG. Existem pessoas que em 5 minutos escrevem código com mais qualidade que POGueiros. E com certeza a sua definição de POG está muito mais completa que a minha. Eu fiz uma generalização.
Concordo sem tirar e nem por.
Sim, é por essas razões que precisamos escrever testes consistentes (porque muito provavelmente ainda não existem na aplicação a ser refatorada) antes de começar a refatorar. Como já vi que você escreveu isso mais abaixo, não creio que seja um ponto de discordância. Alguns pontos tornam a refatoração mais difícil (como o próprio Fowler cita em seu livro), mas não quer dizer que não se deva refatorar. Em projetos de longa duração e com alta taxa de manutenção, na minha visão, a decisão de refatoração, se necessária, deve ser tratada com muita atenção.
Riscos existem. Acho que o risco de um projeto falhar é mais preocupante. Para atuar em projetos dessa natureza de risco é necessária uma equipe experiente em refatoração e tempo. Mesmo assim, acredito que o ganho ainda exista.
O sentido que usei na palavra reconstruir é o mesmo que a engenharia usa com prédio velho: Implodir e reconstruir. Não creio que tenha problemas na aplicação deste sentido. Quando esquecemos o legado e construimos uma aplicação com os mesmos requisitos, creio eu estejamos reconstruindo.
Bingo. Esse é o meu pensamento. E esse “tentando” pode estar envolvendo algumas pequenas refatorações durante o processo.
[quote]
Sim, mas acho que você esteja fazendo uma divisão radical entre gambiarra e qualidade total. Pelo que já vi por aí, existe um meio termo. Existem códigos que não são gambiarras, mas que também podem melhorar na qualidade.
Qualidade é uma daquelas coisas que nunca é demais. O ponto é que existem dois tipos de codigo: o ruim e o bom.
Existe uma fronteira entre o ruim e o bom. Quando vc passa essa fronteira blz, tá valendo. É claro que vc pode aumentar o bom até ao otimo. Mas quando o codigo é ruim vc deve aumentar até ao bom.
Código ruim é porque não respeita as regras e/ou é gambe ( o tipo “fica assim depois mudo”).
eu acho que qualquer tempo passado melhorando o nivel de qualidade do codigo é bem gasto. Importa-me um pepino o que os gerentes acham. Não são eles que tem a responsabilidade pelo codigo , portanto, não sai nada enquanto não estiver certo. [/quote]
Creio que nem divergimos tanto assim. Acho que temos as mesmas idéias e, ao invés de estarmos discutindo, estamos destrinchando um assunto, o que para mim é muito bom também.
Você levou o assunto exatamente para onde eu estava imaginando.
Para mim, nem tiro no pé é. É tiro na cabeça. Se você vai mexer em algo que está em produção e não está totalmente coberto por testes, construa duas asas de folha de A4 e pule do vão central da ponte rio-niterói. Estará se arriscando menos.
hummm… qualidade que degrada… como é que a qualidade degrada ?
Suponho que pela introdução de itens de baixa qualidade.
Mas eles só são introduzidos porque as pessoas não se vigiam ( não seguem as diretivas de qualidade)
Logo, se a qualidade se degrada é por que deixou de haver preocupação com ela.
Vc refactora nessa hora porque “não ha desculpa para a falta de qualidade”. Se houvesse , vc simplesmente deixava ficar.
Portanto, acho que é verdade sim que tudo pode estar errado exceto a qualidade. ( já que quando ela está errada, vc alterar para ficar com. mas isso nada mais é que manter o padrão de qualidade,que é qualidade em si mesmo.)
não me referi a metodologias ageis.
Me refiro a que o num primeiro passo o cara não quis saber de usar os principios OO corretamente e depois, mais tarde quando começa a dar pepino ele vem tentar remediar o problema. Mas ele só fez errado da primeira vez porque não colocou a qualidade em primeiro lugar.
Manter a qualidade não significa ter muito trabalho, apenas seguir alguns principios. O problema é quando o povo tem preguiça de seguir até os princípios mais simples (como p.x. não usar numeros mágicos)
Vamos supor que o código de um componente tem a estrutura de uma bola de espaguete coberta de lama de esgoto e o retardado que o criou nunca ouviu falar de nada parecido com JUnit. A documentação se parece ou com uma parede completamente branca ou com uma parede completamente pichada de coisas ilegíveis e sem sentido.
No entanto aquela porcaria está atrapalhando o desenvolvimento e atraindo cada vez mais e mais bugs e alguém precisa dar um jeito antes que seja tarde demais. E aí, o que fazer? O ideal seria trocar ou refatorar o componente, mas como fazer isso?
Não adianta sentar e chorar, técnicas para abordar isso existem, mesmo que envolvam algum risco.
[quote=victorwss]Vamos supor que o código de um componente tem a estrutura de uma bola de espaguete coberta de lama de esgoto e o retardado que o criou nunca ouviu falar de nada parecido com JUnit. A documentação se parece ou com uma parede completamente branca ou com uma parede completamente pichada de coisas ilegíveis e sem sentido.
No entanto aquela porcaria está atrapalhando o desenvolvimento e atraindo cada vez mais e mais bugs e alguém precisa dar um jeito antes que seja tarde demais. E aí, o que fazer? O ideal seria trocar ou refatorar o componente, mas como fazer isso?
Não adianta sentar e chorar, técnicas para abordar isso existem, mesmo que envolvam algum risco.[/quote]
Neste ponto eu concordo com o sergiotaborda que a preocupacao com a qualidade tem que ser desde o inicio procurando boas praticas e mantendo a aparencia de codigo simples como sinal de qualidade (ja que ninguem se propos a definir o que é qualidade!). Porque nao da pra ficar melhor depois, a reescrita quase sempre é necessaria. Mas nao basta reescrever, provavelmente o processo tera que melhorar, cabecas deverao rolar, porque uma merda grande assim como vc descreveu nao fica pronta de um dia pro outro, nessas horas é facil colocar a culpa na ponta, que nao duvido nada talvez seja um estagiario, mas o problema é mais embaixo.
Agora se nao foram vcs que construiram o componente entao da proxima vez procurem alguem preparado para tarefa, se vc estiver dando consultoria basta esquecer tudo isso e lembrar do cheque no final do mes.
Como assim ninguém definiu qualidade? Nem vi mensagem solicitando isso. =)
Bem, Mr Eric Braude nos diz que seguindo os princípios de correção, robustez, flexibilidade, reusabilidade e eficiência construiremos uma aplicação de qualidade. Além desses princípios de qualidade eu incluiria a legibilidade. Ela pode derivar de algum princípio descrito por Braude? Creio que não. A saber, algo pode ser correto, robusto, flexível, reusável e eficiente sem ser claramente legível para o ser humano.
As vezes precisamos seguir um dos princípios em detrimento de outros. Por exemplo, para ser flexível, pode ser que degrademos um pouco a eficiência. Braude nos ensina que a qualidade é alcançada com o correto equilíbrio desses princípios.
[quote=cmoscoso]
Porque nao da pra ficar melhor depois, a reescrita quase sempre é necessaria. Mas nao basta reescrever, provavelmente o processo tera que melhorar, cabecas deverao rolar, porque uma merda grande assim como vc descreveu nao fica pronta de um dia pro outro, nessas horas é facil colocar a culpa na ponta, que nao duvido nada talvez seja um estagiario, mas o problema é mais embaixo.
Agora se nao foram vcs que construiram o componente entao da proxima vez procurem alguem preparado para tarefa, se vc estiver dando consultoria basta esquecer tudo isso e lembrar do cheque no final do mes. [/quote]
Acredito que o Victor tenha feito uma suposição ao extremo para mostrar que mesmo assim é possível manter a calma e aplicar as técnicas corretamente para enxergar a luz no fim do túnel.
Acho que cabeças devem rolar quando alguém não está nem um pouco preocupado com a qualidade, não por “apenas” não saber o caminho. Se alguém está tentando mostrar o caminho e o cara está pouco se lixando, aí sim, corta a cabeça dele.
Ok, como o Celso já colocou na mensagem logo seguinte a sua, eu estava colocando uma situação extrema.
Vamos supor que o retardado que fez aquele componente já tenha sido punido com uma execução da forma mais cruel, dolorosa e sangrenta possível, e até hoje a alma dele está queimando no inferno implorando o perdão.
Mas, independente de cabeças terem rolado, dinheiro e tempo ter sido perdido, lições serem aprendidas do pior jeito possível, o componente ainda está ali atrapalhando. E alguém tem que fazer alguma coisa com aquele componente.
E então, o que pode ser feito para atacar o problema?
EU pessoalmente, iria para um destes dois caminhos, dependendo do que eu encontrasse no meio os fios de espaguete:
A. Refatoramento mesmo sem ter testes unitários, focando em tentar separar em partes menores, uma vez que é mais fácil lidar com coisas menores. Ah, mas e a possibilidade de introduzir bugs e a possibilidade de isso e a possibilidade de aquilo? Daí, tem que ter coragem, inteligência, versionamento inteligente, e revisar 20 vezes cada mudança, mas não se pode simplesmente cruzar os braços e chorar.
B. Tentar recriar outro componente do zero. Aqui é estudar o código, debuggar, fazer alguns testes de mexer com o código para ver o que acontece, e no fim conseguir descobrir qual é o objetivo do componente e o que ele se propõe a fazer.
Ou seja, é usar engenharia reversa. Normalmente o que acaba saindo é um meio-termo ou uma mistura de A e B.
Se a merda tá feita, não adianta: Alguém tem que limpar.
Quer um exemplo para brincar? Pegue um dos códigos do IOCCC e tente desofuscá-lo.
[EDIT: Uma vez, tive que pegar uma godclass extremamente gambiarrosa, implementando umas 7 ou 8 interfaces e herdando de uma coisa nada a ver, com um switch dentro de um método recursivo com mais de 3000 linhas, sem nenhum comentário inteligível, e tive que dar um jeito. Refatorei ela em 29 classes distintas.
EDIT 2: Um trecho dela eu postei aqui.]
Por que não escrever os testes, se os requisitos são conhecidos? Claro que não desprezo o versionamento inteligente e a revisão. Mas não seria mais seguro usar uma parte do tempo despendido com a tarefa de refatorar escrevendo os testes? Existe alguma situação que torne impossível escrever os testes?
[quote=celso.martins][quote=victorwss]
A. Refatoramento mesmo sem ter testes unitários, focando em tentar separar em partes menores, uma vez que é mais fácil lidar com coisas menores. Ah, mas e a possibilidade de introduzir bugs e a possibilidade de isso e a possibilidade de aquilo? Daí, tem que ter coragem, inteligência, versionamento inteligente, e revisar 20 vezes cada mudança, mas não se pode simplesmente cruzar os braços e chorar.
[/quote]
Por que não escrever os testes, se os requisitos são conhecidos? Claro que não desprezo o versionamento inteligente e a revisão. Mas não seria mais seguro usar uma parte do tempo despendido com a tarefa de refatorar escrevendo os testes? Existe alguma situação que torne impossível escrever os testes?
Abraços.[/quote]
Sim, você escreve testes unitários também (esqueci de dizer o mais importante :oops: ). Obviamente, assim que você já conseguir extrair algum conhecimento sobre o comportamento do negócio. Principalmente para evitar regressões.
Mas, frequentemente, você terá que fazer mudanças grandes o suficiente na estrutura que modificará a API pública dela e isso quebrará os testes. Mas pode ser que isso seja inevitável.
Se você conhecer os requisitos é mais fácil. Mas as vezes o negócio está tão feio que nem os requisitos dele são conhecidos.
e sem refatoracao ela degrada na medida que a codificacao evolui. Portanto se vc refatora é pra alcancar uma condicao melhor que anterior, vc esta melhorando a qualidade sim!