Inspeção de Código Clipper - Case de um projeto ágil

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



Regras

12

77SCRUM

Trello (Kanban).

Release Note.

Sprint Mensal

Retrospectiva.

360°

Daily

Sprint

Backlog

Increment


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


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



Classe de Teste

Regras

12

1010Refatoração

Continuous Improvement

Refactor

TestDo

Opportunity

Plan



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




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.




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




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


Parser



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


Parser



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



Parser



x Case Insensitive

3

85%

Cobertura

29

Regras

1717Processo Desenho do

Processo Clean Code Case Insensitive



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



4

90%

Cobertura

34

Regras

Abílio Gambim Parada

coesão é utilizado como um outro termo técnicopoderia ser citados valores;responsabilidade única

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


5

94%

Cobertura

37

Regras

2020Documentação Viva

Predio C – 7ª AndarSala 301 - Tecnopuc Documentação

Viva Fast Inspector


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


5

94%

Cobertura

37

Regras

2222Suíte de Teste Suíte de Testes Inspeção do

Projeto Java



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



6

96%

Cobertura

43

Regras

2424POC PL/SQL



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 Case Insensitive






x Objetivo de 99.5% de cobertura


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



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


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 [email protected]

Leonardo Carvalho [email protected]

Thomás Daniel [email protected]

Obrigado!

Software

Inspeção de Código Clipper - Case de um projeto ágil