Refatoração: A questão

Me preocupa sao consideracoes como essas vindas de um perfil tecnico, para o produto final vejo riscos em ter um profissional desses definindo o que é bom ou nao para o sw que esta sendo escrito. Mas se o seu “lider” ee na verdade o papel de gerente, que lida com outros assuntos igualmente importantes mas que passa longe de escrever o codigo em si, eu nao vejo pq a principio ter essa discussao sobre refactoring. Um(a) programador(a) deve saber refatorar quando ha compromisso com a qualidade daquilo que esta sendo construido, seja qual for o motivo que levou a querer adotar essa tecnica.

E nao preciso de autorizacao pra fazer aquilo que deveria ser trabalho meu e da equipe de desenvolvimento. Da mesma forma, sempre deve-se levar em conta o perfil da equipe que vc integra. Se suas ideias nao estiverem alinhadas com a da maioria vc passa a ser considerando risco para o projeto. Ainda que reconhecam a validade dos seus argumentos vc é um sabotador, nao alguem que vai melhorar o processo.

Cara, a discussão em torno da refatoração é por um motivo simples: Acredita-se que está perdendo dinheiro. E numa visão simplista, sim está. O custo do projeto é medido em horas. Cada hora melhorando algo que já funciona é “um desperdício” de dinheiro, numa visão imediatista. O que quero tentar mostrar para eles é que essa aparente perda, se transforma em ganho, se somar os benefícios de uma manutenção eficiente em torno do ciclo de vida da bagaça.

Quando é projeto de vida curta, até entendo. Mas em softwares que não tenham uma previsão inicial para sair do ar e que a manutenção será constante, acho que a qualidade é obrigação. Por isso não tem choque. E a equipe é sensacional. Está tendo uma troca de idéias.

Acho que atacar as capacidades de cada um também não é o caminho. O cara é um monstro em C, conhece programação.

O Fowler passou por isso e conta a história na introdução do livro Refactoring. Ele propos 2 semanas de reajuste e recusaram. 6 meses depois o projeto falhou e Kent Beck foi chamado para recomeçar.

Isso acontece nas melhores famílias.

EDIT: Ele não é exatamente o gerente. Ele participa do dia-a-dia da equipe, discute modelagem, essas coisas. Acima dele tem um gerente.

Abraços

Tem uma frase célebre que muito gerente usa errado: “Quality is free.” A interpretação que eles dão é a que o seu líder deu, de que não é preciso investir em qualidade, basta cobrar do peão que faça certo da primeira vez. Na verdade, quem criou essa frase queria dizer justamente o contrário: invista em qualidade, porque essa grana volta lá na frente.

Eu já passei por dois projetos de longa duração em que houve o refactoring quando a qualidade do código caiu tanto que se começou a falar em cancelar o projeto e re-escrever o sistema. Aí apareceu o budget pra parar tudo por algumas semanas e arrumar pelo menos os problemas mais graves.

A propósito, Celso, nesse projeto não existe change request, né? Afinal, se os analistas de negócio seguirem o RUP corretamente, não haverá nenhum motivo para rever os requisitos do sistema, certo?

celso.martins:

Cara, a discussão em torno da refatoração é por um motivo simples: Acredita-se que está perdendo dinheiro. E numa visão simplista, sim está. O custo do projeto é medido em horas. Cada hora melhorando algo que já funciona é “um desperdício” de dinheiro, numa visão imediatista. O que quero tentar mostrar para eles é que essa aparente perda, se transforma em ganho, se somar os benefícios de uma manutenção eficiente em torno do ciclo de vida da bagaça.

Quando é projeto de vida curta, até entendo. Mas em softwares que não tenham uma previsão inicial para sair do ar e que a manutenção será constante, acho que a qualidade é obrigação. Por isso não tem choque. E a equipe é sensacional. Está tendo uma troca de idéias.

