O documento descreve um projeto para desenvolver um plugin para a ferramenta SonarQube capaz de realizar inspeção de código na linguagem Clipper para identificar violações de padrões. O projeto utilizou métodos ágeis como Scrum e Kanban e práticas como TDD, entregas contínuas e testes automatizados para alcançar altos níveis de cobertura de regras e qualidade do código.

1. Workshop
Inspeção de Código Clipper
Case de um projeto ágil
Abílio Gambim Parada
Carlos André Giese
Leonardo Carvalho Duprates
Thomás Daniel Vieira
Fábio Uggeri
Ricardo Vieira
Rodrigo Severo

2. 22
Projeto
O objetivo do projeto é construir um plugin para a ferramenta SonarQube, capaz
de realizar inspeção de projetos da linguagem Clipper para identificar violações.
A violação é um trecho de código fora do padrão de regras definidas pelos
manuais de Arquitetura do Sicredi.
Criticidade: bloqueante, crítico, maior,
menor e info.
Inspeção de código para linguagem Clipper
SonarQube é uma plataforma de código livre desenvolvida para gerenciar a qualidade de um projeto de desenvolvimento de software. O objetivo é garantir a
cobertura dos sete eixos da qualidade do código: Arquitetura e Design, Comentários, Regras de Codificação, Bugs, Complexidade, Testes Unitários, Duplicações.
Regras: arquitetura, eficiência, logico,
legibilidade, manutenção, segurança e
entendimento.
SONARQUBE
PLUGIN CLIPPER SICREDI
PROJETOS CLIPPER SICREDI
50% 70% 60% 60%

3. 33
Entrega
Qualidade Inovação
Valores

4. 44
 MVP
 Escopo aberto
 Sprint Mensal
 Teste Unitário
 Teste Funcional
 Refatoração
 Kanban – Trello
 Scrum
 Feedback
 Ignore line
 TDD
 XP
 Lean
 Entrega Semanal
 Teste
Automatizado
 Burn Down
 Cobertura do
Parser
 Desenho do
Processo
 Clean Code
 Case Insensitive
 Documentação
Viva
 Fast Inspector
 Suíte de Testes
 Inspeção do
Projeto Java
Timeline
 Automação do
sonar-properties
1 2 3 4 5 6 7 8
x Falhas na Inspeção
x TDD
x Pouco Feedback
x Planning semanal
x Status andamento
do projeto
x Acúmulo de
tarefas na
homologação
x Falta de projetos
reais
x Manutenabilidade
do Código
x Case Insensitive
x Visibilidade do
Projeto
x Tempo de Inspeção
x Adequação aos
Padrões do Sicredi
x Possibilidade de
novos projetos
x Entendimento de
regras mais
complexas
x Objetivo de
99.5% de
cobertura
x Entrada em
produção
Regras
12
70%
Cobertura
Regras
85%
Cobertura
Regras
29
90%
Cobertura
Regras
34
94%
Cobertura
Regras
37
96%
Cobertura
Regras
43
97%
Cobertura
Regras
50
98%
Cobertura
Regras
5620
 POC para a
linguagem PLSQL

5. 55
MVP
Mínimo Viável
Mínimo + Viável
É a versão mais simples de um produto com uma quantidade mínima de esforço e tempo de desenvolvimento que pode demonstrar e comprovar a
viabilidade de implementação para o negocio.
 MVP
 Escopo aberto
 Scrum
 Kanban – Trello
 Teste Unitário
 Refatoração
 Sprint Mensal
 Teste Funcional
 Feedback
1
x Falhas na Inspeção
x TDD
x Pouco Feedback
x Planning semanal
12
Regras

6. 66
Escopo
Certeza Técnica
Entrega com maior Valor Agregado
Alinhamento com o Cliente
Flexibilidade
 MVP
 Escopo aberto
 Scrum
 Kanban – Trello
 Teste Unitário
 Refatoração
 Sprint Mensal
 Teste Funcional
 Feedback
1
x Falhas na Inspeção
x TDD
x Pouco Feedback
x Planning semanal
Regras
12

7. 77
SCRUM
Trello (Kanban).
Release Note.
Sprint Mensal
Retrospectiva.
360°
Daily
Sprint
Backlog
Increment
 MVP
 Escopo aberto
 Scrum
 Kanban – Trello
 Teste Unitário
 Refatoração
 Sprint Mensal
 Teste Funcional
 Feedback
x Falhas na Inspeção
x TDD
x Pouco Feedback
x Planning semanal
1
Regras
12

8. 88
Kanban
Test & CodeTo do Code Review
 MVP
 Escopo aberto
 Scrum
 Kanban – Trello
 Teste Unitário
 Refatoração
 Sprint Mensal
 Teste Funcional
 Feedback
1
x Falhas na Inspeção
x TDD
x Pouco Feedback
x Planning semanal
Regras
12

