análise e métricas de codificação

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

Obrigado!

RÔMULO AUGUSTO CAMPOS PELACHINI

romulo@softplan.com.br 48 3027 8000romuloacp@gmail.com

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.