UM PROCESSO PARA APLICAÇÃO DE TÉCNICAS
DE REFACTORING NO DESENVOLVIMENTO DE
SISTEMAS ORIENTADOS A OBJETOS
Palestrante: Isaac Babsky Neto
ATAN Ciência da Informação
Orientador: Renato Cardoso Mesquita
Departamento de Engenharia Elétrica – UFMG
Co-orientadora: Ana Liddy Cenni de Castro Magalhães
XXXX-XX(Rev.:XX)
1
Kent Beck

Que tipos de programas são caros para modificar?

Programas que são difíceis de ler

Programas que possuem lógica duplicada

Programas que estão rodando e que precisam de novas
funcionalidades (principalmente se desenvolvidos por terceiro)

Programas com lógica condicional complexa
XXXX-XX(Rev.:XX)
2
O que é Refactoring ?
Oficina Mecânica
de Motos
do João.
Sou mecânico,
conserto motos
e tenho preço justo
XXXX-XX(Rev.:XX)
Oficina do João

Refactoring pode ser visto como uma mudança feita na estrutura
interna de um software (design) para torná-lo mais fácil e barato
de modificar e mais simples de entender, sem alterar seu
comportamento externo ou observável

Refactoring não é retrabalho
3
Por que usar Refactoring ?

Solução para o “eterno problema da pia”
 Manutenção preventiva e melhoria contínua
 “Não esperar quebrar para consertar”
Refactoring
XXXX-XX(Rev.:XX)
4
Quais os benefícios do Refactoring ?

Refactoring aprimora o design do código


Refactoring torna o código mais fácil de se entender e modificar


Quanto mais claro o código, mais fácil é o entendimento do design
Refactoring ajuda a encontrar bugs


Quanto mais código existir, mais difícil é a tarefa de modificá-lo
Quanto mais se entende o código, mais fácil é mantê-lo
Refactoring ajuda a programar mais rápido

Quanto pior o design, mais lentos são os processos para atualizar e estender o sistema
XXXX-XX(Rev.:XX)
5
Objetivo do Trabalho


Alcançar um modelo de melhoria contínua de aspectos relacionados à
qualidade interna dos softwares, tais como:
 Manutenibilidade
 Operacionalidade
 Extensibilidade
Elaborar um processo para aplicação contínua e gradativa de técnicas de
refactoring no desenvolvimento de sistemas orientados a objetos
 Simples de aplicar e coordenar
 Evolucionário
 Eficiente
XXXX-XX(Rev.:XX)
6
Justificativas do Trabalho

De maneira geral, existe um grande esforço para garantir a qualidade
externa dos produtos de software e pouco para garantir a qualidade interna


Existem muitos métodos e poucos processos que visam a um aumento da
qualidade do produto em si, ou seja, do design do sistema


O cliente pagou não só por um serviço de qualidade, mas também por um
produto de qualidade
Revisão de código, testes unitários, Design Patterns, Técnicas de Refactoring
Utilizar um processo de melhoria contínua do design que seja simples,
focado, fácil de aplicar e fácil de coordenar é um primeiro passo na
tentativa de aprimorar a qualidade interna dos produtos de software
XXXX-XX(Rev.:XX)
7
Processo Proposto
Organizar
Limpar
Aprimorar
Organize :
I.
um código organizado é essencial para ser bem entendido

Limpe :
II.
estando organizado, é possível retirar o que é desnecessário

Aprimore :
III.

XXXX-XX(Rev.:XX)
agora que o código está organizado e limpo, o próximo
passo é aprimorá-lo (agregar valor ao código)
8
Processo Proposto: Organizar
Organizar
Limpar
Aprimorar

Para que serve?
 Esta etapa tem como objetivo melhorar a organização interna das classes
 layout estrutural
 padronização do código

O que se ganha?
 Um código bem organizado é essencial para se garantir a manutenibilidade do sistema
 A localização e o entendimento dos componentes de uma classe se dará de forma mais
rápida e eficiente
 Primeiro contato do desenvolvedor com códigos que não foram desenvolvidos por ele
(percepção de coletividade do código)
Como é realizada?
 Essa etapa é a mais simples de todas (sendo também um bom início para se aplicar o
uso de testes unitários, já que as alterações não são complexas)
 Utilizando técnicas simples de refactoring, tais como:
– Move Field / Method
– Pull Up Field / Method / Constructor Body
– Push Down Field / Method
XXXX-XX(Rev.:XX)