9. 99
Teste Unitário
Regra
1 1
Estrutura
sintática
1 Classe de Teste
1
Arrange, Act and Assert
Como codificar um teste limpo:
Como estruturar o teste: Os três passos claramente definidos para o teste unitário são preparar, agir e
verificar. Primeiro preparamos o que será testado (dados, ambiente, etc.), em seguida realizamos as
operações que serão testadas e por fim verificamos os resultados obtidos. É importante explicitar estas
etapas no código, para mantê-lo limpo.
Fast
Independent
Repeatable
Self-validating
Timelly
 MVP
 Escopo aberto
 Scrum
 Kanban – Trello
 Teste Unitário
 Refatoração
 Sprint Mensal
 Teste Funcional
 Feedback
1
x Falhas na Inspeção
x TDD
x Pouco Feedback
x Planning semanal
Classe de Teste
Regras
12

10. 1010
Refatoração
Continuous Improvement
Refactor
Test
Do
Opportunity
Plan
 MVP
 Escopo aberto
 Scrum
 Kanban – Trello
 Teste Unitário
 Refatoração
 Sprint Mensal
 Teste Funcional
 Feedback
1
x Falhas na Inspeção
x TDD
x Pouco Feedback
x Planning semanal
Regras
12

11. 1111
Ignore Line
InputActionParser
O Input apaga a linha indicada pelo ActionParser
O ActionParser informa qual linha causa o problema
ActionParser é o passo inicial do funcionamento
do programa. Ele inicia a leitura do arquivo e a montagem
da árvore sintática.
Input é a classe que representa o arquivo a ser
processado pelo parser. Nessa classe que será eliminado as
linhas com erros, indicadas pela ActionParser2.
Local nVar1 := 1
Local lVar2 := .v.
Local lVar3 := .T.
Trecho de código após Ignore-Line:
1
2
3
Local nVar1 := 1
Local lVar3 := .T.
1
2
3
 Ignore line
 TDD
 XP
 Lean
x Status andamento
do projeto
x Acúmulo de
tarefas na
homologação
70%
Cobertura
20
2
Regras

12. 1212
TDD
Cada funcionalidade deve iniciar com um teste
unitário que falhará até que a condição de sucesso
seja implementada.
Fail
Desenvolva a funcionalidade conforme as
condições de saída implementadas no
teste unitário. A funcionalidade só estará
concluída quanto o teste passar.
Test & Code
Refactor
TDD
Ajusta e otimiza a funcionalidade
desenvolvida e executa os testes
unitários implementados.
Todos os testes devem passar.
 Ignore line
 TDD
 XP
 Lean
x Status andamento
do projeto
x Acúmulo de
tarefas na
homologação
2
70%
Cobertura
20
Regras

13. 1313
eXtreme Programming
Testes
Entrega
Continua
Trabalho Coletivo
Padrões de
Codificação
Feedback
Refatoração
Bullshit
Pair Programming
Integração
Continua
Simplicidade
Inovação
Time Coeso
Pequenas
Entregas
 Ignore line
 TDD
 XP
 Lean
x Status andamento
do projeto
x Acúmulo de
tarefas na
homologação
2
70%
Cobertura
20
Regras

14. 1414
Entrega
As entregas são validadas a tempo de serem
corrigidas caso seja identificado uma
melhoria ou correção
Entrega
A maior frequência nas entregas permite a
toda a equipe buscar oportunidades de
inovação e melhorias do projeto.
Entrega
O envio Burn Down apresenta a evolução do
projeto permitindo validar se o
planejamento correto.
Entrega
Entrega Semanal
 Entrega Semanal
 Teste
Automatizado
 Burn Down
 Cobertura do
Parser
x Falta de projetos
reais
x Manutenabilidade
do Código
x Case Insensitive
3
85%
Cobertura
29
Regras

15. 1515
Testes Automatizados
Garantir a cobertura dos testes
Reduzir o tempo de execução
Aumentar a assertividade
Feedback rápido e constante
Automação das tarefas manuais
• Na Sprint 01 e Sprint 02 os teste do plugin foram
executados manualmente para todos os
projetos.
• Ao encontrar um defeito analisava-se a linha
onde este ocorreu-o, e reiniciava-se a execução.
• Na Sprint 03 foi implementado um método baseado no
mecanismo ignore line para registrar as linhas com
problemas e continuar a inspeção.
• Não foram mais realizados testes manuais.
Testes manuais: Testes automatizados: Entrega Semanal
 Teste
Automatizado
 Burn Down
 Cobertura do
Parser
x Falta de projetos
reais
x Manutenabilidade
do Código
x Case Insensitive
3
85%
Cobertura
29
Regras

16. 1616
Burn Down
0
2
4
6
8
10
12
Projeto 2054 - Sprint X - Parser e Regras
Target Burn Down Actual Burn Down
 Entrega Semanal
 Teste
Automatizado
 Burn Down
 Cobertura do
Parser
x Falta de projetos
reais
x Manutenabilidade
do Código
x Case Insensitive
3
85%
Cobertura
29
Regras

17. 1717
Processo
 Desenho do
