Refatoração na pratica

Olá pessoal.

Estava eu pensando tentando implementar o mecanismo de mapeamento de herança no Angra http://www.guj.com.br/posts/list/57273.java quando me deparei com a seguinte situação.

O projeto estava muito bagunçado e a implementacao dos relacionamentos estavam feitas de forma porca, vi então que para continuar teria que refazer o projeto inteiro.

Ai pergunto a voces existe uma boa maneira de fazer isso, tentei deste modo:

  • Fiz um backup do projeto.
  • Fui alterando o que precisava
  • E sempre rodando os testes no JUnit para ver se ainda funcionava.

Só que chegava uma hora eu me perdia nas alterações e acabava desistindo.

Alguém ja passou por isso de ser obrigado a refazer um projeto?

Grato a todos.

Oi,

Acho que o maior problema de se fazer um refactoring eh vc convencer o seu gerente que ele eh necessario, e que a relacao custo x beneficio ira compensar no futuro, ou seja, se eu arrumar hoje alguem no futuro nao vai ficar se descabelando para corrigir bugs ‘impensaveis’

Convencido o gerente das alteracoes acho que o melhor eh sempre usar um Controle de Versao e ir testando as alteracoes uma a uma mesmo, se o comportamento for o esperado e os bugs corrigidos ‘commit’ neles…

:slight_smile:

Outra coisa, alem de usar um Controle de Versao (que vai te ajudar a controlar as alteracoes que fizer) seria muito bom que outras pessoas (que nao mexeram no codigo) fizessem os testes…

Quanto ao gerente. É um projeto para TCC, e o unico desenvolvedor sou eu.
É o esquema de controle de versão acabei não fazendo, ta só um projeto unico no eclipse sem cvs nem nada.

Valew.

[quote=André Fonseca]Oi,

Acho que o maior problema de se fazer um refactoring eh vc convencer o seu gerente que ele eh necessario, e que a relacao custo x beneficio ira compensar no futuro, ou seja, se eu arrumar hoje alguem no futuro nao vai ficar se descabelando para corrigir bugs ‘impensaveis’

Convencido o gerente das alteracoes acho que o melhor eh sempre usar um Controle de Versao e ir testando as alteracoes uma a uma mesmo, se o comportamento for o esperado e os bugs corrigidos ‘commit’ neles…

:slight_smile: [/quote]

To me ferrando aki na empresa, pq o codigo ta mal escrito, cheio de coisas q nem sao chamadas e o pior nao tem estrutura de pacotes, as classes tem nomes bizarros… é realmente um inferno, qdo falei q mudar ninguem aceitou… ou seja… tá um sufoco criar um ativa/desativa p/ 1 cliente pq ta mal estruturado… :frowning:

E o pior é que tende a piorar, o pessoal com pressa de implementar não arruma o que tem e fica cada vez mais dificil fazer modificações.

chega uma hora que se voce for ver o tempo que voce ta gastando para fazer uma alteração simples já ultrapassaria a refatoração.

Ou seja voce economiza umas 10h de desenvolvimento hoje e amanha gasta umas 30…

E o pior é que tende a piorar, o pessoal com pressa de implementar não arruma o que tem e fica cada vez mais dificil fazer modificações.

chega uma hora que se voce for ver o tempo que voce ta gastando para fazer uma alteração simples já ultrapassaria a refatoração.

Ou seja voce economiza umas 10h de desenvolvimento hoje e amanha gasta umas 30…[/quote]

Bem lembrado tenho 3 semanas p/ fazer uma pá de coisa… :cry:

Eu já passei por isso.

Não tente corrigir tudo de uma só vez. Vá fazendo aos poucos. É essa a principal vantagem do refactoring. Trabalhe sobre o trecho que você está atuando que, ao longo do tempo, o código ficará muito bom. Cada arrumação que você fizer, depois de um tempo, vai te dar visão para onde arrumar mais. É um método bastante kaizen, mas efetivo.

Refazer o código todo só em caso de extrema urgência. Mas daí nesse caso, nem sempre é bom partir do código antigo. Crie um projeto novo, re-analise e, no máximo, estude o funcionamento de um ou outro método que você considera bem implementado.