9
Processo Proposto: Limpar
Organizar
Limpar
Aprimorar

Para que serve?
 Retirar membros, métodos, código e classes desnecessários ou mesmo hierarquias mal
formuladas
 Verificar o tamanho dos métodos (podendo quebrá-los em outros métodos) e das classes
(que podem originar outras classes)

O que se ganha?
 Ao realizar a limpeza do código, espera-se que seja deixado somente o que é utilizado
dentro do sistema, o que facilitará o seu aprimoramento em uma próxima etapa

Como é realizada?
 Essa etapa é mais complexa que a anterior e deverá demandar a implementação de
testes e a utilização de técnicas de refactoring mais elaboradas que as utilizadas
anteriormente, tais como:
– Extract Class
– Chain Constructors
– Form Template Method
XXXX-XX(Rev.:XX)
10
Processo Proposto: Aprimorar
Organizar
Limpar
Aprimorar

Para que serve?
 Agregar mais valor ao design, pois estando o código organizado e limpo, é possível
aprimorá-lo
 Grande parte das arestas ou “bad smells” já foram retiradas
 O aprimoramento exige certa maturidade por parte dos desenvolvedores, que pode
ter sido alcançada após realizar as etapas anteriores

O que se ganha?
 Elevará ainda mais a qualidade do código existente, valorizando o produto final e
aumentando a manutenibilidade e a operacionalidade do código

Como é realizada?
 Esta etapa deverá ser realizada com muita responsabilidade (ex: uso de testes) e
maturidade (ex: saber o que é prioritário)
 Esta é a etapa mais complexa, porque o desenvolvedor deverá conhecer bem tanto o
sistema (código e requisitos) quanto técnicas de refactoring mais refinadas, tais como:
– Substitute Algorithm
– Replace Type Code With Class
– Extract Composite
XXXX-XX(Rev.:XX)
11
Evolução do Projeto

Principais Dificuldades Enfrentadas
 As primeiras IDEs utilizadas não suportavam de forma integrada a
utilização de ferramentas de testes e medições
 A utilização do Eclipse resolveu este problema, pois possui
ferramentas nativas de testes e diversos plug-ins para medição
(analisadores estáticos de código), como o PMD e o CheckStyle
 Pouca ou nenhuma experiência dos desenvolvedores na área de
Refactoring
 Elaboração de treinamentos e reuniões constantes com as
equipes dos projetos
 Inicialmente, cada projeto utilizava um modelo de planejamento para
a aplicação do processo
 Definiu-se que, diariamente, todos os desenvolvedores da equipe
reservariam 20 min para a aplicação do processo em partes prédefinidas do projeto
XXXX-XX(Rev.:XX)
12
Resultados Obtidos


Ganhos pessoais do desenvolvedor:

Melhor entendimento do sistema
 Aumento da confiança e da produtividade

Maior comprometimento quanto à qualidade
 Maior conscientização em relação à melhoria contínua

Melhor interação entre membros das equipes
 Aumento da comunicação
Ganhos técnicos para a equipe de desenvolvimento:

Produtos mais organizados e padronizados
 Códigos mais enxutos, mais simples e mais claros

Diminuição do tempo de manutenção
 Ganho de tempo para a melhoria do sistema
XXXX-XX(Rev.:XX)
13
Resultados Esperados

Aplicação bem sucedida de ferramentas livres (open source) para
auxiliar na aplicação do processo (analisadores estáticos de código,
ferramentas de testes automatizados,...)

Adaptação do processo para equipes responsáveis pelo
desenvolvimento dos frameworks da Atan (Estudo de Caso)

Definição de um processo consistente que possa ser aplicado a uma
equipe qualquer de desenvolvimento de sistemas orientados a objetos

Aumento da qualidade dos sistemas e da produtividade das equipes
de desenvolvimento
XXXX-XX(Rev.:XX)
14
Resultados Esperados

Um processo consolidado para viabilizar a aplicação de técnicas de
refactoring no desenvolvimento de sistemas orientados a objetos,
utilizando também testes e métricas de qualidade

Dissertação de Mestrado, dentro do Programa de Pós-Graduação em
Engenharia Elétrica da UFMG a ser finalizado em novembro deste ano
XXXX-XX(Rev.:XX)
15
Dúvidas ou sugestões ?
Obrigado!
[email protected]
(31) 3289 7733
XXXX-XX(Rev.:XX)
16