slides_aula_refatoracao

Prévia do material em texto

3/30/2023
1
OPUS GroupLES | DI |PUC-Rio - Brazil
Uma Introdução à Refactoração de Software
Alessandro Garcia
Cronograma – Atividades do Projeto Supervisionado
 Aulas de Introdução a Disciplina e Projeto Supervisionado - ok
 Aulas sobre Projetos Candidatos e Critérios - ok
 Aula tempo para encontro e planejamento das equipes - ok
 Aula de Introdução a Refatoração de Software (hoje)
 Aula sobre Controle de Versões e Git – 4/4
 Defesa do Projeto Escolhido 
 11/4: grupos 1 e 5
 13/4: grupos 3 e 4
 18/4: grupos 2 e 6
 Aula sobre Contribuições no Github (parte 1) – 20/4
March 23 Alessandro Garcia @ OPUS Group 1
3/30/2023
2
Cronograma – Atividades do Projeto Supervisionado
 Aula sobre análise estática – 25/4
 Preparação para análise das refatorações e escolha das refatorações
abertas – 27/4 (reunião interna dos grupos)
 Apresentações sobre Refatorações (atividades 2 e 3) 
 4/5: grupos 1 e 2
 9/5: grupos 3 e 4
 11/5: grupos 5 e 6
 16/5 – reunião interna dos grupos (trabalho na implementação das refatorações)
 18/5 – aula de acompanhamento (resumo dos progressos)
March 23 Alessandro Garcia @ OPUS Group 2
Ordem dos grupos – 1o DIA de apresentações – 11/4
 GRUPO 1 - Matplolib
EDUARDO DANTAS LUNA
GABRIEL DE OLIVEIRA ROSA M MADEIRA
LUCA VASCONCELLOS RIBEIRO
THIAGO LUIS BECKER DA ROCHA
 GRUPO 2 - Jarvis
JHONATAN CAETANO ARRUDA
JOAO ROIZEN FONTANA
LUCAS DO COUTO BARRA TORRES
MATHEUS SAMPAIO MOREIRA
3
3/30/2023
3
Ordem dos grupos – 2o DIA de apresentações – 13/4
 GRUPO 3
ALEXANDRE RODRIGUES BOMFIM JUNIOR
ARTHUR XAVIER TAVARES
CAIO COUTINHO PALMIERI
JOAO PEDRO MONTEIRO MAIA
 GRUPO 4 - Zulip
LUCAS CAPUTO BELLO
MARINA SCHULER MARTINS
SERGIO BERNARDELLI NETTO
WLADIMIR CALAZAM DE ARAUJO G RAMOS
Alessandro Garcia @ OPUS Group 4
Ordem dos grupos – 3o DIA de apresentações – 18/4
 GRUPO 5 - Mockito
BERNARDO BULGARELLI TEIXEIRA
RAFAEL RIBEIRO DE CARVALHO
THOMAZ PASSARELLI ESPIRITO SANTO
 GRUPO 6 
JOÃO PEDRO GUIMARÃES SOARES
LEONARDO ABREU SANTOS
SERGIO GABRIEL VIEIRA BOUCO
5
3/30/2023
4
Apresentação do grupo nos dias 11, 13 e 18
• Escolha do projeto: informe número do grupo e o projeto no Whatsapp
• Tempo de apresentação: 25 a 30 mins no máximo
• seguido por perguntas e respostas do outro grupo e pelos professores (10 a 15 
mins)
• Todos os membros da equipe devem falar ao longo da apresentação
• Objetivos: 
• apresentar as informações básicas e justificativas do projeto escolhido, bem
como seleção inicial de módulos candidatos
• defender e convencer a outra equipe e os professores que o grupo tem
domínio inicial sobre o projeto escolhido, bem como estão motivados em
estudarem e trabalharem neste projeto
• IMPORTANTE: devem começar a trabalhar em paralelo nas atividades 2 
e 3 o quanto antes 
6
Itens para serem incluídos na Apresentação
• Dados gerais sobre o projeto que achar ser pertinente
• incluir informações apresentadas nas 2 aulas sobre descrições dos projetos
• Incluir alguma informação sobre a arquitetura de módulos do 
projeto: idealmente, visual
• explicar sucintamente a arquitetura (ex. REST? Em camadas?) e o papel dos 
módulos principais
• Incluir outras informações importantes disponíveis
• exemplo: quais são os atributos de qualidade importantes neste projeto? 
(readme, discussões dos desenvolvedores, descrições das issues e commits)
7
3/30/2023
5
Itens para serem incluídos na Apresentação
• Apresente em mais detalhes o propósito de um ou mais
módulos
• candidatos do foco do projeto supervisionado
• apresente justificativas da escolha destes módulos candidatos
• use os mesmos critérios usados para escolha dos projetos
• use outros critérios que o grupo julgar pertinente
• quantos desenvolvedores envolvidos recentemente*?
• quantos commits afetando este módulo realizado nos últimos meses*?
8
Itens para serem incluídos na Apresentação
• Tentem instalar o projeto
• Nomes do líder e vice-líder da equipe
• haverá uma rotação? (ex. bimestral)
9
3/30/2023
6
OPUS GroupLES | DI |PUC-Rio - Brazil
Uma Introdução à Refactoração de Software
Alessandro Garcia
Software maintenance and evolution
 software changes everyday
 new features are progressively introduced in existing classes and methods
 modifications to incorporate…
 new frameworks and libraries
 additions or removal of modules
 structural decay of methods, classes or components (e.g., packages)