Processo
 Clean Code
 Case Insensitive
x Visibilidade do
Projeto
x Tempo de Inspeção
4
90%
Cobertura
34
Regras

18. 1818
Clean Code
Simplicidade
Expressividade
Coesão
“Um código limpo é simples e direto.
É tão legível quanto uma prosa bem
escrita. Ele jamais torna confuso o
objetivo do desenvolvedor, em vez
disso, é sempre repleto de abstrações
claras e linhas de comando
objetivas.”
Grady Booch, autor do livro
Object Oriented Analysis and Design with Applications
Padronização
Legibilidade
Refatoração Objetividade
 Desenho do
Processo
 Clean Code
 Case Insensitive
x Visibilidade do
Projeto
x Tempo de Inspeção
4
90%
Cobertura
34
Regras

19. 1919
Documentação Viva
Assuntos:
1. Estrutura do Parser;
2. Mecanismo Ignore-Line;
3. Estrutura das Regras;
4. Código Limpo;
5. Testes Unitários;
6. Desenho do Processo
7. Fast-Inspector.
 Documentação
Viva
 Fast Inspector
x Adequação aos
Padrões do Sicredi
5
94%
Cobertura
37
Regras

20. 2020
Documentação Viva
Predio C – 7ª AndarSala 301 - Tecnopuc
 Documentação
Viva
 Fast Inspector
x Adequação aos
Padrões do Sicredi
5
94%
Cobertura
37
Regras

21. 2121
Fast Inspector
Hash
Fast-Inspector é um mecanismo para acelerar a inspeção de código Clipper. A cada
inspeção do projeto, é criptografada uma hash do conteúdo do código fonte. Essas informações
são salvas no banco do Sonar e comparadas a cada inspeção.
Caso a nova hash seja igual a antiga, então a inspeção não precisaser executada.
Arquivos
fonte Clipper
 Documentação
Viva
 Fast Inspector
x Adequação aos
Padrões do Sicredi
5
94%
Cobertura
37
Regras

22. 2222
Suíte de Teste
 Suíte de Testes
 Inspeção do
Projeto Java
x Possibilidade de
novos projetos
x Entendimento de
regras mais
complexas
Checks – Criação das Regras
Squid – Parser do código Clipper6
96%
Cobertura
43
Regras

23. 2323
Inspeção Projeto Java
 Suíte de Testes
 Inspeção do
Projeto Java
x Possibilidade de
novos projetos
x Entendimento de
regras mais
complexas
6
96%
Cobertura
43
Regras

24. 2424
POC PL/SQL
x Entrada em
produção
 POC para a
linguagem PLSQL
 PL/SQL oportunidade de Futuro Projeto
 Conhecimento gerado na Equipe,
 Viabilidade de construção,
 Validação da necessidade do cliente,
 Entrega focada em MVP
7
97%
Cobertura
50
Regras

25. 2525
Projeto Clipper
1 2 3 4 5 6 7 8
x Falhas na Inspeção
x TDD
x Pouco Feedback
x Status andamento
do projeto
x Acúmulo de
tarefas na
homologação
x Falta de projetos
reais
x Manutenabilidade
do Código
x Case Insensitive
x Visibilidade do
Projeto
x Tempo de Inspeção
x Adequação aos
Padrões do Sicredi
x Possibilidade de
novos projetos
x Entendimento de
regras mais
complexas
x Objetivo de
99.5% de
cobertura
x Entrada em
produção
Regras
12
Regras Regras
29
Regras
34
Regras
37
Regras
43
Regras
50
Regras
5620
70%
Cobertura
85%
Cobertura
90%
Cobertura
94%
Cobertura
96%
Cobertura
98%
Cobertura
99%
Cobertura
 MVP
 Escopo aberto
 Sprint Mensal
 Teste Unitário
 Teste Funcional
 Refatoração
 Kanban – Trello
 Scrum
 Feedback
 Ignore line
 TDD
 XP
 Entrega Semanal
 Teste
Automatizado
 Burn Down
 Cobertura do
Parser
 Desenho do
Processo
 Clean Code
 Case Insensitive
 Documentação
Viva
 Fast Inspector
 Suíte de Testes
 Inspeção do
Projeto Java
 Automação do
sonar-properties
 POC para a
linguagem PLSQL

26. 2626
Opinião do cliente
 Boa comunicação no alinhamento diário sobre desenvolvimento e procedimentos
 Flexibilidade de escopo e planejamento na definição de regras e desenvolvimento
x Falta de ferramenta de integração com o Sicredi semelhante ao Trello
ou um fórum
 Pró-atividade na sugestão de melhorias
 Refatoração e ajustes com agilidade nos problemas detectados pela
homologação
 Foco nas entregas de maior valor agregado

27. 2727
Feedback
Abílio Gambim Parada
abiliop@dbserver.com.br
Leonardo Carvalho Duprates
leonardod@dbserver.com.br
Thomás Daniel Vieira
thomasv@dbserver.com.br
Obrigado!