Refactoring x Rework

Estava comentando sobre práticas ágeis com um amigo e disse que gostava muito de coisas como Design Evolutivo, KISS (keep it simple stupid), essa coisa de acolher as mudanças (embrace changes), e falei na palavra chave Refactoring. Pra que eu fui falar isso? 😛 Na mesma hora eu ouvi: “Refactoring ou Rework? para mim é  mesma coisa!“.

Desde aquele dia tive vontade de escrever um post falando sobre isso, e tentando explicitar as diferenças ( porque na minha cabeça é completamente diferente ). Apesar de soarem como coisas similares para algumas pessoas, e algumas outras pessoas até confundirem dizendo que estão fazendo refactoring quando estão fazendo rework e vice-versa, existem diferenças entre essas atividades.

Vamos começar com a definição do que é refactoring:

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.

Como a própria definição já fala, a idéia do refactoring é modificar a estrutura interna (design) do código de forma a melhorá-la ou ajustá-la para algum comportamento que não tinha sido previsto anteriormente (embrace changes). O Refactoring se encaixa perfeitamente no mundo das práticas ágeis justamente porque a idéia do desenvolvimento ágil é se preocupar com o AGORA, então o design da aplicação vai ser feito pensando nas coisas que se conhecem hoje, e que são precisas hoje, e esse mesmo design evolui a medida que o conhecimento vai aumentando, ou que

as mudanças forem chegando . Esse é o famoso design evolutivo, que anda de mãos dados com o refactoring, pois o refactoring dá subsídio a evolução do design.

Só para ficar mais claro do que é design evolutivo e refactoring eu queria falar de como seria o oposto disso tudo. O oposto disso seria nós começarmos um projeto com uma tela

de login, e um usuário que loga e mostra a tela principal e no momento de fazer o design das classes eu já criar (isso mesmo, cedo assim)  diversos componentes do sistema, criar interfaces para meio mundo de coisa, criar classes abstratas que vão representar objetos que só vão ser criados daqui a 6 meses, ou 1 ano. Como você pode notar eu já teria uma “arquitetura” pronta desde o início do projeto, e isso pode acarretar algumas coisas como: 1) Aceitar mudanças vai ser tornar um problema maior do que o normal, pois você já preparou seu sistema para um determinado comportamento (mesmo sem te

r muito conhecimento, pois normalmente no inicio do projeto se tem pouco conhecimento a respeito do negócio/domínio); 2) Provavelmente algo do que você fez NUNCA será usado, e talvez ainda esse algo (NUNCA usado) seja causa de bug e de dificuldades no design da aplicação (mas novamente, mudar já se torna bem mais dificil pois já tem muita coisa pronta).

Bom, acredito que já está mais claro o que é refactoring e como ele está diretamente relacionado com agilidade e com desenvolvimento iterativo/incremental. Acredito que não preciso nem falar muito sobre Rework, mas como é o título desse post então vamos lá. Começando com a definição:

Rework is to rewrite or revise; To work over again.

A própria definição já diz muita coisa, é reescrever algo, refazer, fazer de novo. Aí você pode perguntar: mas no refactor você também não refaz? E eu respondo, isso mesmo, só que o propósito de refazer do refactoring é diferente, é melhorar e ajustar e não corrigir algo que foi feito errado. E é justamente aí onde entra o rework, se eu fiz alguma coisa errada, vou ter que fazer um rework para corrigir. Se criei algo de forma errada tenho que refazer (rework). Então vamos lá… Toda correção de Bug é um rework. Toda correção de um requisito é um rework. Isso tudo porque você está gastando tempo de novo com algo que teoricamente já devia estar bom. Se no seu refactoring você introduzir bugs, vc terá que fazer um rework do refactoring para corrigir esses bugs ( e isso sim é perder tempo/dinheiro). Vamos continuar…. Toda mudança de requisitos ou requisito novo que for impactar o design do sistema é rework ou refactoring? Refactoring, pois o requisito estava OK até a mudança ou até a chegada do requisito novo.

É isso aí, espero que tenha ficado mais explícita a diferença entre essas duas palavras tão parecidas.

Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s