Refatoração e prazos: como conciliar?

Olá, pessoal! Hoje vou falar um pouco da importância da refatoração (refactoring) de código. Para alguns, um assunto tão...

Dextra

View posts by Dextra
Somos especialistas em desenvolvimento de software sob medida para negócios digitais. Pioneiros na adoção de metodologias de gestão ágil, combinamos processos de design, UX, novas tecnologias e visão de negócio, desenvolvendo soluções que criam oportunidades para nossos clientes. A Dextra faz parte da Mutant, empresa B2B líder no mercado brasileiro e especialista em Customer Experience para plataformas digitais.
Data de publicação: 22/05/2014
Sabe quais ações são suficientes para o código continuar limpo e evitar grandes refatorações, que impactem no ciclo de vida do sistema? Confira o post!

Olá, pessoal!
Hoje vou falar um pouco da importância da refatoração (refactoring) de código. Para alguns, um assunto tão natural que não mereceria nem uma discussão longa do seu valor. Mas, infelizmente, ainda temos pessoas que não compreendem totalmente esta técnica de melhoria de código. Porém, hoje não falaremos deste assunto na linha técnica, mas na comportamental.
Uma definição de refatoração que gosto é a do Wikipédia:

Refatoração (do inglês Refactoring) é o processo de modificar um sistema de software para melhorar a estrutura interna do código sem alterar seu comportamento externo.

O mais comum é ouvirmos que refatoração é retrabalho: “Como assim você vai reescrever um código que já está funcionando?”. Acredito que este seja o questionamento mais comum.
Para quem não tem experiência como desenvolvedor de software, é algo um pouco complicado de explicar. Por não entenderem programação, elas não conseguem conceber como o código de uma aplicação pode evoluir, mesmo com tudo funcionando, rumo ao caos. Também não conseguem conceber que a estrutura interna do código precisa, por vezes, ser alterada para contemplar novos requisitos nunca antes previstos, com novas interações nos bastidores que ela não tem consciência.
E não é culpa delas. Assim como entendemos de software melhor do que elas, elas entendem melhor do que nós de outras coisas. Como profissionais, precisamos explicar com clareza os nossos motivos, os riscos envolvidos de continuar como está e sermos ouvidos.
Mas temos responsabilidades como desenvolvedores. Temos que entender quando uma refatoração é necessária, levando em conta o contexto que o sistema está inserido. Mas, antes disto, entender que existem diferentes níveis de refatoração.
A mais simples são as que fazemos o tempo todo. Refatorar pequenos trechos de código é algo que o desenvolvedor está constantemente fazendo: evitar uma duplicação, separar métodos em novas classes, melhoria em nomes de métodos/variáveis/etc…
Só estas ações já são suficientes para o código continuar limpo e evitar grandes refatorações, que impactem no ciclo de vida do sistema. Mas algumas situações ou percepções escapam da visão do gerente, do Product Owner, do cliente e do desenvolvedor. Assim, a aplicação acaba evoluindo para um caminho que, cedo ou tarde, a refatoração será percebida como necessária. Novamente, citando o Wikipédia:

O uso desta técnica aprimora a concepção (design) de um software e evita a deterioração tão comum durante o ciclo de vida de um código. Esta deterioração é geralmente causada por mudanças com objetivos de curto prazo ou por alterações realizadas sem a clara compreensão da concepção do sistema.

Conseguimos enxergar 2 cenários comuns no parágrafo acima: objetivos de curto prazo e alterações realizadas sem a clara compreensão da concepção do sistema. São cenários tristes, pois: são comuns, geram uma montanha de débitos técnicos e o desenvolvedor tem pouco poder de evitá-los. Mas o estrago no código da aplicação realizado por eles são reversíveis.
Dependendo do tamanho do buraco deixado, ele pode ser resolvido sem impactar no planejamento das atividades. Mas, se a extensão do primeiro cenário for muito longa ou a imprevisibilidade do segundo mostra-se muito alta, será preciso ter a “conversa”.
Uma vez que o assunto da refatoração chega a nível gerencial e/ou no cliente, é porque esta refatoração vai afetar o cotidiano do projeto. Ou seja, podemos entender que neste caso o código está realmente ruim e alguma ação precisa ser tomada e comunicada. Como citei anteriormente, é preciso explicar com clareza o problema existente.
Não posso dizer por você como isto deve ser dito. Esta comunicação precisa ser feita de uma maneira eficaz e, para isto, é necessário ser claro ao passar suas motivações. Em geral, posso recomendar a utilização de exemplos da própria aplicação, com um histórico de como as coisas aconteceram, decisões adotadas e os problemas gerados a partir delas.
De uma forma geral, indicaria um discurso nesta linha: “Havia apenas o conceito de Pessoa no sistema. Com os novos prazos agressivos, surgiu a Pessoa Física e não tivemos tempo de separar os atributos e serviços comuns entre elas e duplicamos código. Conseguimos melhorar um pouco, mas de repente surgiu a ideia de Pessoa Jurídica e Estrangeiro no sistema e encaixamos da melhor maneira possível no prazo. Para boa evolução do sistema, precisamos ter serviços diferentes para cada tipo de pessoa, pois todas elas estão compartilhando código que não deveriam, e como consequências as alterações e bugs afetam todas elas”.
Por fim, se você sentiu falta de algo mais técnico no texto, deixo a indicação de um livro excelente sobre refatoração, o Refactoring: Improving the Design of Existing Code. Livro para leitura e consulta de todo bom desenvolvedor de software.

Dextra

View posts by Dextra
Somos especialistas em desenvolvimento de software sob medida para negócios digitais. Pioneiros na adoção de metodologias de gestão ágil, combinamos processos de design, UX, novas tecnologias e visão de negócio, desenvolvendo soluções que criam oportunidades para nossos clientes. A Dextra faz parte da Mutant, empresa B2B líder no mercado brasileiro e especialista em Customer Experience para plataformas digitais.

Comentários

  1. João23 de Maio de 2014

    O problema é quando a refatoração é apenas Perfeccionismo e causa atraso no projeto. tem desenvolvedor que não entende isso também.

    Responder
    1. Dherik Barison23 de Maio de 2014

      Olá, João!
      Obrigado pelo comentário.
      Bem observado. O desenvolvedor também precisa ter o bom senso de quando a refatoração é necessária e quando ela deve “terminar”. Acredito que só este assunto já daria um novo texto :).

      Responder

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

6 − 1 =

Posts relacionados

  1. Sobre a Dextra

    Somos especialistas em desenvolvimento de software sob medida para negócios digitais. Pioneiros na adoção de metodologias de gestão ágil, combinamos processos de design, UX, novas tecnologias e visão de negócio, desenvolvendo soluções que criam oportunidades para nossos clientes.

  2. Categorias

Scroll to top