March 23 Alessandro Garcia @ OPUS Group 11
3/30/2023
7
Symptoms of poor design choices…
… start to accumulate…
… and… 
 hamper the introduction of new features
 disable the possibility of changing frameworks 
or libraries
 hinder “modernization” of software systems 
with new technologies, e.g., (micro)services
March 23 Alessandro Garcia @ OPUS Group 12
250 billions of lines of 
legacy code
March 30, 2023 afgarcia@inf.puc-rio.br 13
[Seacord et al, Modernizing Legacy Systems, 2003]
If code is not progressively and properly refactored...
3/30/2023
8
Why design degradation is important?
39% (out of technical debt 
rejections) were related to design problems
Productivity Reduction
206 out of 1722 changes rejected require refactoring
M. Campos et al. Does Technical Debt Lead to the Rejection of Pull Requests?. SBSI, 2016. 
Refactoring is (should be) part of the routine…
March 23 Alessandro Garcia @ OPUS Group 15
Refactoring is the process of improving the 
structure a software system without 
changing the external behavior
It is a disciplined way to clean up code that 
minimizes the chances of introducing bugs
"Improving the design after it has been 
written"
3/30/2023
9
Refactoring: a set of code transformations
 Rename
 Extract Method
 Inline Method
 Move Method
 Pull up a Method or a Field
 Push down a method or a field
 Extract Interface
 Remove dead code
…
March 23 Alessandro Garcia @ OPUS Group 16
Open source projects: refactoring frequency
 Is structural quality a common concern?
17
23 projects
(different domains)
15 projects > 40 KLOC each
29,318 refactorings
 1,270 per system
various detectors of code smellstwo refactoring 
detectors
3/30/2023
10
Improving structural quality…
… is a frequent target of refactorings
18
Extract method 7,517
Move field 4,356
Inline method 1,528
Move method 1,404
Pull up method 629
Pull up field 465
Extract superclass 342
Extract interface 133
Push down method 114
Push down field 78
Categorias de refatoração
 é intencional ou não intencional
 é pura ou entrelaçada com outras mudanças (no 
mesmo 
 é simples ou composta (quantas transformações?)
 é manual ou apoiada ou pela IDE
March 23 Alessandro Garcia @ OPUS Group 19
3/30/2023
11
Smells as Hints
 “A code smell or anomaly is a 
surface indication of a deeper 
design problem, observed in a 
program's low-level structure” 
[Fowler 1999]
 Anomalous micro-strututures: 
classes, methods, attributes, etc..
 Catalog of 22 code smell types
Examples of code anomaly types
 Good Classes
 Long Methods
 Feature Envies
 Duplicated Code
 Speculative Generality
 Lazy Class
 Refused Bequest
 Shotgun Surgery
 Divergent Change
March 23 Alessandro Garcia @ OPUS Group 21
3/30/2023
12
Smelly (anomalous) code …
… is a frequent target of refactorings
22
Extract method 7,517 85.28%
Move field 4,356 77.18%
Inline method 1,528 74.21%
Move method 1,404 74.71%
Pull up method 629 81.24%
Pull up field 465 71.61% 
Extract superclass 342 38.30%
Extract interface 133 48.87%
Push down method 114 85.96%
Push down field 78 74.35%
Static Analyzer
… to detect opportunities for refactoring
Alessandro Garcia @ OPUS Group 23