Acho que atacar as capacidades de cada um também não é o caminho. O cara é um monstro em C, conhece programação. Talvez ele ainda não tivesse visto esse ganho na frente. Isso acontece com qualquer um. O importante é saber ouvir e quando o argumento fizer sentido, reconhecer.

O Fowler passou por isso e conta a história na introdução do livro Refactoring. Ele propos 2 semanas de reajuste e recusaram. 6 meses depois o projeto falhou e Kent Beck foi chamado para recomeçar.

Isso acontece nas melhores famílias.

Acho valida sua atitude mas como lider nao me convenceria nem um pouco trocar o processo atual, a visao imediatista que funciona (supondo que esteja!), por possiveis beneficios futuros…

Por outro lado, talvez o proximo passo para uma equipe motivada seja por conta propria, ou seja sem o aval do lider, fazer o que acha certo, e no final mostrar resultados positivos ao inves de especular sobre os beneficios.

celso.martins:

EDIT: Ele não é exatamente o gerente. Ele participa do dia-a-dia da equipe, discute modelagem, essas coisas. Acima dele tem um gerente.

Abraços

Ele define a arquitetura e garante que esteja sendo cumprida?

Repare, nao estou falando de requisitos nem de UML, mas escrever e inspecionar codigo, testes, integracoes, etc.

rubinelli:

A propósito, Celso, nesse projeto não existe change request, né? Afinal, se os analistas de negócio seguirem o RUP corretamente, não haverá nenhum motivo para rever os requisitos do sistema, certo?

Acho que algo como a XP ou o SCRUM também trará benefícios grandes, mas um passo de cada vez. Mas, primeiro temos que nos preocupar mais com a qualidade, refatorando ou não, ao invés de somente focar nos prazos e sair fazendo de qualquer jeito. Algumas vezes dá para focar no prazo e na qualidade. O problema é o pensamento do “tempo perdido”, pois, as vezes, mesmo com tempo, as pessoas achavam que seria um desperdício de tempo refatorar. Acho que mudança de mentalidade nesse ponto é um salto grande.

Não são “possiveis beneficios futuros”. Na minha ótica, isso é tão certo quanto 2 + 2 = 4. Vamos lá.
Supondo que eu tenha uma média de 5 manutenções mensais simples em determinado sistema legado. Cada manutenção leva, em média, 2 dias para ser implementada e testada. Refatoramos o sistema e percebemos que esse tempo de manutenção caiu para 2 horas.

Obs: Já trabalhei em uma consultoria de sistemas em Delphi que gastava 2 semanas para entregar manutenções ridículas. Tudo era orientado a eventos e alguns tinham cerca de 300 linhas fazendo umas 20 coisas diferentes. Tentei implementar a OO e fui demitido.

Isso significa que:

Antes
8 * 2 * 5 = 80 horas usadas com manutenção do sistema

Depois
8 * 5 = 40 horas para a refatoração
2 * 5 = 10 horas usadas com manutenção do sistema
Total de 50 horas no primeiro mês e 10 horas nos meses subsequentes

Só no primeiro mês, já está estampada a diferença. Projete isso nos próximos 12 meses. E não é especulação. Os benefícios extraidos das boas práticas de desenvolvimento é fato comprovado pela experiência.

Alguns poderiam dizer que: Ahhh isso é benefício para o cliente e não para a consultoria. Para mim isso é outra visão superficial. O motivo é simples. Se você consegue fazer algo em 1/8 do tempo que era necessário anteriormente, você, na visão da gestão empresarial, está sendo mais eficiente. Você está fazendo mais com menos recursos. Eu diria que você está sendo, inclusive, mais competitivo, isto é: fazendo mais e melhor com menos recursos. No atual cenário da economia mundial, só há espaço para os competitivos.

Seu cliente fica feliz, você fica feliz, sua consultoria fica feliz. Por que sua consultoria DEVERIA ficar feliz? Porque, ao invés de estar concentrando esforços e se desgastando em reuniões para convencer o seu cliente de que as 80 horas foram necessárias (o que quase nunca é uma tarefa fácil), você estará concentrando esforços e se desgastando para conquistar novos clientes e, assim, estará solidificando as bases da sua empresa, garantindo uma penetração maior no mercado. E, provavelmente, utilizando o mesmo pessoal.

