Post on 14-Apr-2017
WorkshopInspeção de Código ClipperCase de um projeto ágil
Abílio Gambim ParadaCarlos André GieseLeonardo Carvalho DupratesThomás Daniel Vieira
Fábio UggeriRicardo VieiraRodrigo Severo
22Projeto
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%
33
Entrega
Qualidade Inovação
Valores
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 8x Falhas na Inspeçãox TDDx Pouco Feedbackx Planning semanal
x Status andamento do projeto
x Acúmulo de tarefas nahomologaçã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 deregras maiscomplexas
x Objetivo de 99.5% de cobertura
x Entrada em produção
Regras12
70%Cobertura
Regras
85%Cobertura
Regras29
90%Cobertura
Regras34
94%Cobertura
Regras37
96%Cobertura
Regras43
97%Cobertura
Regras50
98%Cobertura
Regras5620
POC para a linguagem PLSQL
55MVP
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
1x Falhas na Inspeçãox TDDx Pouco Feedbackx Planning semanal
12
Regras
66Escopo
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
1x Falhas na Inspeçãox TDDx Pouco Feedbackx Planning semanal
Regras
12
77SCRUM
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çãox TDDx Pouco Feedbackx Planning semanal
1
Regras
12
88Kanban
Test & CodeTo do Code Review MVP Escopo aberto Scrum Kanban – Trello Teste Unitário Refatoração Sprint Mensal Teste Funcional Feedback
1x Falhas na Inspeçãox TDDx Pouco Feedbackx Planning semanal
Regras
12
99Teste Unitário
Regra1 1
Estrutura sintática
1Classe de Teste1
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.
FastIndependentRepeatableSelf-validatingTimelly
MVP Escopo aberto Scrum Kanban – Trello Teste Unitário Refatoração Sprint Mensal Teste Funcional Feedback
1x Falhas na Inspeçãox TDDx Pouco Feedbackx Planning semanal
Classe de Teste
Regras
12
1010Refatoração
Continuous Improvement
Refactor
TestDo
Opportunity
Plan
MVP Escopo aberto Scrum Kanban – Trello Teste Unitário Refatoração Sprint Mensal Teste Funcional Feedback
1x Falhas na Inspeçãox TDDx Pouco Feedbackx Planning semanal
Regras
12
1111Ignore Line
InputActionParserO 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 := 1Local lVar2 := .v.Local lVar3 := .T.
Trecho de código após Ignore-Line:
123
Local nVar1 := 1
Local lVar3 := .T.
123
Ignore line TDD XP Lean
x Status andamento do projeto
x Acúmulo de tarefas nahomologação
70%
Cobertura
20
2
Regras
1212TDD
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
TDDAjusta 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 nahomologação
2
70%
Cobertura
20
Regras
1313eXtreme Programming
Testes
EntregaContinua
Trabalho Coletivo
Padrões deCodificação Feedback Refatoração
Bullshit
Pair Programming
IntegraçãoContinua
Simplicidade
Inovação
Time Coeso
Pequenas Entregas
Ignore line TDD XP Lean
x Status andamento do projeto
x Acúmulo de tarefas nahomologação
2
70%
Cobertura
20
Regras
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
1515Testes 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
1616Burn Down
28/03/2
016
29/03/2
016
30/03/2
016
31/03/2
016
01/04/2
016
04/04/2
016
05/04/2
016
06/04/2
016
07/04/2
016
08/04/2
016
11/04/2
016
12/04/2
016
13/04/2
016
14/04/2
016
15/04/2
016
18/04/2
016
19/04/2
016
20/04/2
016
21/04/2
016
24/04/2
016
25/04/2
016
26/04/2
017
27/04/2
018
28/04/2
0190
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
1717Processo Desenho do
Processo Clean Code Case Insensitive
x Visibilidade do Projeto
x Tempo de Inspeção
4
90%
Cobertura
34
Regras
1818Clean 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
1919Documentação VivaAssuntos: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
2020Documentaçã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
2121Fast 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 precisa ser executada.
Arquivos fonte Clipper
Documentação Viva
Fast Inspector
x Adequação aos Padrões do Sicredi
5
94%
Cobertura
37
Regras
2222Suíte de Teste Suíte de Testes Inspeção do
Projeto Java
x Possibilidade de novos projetos
x Entendimento deregras maiscomplexas
Checks – Criação das Regras
Squid – Parser do código Clipper6
96%
Cobertura
43
Regras
2323Inspeção Projeto Java Suíte de Testes Inspeção do
Projeto Java
x Possibilidade de novos projetos
x Entendimento deregras maiscomplexas
6
96%
Cobertura
43
Regras
2424POC 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
2525Projeto Clipper
1 2 3 4 5 6 7 8x Falhas na Inspeçãox TDDx Pouco Feedback
x Status andamento do projeto
x Acúmulo de tarefas nahomologaçã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 deregras maiscomplexas
x Objetivo de 99.5% de cobertura
x Entrada em produção
Regras12
Regras Regras29
Regras34
Regras37
Regras43
Regras50
Regras5620
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
2626Opiniã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
2727Feedback
Abílio Gambim Paradaabiliop@dbserver.com.br
Leonardo Carvalho Dupratesleonardod@dbserver.com.br
Thomás Daniel Vieirathomasv@dbserver.com.br
Obrigado!