Percepção Individual sobre Refatoração de Código Fonte

coletados de 20 programadores. Um programador indicou explicitamente que não tinha como responder sobre refatoração de código, uma vez que desconhecia o termo e a área.

A primeira questão sobre refatoração requeria justamente que o programador definisse o termo refatoração. Queríamos saber se todos entendiam uniformemente o conceito refatoração e se a prática que estava ocorrendo na organização era de fato refatoração de código. As respostas para essa questão, que era livre, foram codificadas e tiveram seus códigos separados em três grupos diferentes, um para cada dimensão das respostas obtidas. As dimensões são: i) “refatoração é...”; ii) “refatoração não pode...”; e iii) “refatoração auxilia no(a)...”. A Figura 2.4 a seguir apresenta os códigos do grupo “refatoração é...”.

Figura 2.4 – Códigos para o grupo de respostas “refatoração é...”

As respostas de definição de refatoração de código contemplaram não somente a definição em si, mas também algumas informações adicionais que vimos

2 5 3 1 9 8 2 0 1 2 3 4 5 6 7 8 9 10

Refatoração é...

31

como interessante de serem capturadas e analisadas e que estão relacionadas com restrições para as atividades de refatoração e com os prováveis impactos que a refatoração pode ocasionar no código fonte. Para a definição em si, fato importante de ser observado é a quantidade de respostas definindo refatoração como sendo reconstrução de código fonte, ou seja, retrabalho puro. Outras definições de destaque são as que relacionam refatoração de código com correção de defeitos e ainda atualização de código para inserção de requisitos. Essas respostas foram os primeiros indícios que identificamos de que os programadores não estavam falando da mesma prática e de que o que provavelmente estava ocorrendo na organização não era refatoração e sim reconstrução de código fonte. Vale destacar que de uma mesma resposta surgiram mais de um código, por isso a soma total dos códigos não é exatamente o número de respostas (20).

Figura 2.5 – Códigos para o grupo de respostas “refatoração não pode...”

Alguns programadores mencionaram ainda que a refatoração não pode acarretar em alterações de funcionalidades do código ou ainda inserir defeitos (ver Figura 2.5). Restrições que vão ao encontro da definição de refatoração apresentada em (FOWLER et al., 1999) que preconiza a não alteração do comportamento externo, porém que estão distantes do que profissionais da prática de outras organizações de desenvolvimento de software relatam (KIM, ZIMMERMANN e NAGAPPAN, 2012).

5 2 0 2 4 6 Alterar funcionalidades do código

Inserir defeitos no código

32 Figura 2.6 – Códigos para o grupo de respostas “refatoração auxilia no(a)...”

Outro conjunto de respostas dos programadores a respeito da refatoração foi relacionado com os benefícios que ela poderia trazer para o código fonte. Para os programadores, a refatoração de código impacta diretamente características de qualidade como legibilidade, desempenho, extensibilidade e manutenibilidade (ver Figura 2.6). Fato interessante nessas respostas é a quantidade expressiva de programadores que indicaram legibilidade como sendo uma característica impactada pela refatoração de código, pode ser mais um indício de que eles veem a refatoração como sendo uma atividade de melhoria pontual no código fonte.

Através dos dados obtidos com o survey, conseguimos perceber que embora existisse de fato refatoração de código na organização, a atividade mais frequente era a de reconstrução de código fonte. Além disso, percebemos que havia uma dissonância entre as percepções sobre refatoração de código na organização e muitos programadores entendiam ainda que refatorar o código era simplesmente modificar o código, seja para corrigir problemas ou inserir funcionalidades. Pudemos confirmar esses resultados encontrados através da análise de outras respostas ao formulário de refatoração, como as respostas obtidas com a questão sobre a frequência com que os programadores refatoravam o código dos projetos que participavam. A maioria dos programadores disse que raramente eles realizavam tarefas de refatoração – como possível de ser visualizado na Figura 2.7 –, porém houve aqueles que responderam diariamente, semanalmente e mensalmente, frequências impensáveis para atividades que, de certa forma, trazem riscos e custos aos projetos.

3 2 1 5 2 2 1 0 1 2 3 4 5 6

33 Figura 2.7 – Frequência de realização de atividades de refatoração de código fonte

Outro conjunto de respostas que trouxe ainda mais respaldo às conclusões alcançadas até então foi o de 10 respondentes que indicaram que já tinham interrompido atividades de refatoração de código iniciadas. Dentre os motivos para a refatoração, alguns programadores indicaram que queriam atualizar funcionalidades e bibliotecas de desenvolvimento. Foco para um respondente que indicou ter realizado a refatoração para melhorar a compreensibilidade do código fonte, melhoria que entendemos poder ser pontual.

Figura 2.8 – Códigos extraídos das respostas sobre experiências com atividades de refatoração que foram interrompidas

Dentre as situações que mais influenciavam os programadores a realizarem tarefas de “refatoração” de código estavam as relacionadas com mudanças pontuais

1 3 3 1 11 1 0 2 4 6 8 10 12

Refatoro o código...

34

no código fonte, como a existência de variáveis, constantes, métodos, funções, procedimentos e/ou parâmetros desnecessários, além de problemas na legibilidade de seus identificadores. Quando analisamos essa listagem (ver Tabela 2.7) em conjunto com os problemas que mais ocorrem na organização, vemos que os problemas mais recorrentes não são necessariamente os mais tratados, possivelmente porque a prioridade dos problemas recorrentes é menor do que a dos problemas mais tratados; ou ainda porque os problemas mais tratados são vistos como mais rápidos e fáceis de serem resolvidos e causam menos efeitos colaterais ao código fonte.

Tabela 2.7 – Situações que mais influenciam a refatoração de código na empresa Alfa

% (valor agregado/máximo

valor possível)

Situação que influencia a refatoração na empresa

Influencia na Refatoração...

68,42 Redundância de código.

SEMPRE

66,67 Variáveis, constantes, métodos, funções e/ou

procedimentos desnecessários.

64,91

Legibilidade deficiente, ou seja, variáveis, constantes, métodos, funções e/ou

procedimentos com nomes não intuitivos ou localizados em lugares inapropriados.

63,16 Métodos, funções e/ou procedimentos com

muitos parâmetros desnecessários.

59,65 Baixo desempenho da aplicação.

EVENTUALMENTE

57,89 Código de difícil manutenção.

49,12 Código de difícil extensão de funcionalidades.

45,61 Código de difícil reutilização.

RARAMENTE

45,61 Métodos, funções e/ou procedimentos com

muitas responsabilidades.

42,11 Dificuldade de testar o código sem antes aplicar

refatoração.

40,35 Código muito fragmentado.

31,58 Falso Positivo (Código com alta complexidade.)

22,81 Falso Positivo (Código muito extenso.)

NÃO INFLUENCIA

19,30 Existência de código legado com o qual é

necessário trabalhar.

-5,26 Falta de modelos de projeto/arquitetura que

permitam entender o software.

-19,30 Forte dependência com código de outros times

de desenvolvimento.

-64,91 Falso Positivo (Alto tempo de compilação do

35