Cara, não esquenta a cabeça com isso. A equipe é motivada e gozamos de relativa liberade para executar nossos afazeres.

A arquitetura é definida em reuniões com os mais experientes da fábrica, como eu disse.

Abraços.

Como falei, mesmo que vc esteja certo dos beneficios existe uma distancia entre a teoria e a pratica. Se a equipe toda sente confiante nao ha pq nao tentar. Mas existem pessoas que simplesmente apreciam nao ter que tomar certas decisoes pelos outros.

celso.martins:

A arquitetura é definida em reuniões com os mais experientes da fábrica, como eu disse.

Abraços.

Entao vc tem varios lideres? Qual a opiniao deles sobre refactoring?

cmoscoso:

Entao vc tem varios lideres? Qual a opiniao deles sobre refactoring?

Cara, a idéia não é discutir a estrutura da equipe. E nem posso fazer isso. A idéia é discutir o impacto da refatoração, aparentemente negativo, no custo de um projeto.

Abraços.

bom nao vou mentir vou o texto mais idiota que ja li sobre a refatoracao. Quem respondeu o texto nao tem ideia do custo da manutencao de software dentro do projeto. E outra somente os bons programadores que tem codigos faceis de serem lidos, e que preservem a flexibilidade dentro de um software caso contrario, entra na gambiarra. É mais simples e facil programar, pelo “eu acho melhor ir assim, pq eu consigo entender”

Achei importante uma pequena apresentacao sobre refatoracao e anexei… para quem nao conhece o assunto… e tem um post no meu blog sobre
Refatoracao e manutencao de software

flw! abraco!

Não sei porque as pessoas tendem a criticar duramente outras pessoas que não compartilham da mesma opnião. Já disse que pode ser uma visão imediatista e, para aplicações de vida curta, eu até entendo que justifique. Encontrei muita gente assim ao longo da minha carreira. Como eu disse, no início do ano desmotivei com uma situação em que fui proibido de desenvolver uma aplicação OO. Em pleno 2008. Imagina refatorar os legados.

Interessante a sua apresentação.

Acho que a nossa postura deva ser de diálogo e demonstração de fatos. Assim poderemos ter uma mudança de mentalidade no local onde trabalhamos. Canso de ver gente reclamando (e não estou usando onde trabalho como exemplo) que essa forma de trabalho não dá, que não concorda com muitos pontos e deixa tudo por isso mesmo. Muitas vezes, por falta de coragem de falar com alguém que possa resolver. Ao invés de tentar mudar, ou aceita ou pede demissão e critica duramente o modelo. Assim não vamos conseguir nada.

Acho que essa mudança de mentalidade depende dos profissionais agirem e não esperar que gerentes ou quem quer que seja mude de opnião como em um passe de mágica.

Abraços.

celso.martins

Aqui vai minha idéia de refatoração:

Este tipo de “atividade” sempre existiu (baseado no que já lí e vivi nos anos 80 e 90), apenas o nome e a maneira com que é tratado ficou um pouco diferente.
Partindo do principio que +ou- 80% do tempo gasto em um projeto é em cima de manutenção (idéia que vem de muito tempo também) fica claro que o cuidado com a qualidade do código nunca será um desperdício.
Mas por que o nível satisfatório do código não é atingido logo na primeira vez que é feito? Se entendi bem esta pergunta é o centro do papo que vc teve com teu camarada; na minha opinião a resposta é a seguinte: sintese, é essa resposta. O desenvolvedor, em um nível mais amplo, poderá ter problemas de sintese em dois pontos: no entedimento do sistema (regras, fluxos etc…) e os recursos da linguagem que serão aplicados na solução; a medida que a sintese aumenta nos dois pontos melhores soluções são encontradas para o mesmo problema. Toda vez que escrevemos um código e materializamos a nossa solução, a nossa sintese sobre o problema aumenta fazendo com que consigamos criar uma solução melhor do que a aplicada anteriormente.
Logo, quando falamos de refatoração ou qualidade de código estamos indiretamente falando de um fenomeno (entre outros) que ocorre ao se tentar entender as coisas, isso acontece em todo universo não só na computação.
Quem paga a melhoria do código? Na minha opinião depende muito do contexto, se o projeto foi planejado pensando nesta questão, ele mesmo paga; as vezes um atividade leva menos tempo do que a prevista, logo a coisa já está paga. Se vc for como eu que é um pouco perfeccionista não importa quem irá pagar se o projeto ou eu; já fique até mais tarde para melhorar código sem receber pelo simples prazer de saber que fiz melhor e que com isso me tornei um desenvolvedor melhor e por ai vai…

