Upload
ana-paula-g-soares
View
43
Download
12
Embed Size (px)
Citation preview
Rômulo A. C. PelachiniAnálise e Métricas de Codificação
U N J
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Motivação• Por que falar sobre métricas?
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Motivação
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Motivação
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Motivação
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Motivação
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
De greenfield para brownfield• Projetos não viram legado da noite para o dia.• De débito técnico em débito técnico.• De commit em commit.• De feature não documentada em feature não documentada.• De requisito mal especificado em requisito mal especificado.• De IF em IF.
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
De greenfield para brownfield
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
De greenfield para brownfield
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
De greenfield para brownfield
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
De greenfield para brownfield
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Como parar a sangria?
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Como parar a sangria?
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
KALOI• Keep A Lid On It (coloque uma tampa na panela).• Evite novos débitos técnicos.• Sempre que possível diminua a pressão.
• Structure101.com• scrcheck https://github.com/sglebs/srccheck
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Débito técnicoA estimativa é de que o custo mundial com débito técnico gire em torno de U$ 500 Bi / ano. (~U$ 3,61 por linha de código)
• Qual a estimativa do custo para o Brasil?• E na sua empresa?• E no seu projeto?
• https://blog.sonarsource.com/evaluate-your-technical-debt-with-sonar/
• https://blog.sonarsource.com/sqale-the-ultimate-quality-model-to-assess-technical-debt/
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Débito técnico• Como minimizar a ocorrência de débitos técnicos?
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Métricas
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Métricas• Mensure e acompanhe regularmente.• Como as métricas podem ajudar a minimizar a ocorrência de débitos
técnicos?
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Como as métricas podem ajudar?• Os principais objetivos das métricas de software são
identificação e medição dos principais parâmetros que afetam o desenvolvimento de software (Mills, 1988).
• Através das métricas podemos rapidamente identificar se um código está em conformidade com as melhores práticas de programação (OO, SOLID, Design Patterns, Clean Code) e consequentemente podemos inferir o quanto este código pode ser compreendido, estendido, modificado, mantido, etc.
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Antes, alguns cuidados?• Não podemos simplesmente olhar para os números.
Por exemplo, métricas como “LinesOfCode”, “Number of functions”, “Worked hours”, “Number of bugs”, “Function Points”, “Burdown”, “Velocidade”• Então quer dizer que quanto mais linhas de código escrevo melhor é
meu software? Ou quanto menos código melhor?• Quanto mais rápido faço melhor será meu software?• Se eu só separar em várias funções na mesma classe melhor será
minha classe?• O objetivo é não apresentar erro para o usuário (então vou matar
todas as exceções)?
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Antes, alguns cuidados?
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Antes, alguns cuidados?
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Aplicando na Softplan (UNJ)• Piloto com duas equipes (Alemanha e Japão).• Build em pipeline.• Métricas por equipe (Understand e srccheck).• Tampa da panela por equipe (KALOI).• SONAR por equipe.• Resultado Build – Alemanha• Resultado Build - Japão
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Aplicando – Build em pipeline
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Aplicando – Métricas por equipe
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Aplicando – Métricas por equipe
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Aplicando – Métricas por equipe
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Aplicando – Métricas por equipe
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Aplicando – Métricas por equipe
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Aplicando – Métricas por equipe
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Aplicando – Métricas por equipe
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Aplicando – Métricas por equipe
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Aplicando – Métricas por equipe
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
• Count Line Code x Count Class Coupled x Percent Lack Of Cohesion
• Count Line Code Max Cyclomatic Modified MaxNesting
Aplicando – Métricas por equipe
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Aplicando – Métricas por equipe
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Aplicando – Métricas por equipe
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Aplicando – Métricas por equipe
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Aplicando - SONAR
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Sonar
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Sonar
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Sonar
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Structure101
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Structure101
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Conclusão
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Conclusão• Ao compreender o significado e importância de cada métrica
faz com que cada linha de código se volte para atender as mesmas e consequente o código fica com melhor legibilidade, manutenibilidade, extensibilidade...
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Apêndice
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Débito técnicoWard Cunningham criou o termo para indicar a responsabilidade que uma organização possui quando se diminui a qualidade da sua base de código, a fim de cumprir metas de curto prazo.
• Diminuir a qualidade sempre custa mais caro e o preço será cobrado logo a diante.
• Pesquisas da Forrester Research indicam que manter um software é mais caro que desenvolver um novo e ainda que um bug custa 30x mais quando encontrado em produção.
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Débito técnicoImportante destacar que existem duas vertentes na comunidade:
• A primeira define que qualquer defeito é um débito.• A outra defende que os defeitos que o “usuário enxerga” não são
débitos, que somente os desenvolvedores, arquitetos, projetistas, engenheiros, POs sabem e são responsáveis por estes
débitos.
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Débito técnicoMúltiplas fontes:
• Code debt - Violações de ferramentas de análise estática e estilo de codificação inconsistente.
• Design debt - Design smells e violações das regras de design.• Test debt - Falta de testes, cobertura inconsistente e testes
inadequados.• Documentation debt - Ausência de documentação para
conceitos/funcionalidades importantes, documentação fraca e/ou desatualizada.
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Débito técnico
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Code debt Design debt Test debt Documentation debt
Static analysis tool
violations
Design smells
Lack of tests No doc. for importante
concerns
.....
Inconsistent coding style
Violations of design rules
Inadequate coverage
Outdated doc.
www.desingsmells.com
Débito técnico
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Code debt Design debt Test debt Documentation debt
Static analysis tool
violations
Design smells
Lack of tests No doc. for importante
concerns
.....
Inconsistent coding style
Violations of design rules
Inadequate coverage
Outdated doc.
www.desingsmells.com
Histórico das métricas de software• Origem nos anos 60 e 70.
• Em 1955 com John Backus - LOC - FORTRAN - problemas: comentários devem ou não ser considerados?
• Provavelmente o primeiro artigo sobre medidas e métricas de software que tratava sobre complexidade foi "Quantitative Measurement Program Quality" de 1968 escrito por R. J. Rubey and R. D. Hartwick.
• Entre 70 e 80 surgiram muitas métricas que tentavam medir a complexidade.
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Histórico das métricas de software• Em 1974 R. W. Wolverton criou a primeira métrica para medir
a produtividade dos programadores.• Em 1976 Thomas McCabe introduz a Cyclomatic Complexity.• Já em 1979 Alan Albrecht (IBM) apresenta Pontos de Função.• Em 1981 Harrison apresenta Nesting Level.• No ano de 1982 Troy define um conjunto de métricas que
tentam quantificar modularidade, tamanho, complexidade, coesão e acoplamento de um programa.
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Histórico das métricas de software- Em 1994 Chidamber and Kemerer, surgem as conhecidas
"CK metrics" - métricas focadas em Orientação a Objetos.- etc...
H. Zuse, A Framework of Software Measurement. Berlin: Walter de Gruyter, 1998Wikipedia, “Metrics,” http://www.wikipedia.org/MetricsH. Zuse, Software Complexity: Measures and Methods. New York: Walter de Gruyter, 1991M. H. Halstead, Elements of Software Science. New York: Elsevier, 1977Wikipedia, “Static code analysis,” http://en.wikipedia.org/wiki/Static_code_analysis
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Por que usar métricas?• Inúmeras razões, mas as principais são:
• CUSTO $$$$.• Compreensão.• Avaliação.• Predição / Estimativa.• Aperfeiçoamento / Evolução.
• Testes automatizados (unit tests, GUI, regressão, performance, etc) e cobertura de código só apresentam informações sobre o funcionamento atual do código, não indicam nem quantificam a simplicidade, manutenibilidade, extensibilidade, abstração entre outros indicadores da qualidade de código.
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Por que usar métricas?• Foco na qualidade do produto.• Produtividade (por exemplo, é mais fácil dar manutenção em
um método com 10 linhas ou em um com 1000 linhas).
• Sobre o aspecto de Gerenciamento o processo de desenvolvimento:• Planejar e estimar custos e prazos.• Controle de qualidade.
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Antes, alguns cuidados?
S O F T P L A N
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
Complexidade ciclomática• Define a quantidade de caminhos lineares que
um programa (rotina) pode percorrer.• No gráfico de exemplo, temos uma
complexidade de 3.• Fórmula: Edges – Nodes + Connected
Components -> 8 – 7 + 2 = 3• API no Understand: Cyclomatic • Possui variantes: CyclomaticModified,
CyclomaticStrict.
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Complexidade ciclomática• Na CyclomaticModified uma estrutura complexa de decisão
(case, switch) conta apenas como 1 e não cada opção do case/switch, por exemplo:
• Na CyclomaticStrict em condições com operadores lógicos (AND e OR) cada opção conta como 1, por exemplo (valor = 3):
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Chidamber and Kemerer• Apresentaram 6 métricas voltadas para OO. Considerando
características estruturais e design da OO. São elas:• Weighted Method per Class (WMC).• Depth of Inheritance Tree (DIT).• Number of Children (NOC).• Coupling between Object classes (CBO).• Response for a Class (RFC).• Lack of cohesion in Methods (LCOM).
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Weighted Method per Class(WMC)
• Número de métodos da classe (não considera métodos da herança).
• Esta métrica mede a complexidade total de uma classe. Para isto, são considerados o total de métodos e a complexidade de cada um.
• Com base nisso podemos inferir o tempo e esforço necessário para desenvolver e manter a classe.
• Classes com alto WMC devem ser refatoradas para classes menores, com menor WMC.
• API no Understand: CountDeclMethod.
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Depth of Inheritance Tree (DIT)• Indica a profundidade da hierarquia de classes.• Quanto maior a árvore da hierarquia, mais métodos a classe
pode herdar, aumentando a sua complexidade.• API no Understand: MaxInheritanceTree.
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Depth of Inheritance Tree (DIT)
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Number of Children (NOC)• Indica o número de filhos imediatos.• Alto NOC, indica grande reuso (bom), no entanto quanto maior
o NOC maior a quantidade de testes (ruim).• API no Understand: CountClassDerived.
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Coupling Between Object (CBO)• Para cada objeto esta métrica indica o número de objetos que
está acoplado.• Uma classe A é acoplada a uma classe B se ela usa um método,
tipo ou variável de B.• Também conhecida como Efferent Coupling (CE).• Alto acoplamento evita reuso.• Acoplamento dever ser mantido ao mínimo.• Quanto maior, mais rigorosos devem ser os testes.• API no Understand: CountClassCoupled
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Response for a Class (RFC)• Mede o número de métodos chamados mais o número de
métodos da própria classe.• Indica o número máximo de métodos que podem ser
invocados a partir de um objeto.• Alto valor indica alta complexidade no design da classe e
valores baixos indicam alta reusabilidade e polimorfismo.
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Lack of Cohesion in Methods• Mede a falta de coesão da classe.• Avalia as diferenças da classe (dissimilaridade).• Alta dissimilaridade entre os métodos indica que a classe tem
mais de uma responsabilidade (SRP).• API no Understand: PercentLackOfCohesion.
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Nesting• Mede o nível máximo de aninhamento.• API no Understand: MaxNesting.
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Nesting
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Guia rápido
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Métrica Escopo SaneamentoAvgCyclomatic Projeto
ArquivoClasse
Rotina
Efetuar os saneamentos a seguir, para arquivo, classe, rotina Quebrar o fonte em mais arquivos, menores. Quebrar a classe em classes menores. Usar composição, padrões de projeto, etc. Single Responsibility Principle. Quebrar em rotinas menores. Usar refactorings para tal.
MaxNesting Projeto ArquivoClasse Rotina
Efetuar os saneamentos nas rotinas do projeto. Efetuar os saneamentos nas rotinas do arquivo. Efetuar os saneamentos nas rotinas da classe. Refactorings como: trocar condicional por polimorfismo, extrair método, tabelas de decisão como estrutura de dados, usar clausulas guarda, etc.
Guia rápido
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
CountLineCode Projeto Arquivo
Classe Rotina
Elimine redundâncias de código. Simplifique o design. Use OO/polimorfismo para reusar/compartilhar código. Elimine redundâncias de código. Simplifique o design. Use OO/polimorfismo para reusar/compartilhar código. Quebrar a classe em classes menores. Quebrar em rotinas menores. Usar refactorings como: trocar condicional por polimorfismo, extrair método, tabelas de decisão como estrutura de dados, etc.
CountLine Projeto Arquivo
Classe
Rotina
Elimine redundâncias de código. Simplifique o design. Use OO/polimorfismo para reusar/compartilhar código. Elimine redundâncias de código. Simplifique o design. Use OO/polimorfismo para reusar/compartilhar código. Quebrar a classe em classes menores e extrair para novos arquivos. Respeite SRP (Single Responsibility Principle) e ISP (Interface Segregation Principle) Quebrar em rotinas menores e extrair para novos arquivos. Usar refactorings como: trocar condicional por polimorfismo, extrair classe, extrair método, tabelas de decisão como estrutura de dados, etc.
Guia rápido
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
CountDeclSubProgram
Arquivo
Classe Rotina
Elimine redundâncias de código. Simplifique o design. Use OO/polimorfismo para reusar/compartilhar código. Quebrar a classe em classes menores. Refactorings como: extrair método, usar templates, etc. Consolide o comportamento em classes, lembrando do SRP (Single Responsibility Principle).
CountDeclClass Arquivo Refatore algumas classes para arquivos próprios.CountDeclMethod Classe Quebrar a classe em classes menores. Verifique se a classe não está fazendo
mais de um coisa, respeite o SRP (Single Responsibilty Principle)MaxInheritanceTree
Classe Quebrar a classe em classes menores. Utilize hierarquias mais razas. Use mais composição ao invés de herança. Padrões de projeto.
CountParams Rotina Falta OO? Agregue parâmetros com objetos. Repense as responsabilidades.
Guia rápido
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
Cyclomatic Projeto ArquivoRotina
Efetuar os saneamentos a seguir, para arquivo e rotina Quebrar o fonte em mais arquivos, menores Quebrar em rotinas menores. Usar refactorings como: trocar condicional por polimorfismo, extrair método, tabelas de decisão como estrutura de dados, etc.
CountClassCoupled Classe Reduza o número de dependências. Utilize interfaces, Dependency Inversion Principle.
PercentLackOfCohesion Classe Quebre em classes distintas, respeite o SRP (Single Responsibility Principle) e ISP (Interface Segregation Principle).
RatioCommentToCode Projeto Arquivo
Classe Rotina
Efetuar os saneamentos a seguir, para arquivo, classe, rotina O fonte não revela a verdadeira intenção e os comentários são "desodorantes"? Renomeie classes, métodos etc para deixar explícita a intenção. O fonte não revela a verdadeira intenção e os comentários são "desodorantes"? Renomeie métodos etc para deixar explícita a intenção. O fonte não revela a verdadeira intenção e os comentários são "desodorantes"? Renomeie variáveis, extraia métodos, etc.
Guia rápido
S O F T P L A N , 1 3 D E J A N E I R O D E 2 0 1 7
SOFTPLAN
• Dicas:• Prefira sempre corrigir as métricas pelo menor escopo, ou seja,
começando pela rotina, classe, arquivo e por último o projeto.• Prefira sempre refatorar rotinas que possuam testes automatizados.