flws

celso.martins:

Cara, a discussão em torno da refatoração é por um motivo simples: Acredita-se que está perdendo dinheiro. E numa visão simplista, sim está. O custo do projeto é medido em horas. Cada hora melhorando algo que já funciona é “um desperdício” de dinheiro, numa visão imediatista. O que quero tentar mostrar para eles é que essa aparente perda, se transforma em ganho, se somar os benefícios de uma manutenção eficiente em torno do ciclo de vida da bagaça.

Refactoração (esse termo não existe, mas ok…) só funciona quando vc tem codigo de qualidade.
PEgar um POG e “des-pogá-lo” não é refactoração.
Refactoração acontece quando vc entende melhor o sistema e entende que algo está errado com a responsabilidade das classes.

Portanto, refactoração não tràs melhor qualidade ao seu sistema, trás mais valor ao sistema. Deste ponto de vista não é uma perda de tempo nem de dinheiro. (O custo medido em horas é uma analepse do seculo passado)

Agora, parece-me que vc está falando de “alterar o codigo que está ruim”.vou chamar a isso refinamento só para destinguir o conceito subjacente embora possamos chamar de refatoração.

Ora refinamento é bom na medida que :

1. elevar o valor do sistema ( o mesmo que refactoração)
2. elevar a qualidade do codigo.

Repare que para fazer refactoração vc precisa de codigo de boa qualidade para começar. Esse codigo só vem de duas formas:a) os programadores se preocupam com a qualidade a incluem à partida , b) os programadores injetam qualidade à posteriori.

Vc faria um refinamento para elevar a qualidade do codigo à posteriori.
Esta ação é perda de tempo e dinheiro ? Não. A menos que vc ache que qualidade não é bom. (alguns acham)
É correto aceitar que o gerente diga que não pode gastar tempo com isso ?
Depende. Se foi vc a fazer vc pode gastar tempo, mas isso deve impactar directamente em si já que foi vc que colocou pouca qualidade para começo de conversa.
Se o código é legado não. Contudo, se o codigo é legado, o refinamento deve apenas acontecer como pré-requisito de uma efacotração. Ou seja, se não pensa em mudar alguma coisa mais “subtancial” no sistema, não ha porque fazer refinamento.

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.

Eu costumo dizer que o objetivo ao construir um software não é que ele funcione, é que ele seja facil de alterar (manter).
Se funciona otimo, se não funciona e é facil de alterar, rápidamente se coloca a funcionar.

Qualidade de código injetada à posteriori é muito cara porque demora muito para as pessoas entendenrem as gambs feitas antes (até que elas mesmas fizeram). Boas práticas podem ajudar a aumentar a qualidade desde o dia 1, mas é preciso impor o padrão de qualidade. Isso, sem duvida, é o papel do lider tecnico.

Não ha desculpa para a falta de qualidade. Qualquer um que diga o contrário está enganado. E tem 2 saidas: a) desistir de desenvolvimento, b) aprender dar qualidade ao codigo

Colocar qualidade no codigo não é uma necessidade para o cliente, mas deve ser para o programador. Se ele quer ter orgulho do seu trabalho, claro…

fantomas:

celso.martins

Aqui vai minha idéia de refatoração:

Este tipo de “atividade” sempre existiu (baseado no que já lí e vivi nos anos 80 e 90), apenas o nome e a maneira com que é tratado ficou um pouco diferente.
Partindo do principio que +ou- 80% do tempo gasto em um projeto é em cima de manutenção (idéia que vem de muito tempo também) fica claro que o cuidado com a qualidade do código nunca será um desperdício.
Mas por que o nível satisfatório do código não é atingido logo na primeira vez que é feito? Se entendi bem esta pergunta é o centro do papo que vc teve com teu camarada; na minha opinião a resposta é a seguinte: sintese, é essa resposta. O desenvolvedor, em um nível mais amplo, poderá ter problemas de sintese em dois pontos: no entedimento do sistema (regras, fluxos etc…) e os recursos da linguagem que serão aplicados na solução; a medida que a sintese aumenta nos dois pontos melhores soluções são encontradas para o mesmo problema. Toda vez que escrevemos um código e materializamos a nossa solução, a nossa sintese sobre o problema aumenta fazendo com que consigamos criar uma solução melhor do que a aplicada anteriormente.
Logo, quando falamos de refatoração ou qualidade de código estamos indiretamente falando de um fenomeno (entre outros) que ocorre ao se tentar entender as coisas, isso acontece em todo universo não só na computação.
Quem paga a melhoria do código? Na minha opinião depende muito do contexto, se o projeto foi planejado pensando nesta questão, ele mesmo paga; as vezes um atividade leva menos tempo do que a prevista, logo a coisa já está paga. Se vc for como eu que é um pouco perfeccionista não importa quem irá pagar se o projeto ou eu; já fique até mais tarde para melhorar código sem receber pelo simples prazer de saber que fiz melhor e que com isso me tornei um desenvolvedor melhor e por ai vai…
flws

É exatamente dessa forma que eu penso. E já virei algumas noites melhorando coisas que eu mesmo fiz e que os outros fizeram, sem custo nenhum para ninguém. Só para o meu sono, mas com o benefício de ver algo bem feito no dia seguinte.

Abraços.

Concordo plenamente, Sérgio.
Eu só acrescentaria uma sugestão a todos os colegas: cuidado ao criticar publicamente um programa, pois ele pode ter sido feito por você!
Quem gosta de fazer bem feito está sempre aprendendo e evoluindo, então é natural que, hoje, faça melhor do que há algum tempo atrás.
Aliás, um bom profissional atinge um bom grau de desenvolvimento humano quando, ao abrir um programa para manutenção, resiste à tentação de ver quem é o autor. Isto é só perda de foco e de tempo.

É por isso que a recomendação é que não se coloque autor no código.
Quando trabalha sozinho vc já sabe que foi vc. Quando em equipe , não interessa quem fez.
Tá errado ? corrige e pronto.

Abaixo o tag @author !

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. Não estou falando de POG. Meu conceito de POG é: uma solução que você poderia ter dado de uma forma mais simples e elegante mas, provavelmente por falta de conhecimento, fez de qualquer jeito. Essas soluções precisam ser refeitas e não refinadas ou refatoradas.

Acredito que se você está trazendo legibilidade, no mínimo, ao código, você está aumentando a qualidade.

Sim, estou falando disso. E englobando tudo. Refinamento de responsabilidade de classes e métodos, ifs/fors aninhados e mais o sem número de pontos levantados no livro do Fowler.

Acho que, devido a minha visão de que a refatoração traz sim qualidade ao código, é possível realiza-la a partir de código com pouca qualidade. Acho que o o ponto a ser definido aqui é se a refatoração vai levar mais tempo que a reconstrução. Se sim, acho que ela é desnecessária. Melhor reconstruir. Acho que a refatoração de códigos legados entra na justificativa de tempo de manutenção do meu outro post.

E sim, claro que já refatorei código meu (e continuo refatorando). Já cansei de terminar uma solução, não gostar e começar a pensar em quebra e remanejamento de métodos, etc. Já virei noites por achar que algo não cheirava bem. E como o fantomas disse, sim, procuro ser perfeccionista. Ainda não sei se é qualidade ou defeito, mas hoje tenho muito mais orgulho de algo que fiz de primeira do que algo que eu fazia anteriormente. E sinto a melhora a cada dia.

Algumas vezes ainda não consigo isso. E melhorando a qualidade do que faço posteriormente, creio que eu esteja treinando para ser mais perfeito da próxima vez.

Interessante esta visão.

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.

Concordo em gênero, número e grau. Eu já vi uma empresa inteira que estava pouco se lixando para isso. Provavelmente vai quebrar, é só questão de tempo.

Pode não ser uma necessidade aparente. Porque a partir do momento que você reduza drasticamente o tempo de entrega de uma manutenção, vai passar a ser uma necessidade básica.

Abraços.

Concordo plenamente, Sérgio.
Eu só acrescentaria uma sugestão a todos os colegas: cuidado ao criticar publicamente um programa, pois ele pode ter sido feito por você!
Quem gosta de fazer bem feito está sempre aprendendo e evoluindo, então é natural que, hoje, faça melhor do que há algum tempo atrás.
Aliás, um bom profissional atinge um bom grau de desenvolvimento humano quando, ao abrir um programa para manutenção, resiste à tentação de ver quem é o autor. Isto é só perda de foco e de tempo.

Estou falando de forma generalizada, espero que tenha entendido desta forma. Não estou criticando A ou B. Critico muito mais o que eu faço.

Abraços.

sergiotaborda:

pinto:

Aliás, um bom profissional atinge um bom grau de desenvolvimento humano quando, ao abrir um programa para manutenção, resiste à tentação de ver quem é o autor. Isto é só perda de foco e de tempo.

É por isso que a recomendação é que não se coloque autor no código.
Quando trabalha sozinho vc já sabe que foi vc. Quando em equipe , não interessa quem fez.
Tá errado ? corrige e pronto.

Abaixo o tag @author ! ;)

Talvez… presta atenção, estou dizendo talvez, com a tag author você possa identificar na sua equipe as pessoas que estão precisando de nivelamento. Se não usar a tag negativamente, acho que tudo bem.

Agora se trabalhar a pessoa que não esteja nivelada (me incluo nessa leva também), teremos uma equipe mais forte e evitaremos problemas futuros.

Ou não?

Abraços

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.

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?

Temos aqui vários sistemas que qualquer alteração demora 1 semana para ser executada. Eu estimo que demoraria no máximo 2 dias se a arquitetura dela fosse mais… humana.

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.”

[/rant]

Eu concordo em 100% com os argumentos do Celso na discussao.

Mas o que reparei aí é o que vejo sempre nesse tipo de discussão. Aqueles que são contra a ideia da refatoracao usam argumentos baseados num ideal. No deveria ser assim, no bom programador isso, no bom programador aquilo. No “Se vc fizer certo desde o principio nao precisa refatorar.”

Como se isso nao fosse obvio. O problema eh que pra nós programadores mortais isso nem sempre eh possivel. Quem sabe seja pra eles que sao os “ases” do design que consiguem resolver tudo com um pouco de UML (sei).

Num mundo ideal em que todas as pessoas sao felizes nao precisamo de refactoring.

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.”

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.

Abraços.

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.

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.

Bruno Laturner:

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.

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?

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.

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.

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.

Abraços.

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.

Abraços.

I love people motivated … 8)

Gostei bastante das respostas Sergio, obrigado!

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)

Nem eu, onde vc leu agile?!?

cmoscoso:

sergiotaborda:

não me referi a metodologias ageis.

Nem eu, onde vc leu agile?!?

Ok. Não me referi a “metodologias incrementais”. ( ageis são incrementais. incrementais podem não ser ageis.)

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.

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.

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.

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.

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.

Abraços.

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?

Abraços.

celso.martins:

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.

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.

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.