# Processo de desenvolvimento Bricks

Este documento tem como objetivo facilitar o entendimento do processo de desenvolvimento junto ao **Bricks**, explicando o objetivo de cada fase.

## Índice

* [Bricks](#bricks)
* [Propósito](#propósito)
* [Fluxo](#fluxo)
* [Fases](#fases)
* [Análise](#análise)
* [Validação da análise](#validação-da-análise)
* [Implementação](#implementação)
* [Testes](#testes)
* [Revisão de código](#revisão-de-código)
* [Fechamento de versão](#fechamento-de-versão)
* [Bugs encontrados](#bugs-encontrados)
* [Equipe responsável](#equipe-responsável)

## Bricks

O [Bricks](https://bricks.wssim.com.br/) é uma biblioteca que entrega um conjunto de componentes responsivos criados em **ReactJS**, tendo utilização junto à solução **Web**, a biblioteca foi criada pelo time de front-end da **WealthSystems** para dar suporte ao desenvolvimento dos aplicativos web de uma forma rápida e fácil.

## Propósito

Todas implementações antes de serem realizadas devem ser analisadas, criticadas e por fim executadas da melhor forma possível. Pontos como impacto gerado, escopo de atribuição, execução e padronização são dentre muitos, os fatores que mais afetam a manutenibilidade da biblioteca.

Com isso surgiu a preocupação de criar e manter um processo, tendo como objetivo o foco na evolução de uma forma segura, detalhada e dentro dos padrões.

## Fluxo


## Fases

### Análise

É necessário uma tarefa de análise da implementação desejada, contendo informações detalhadas e objetivas, os pontos necessários para facilitar a **validação da análise**.

A tarefa deve conter:
- Caso de uso que gerou a demanda ( cliente interno ou externo );
- Análise de escopo;
- Definição do escopo de implementação junto às soluções já existentes, levando em consideração a utilização de bibliotecas de terceiros, exclusão de soluções que contenham regras de negócio e padrões de layout;
- Plano de desenvolvimento;
- Ter um plano de execução da implementação, propondo a forma com que a ideia será implementada, trazendo pontos técnicos para dar fundamentação à proposta;
- Análise e validação conjunta a UX;
- O apoio de UX para componentes do **bricks** é primordial, visto que temos **guidelines** e a quebra disso impacta globalmente;
- Alterações tanto relacionadas a layout ou funcionalidade já existentes devem possuir uma análise de impacto, levando em consideração a utilização do componente em soluções já implementadas;

### Validação da análise

Após a análise ser entregue pelos interessados, será feita uma validação junto à equipe responsável pelo **Bricks**. Essa validação poderá ser efetuada por um **responsável** ou pela **equipe responsável**.

Pontos mais críticos a serem validados:
- Validação da solução proposta para o escopo do **bricks**;
- Auxílio na filtragem do que esta sendo proposto para implementação, ideias para bibliotecas de terceiros e formas de desenvolvimento alternativas que possam ser mais adequadas ao contexto;
- Validações de layout, tendo como objetivo não apenas propor mudanças, mas também evitar problemas que possam ser desconhecidos pela equipe de análise;
- Auxílio na quebra de código e estruturação;

### Implementação

Tendo a validação concluída, todo material que possa ter sido gerado é atualizado junto à análise, a implementação será realizada pela equipe interessada, tendo a total liberdade de procurar os responsáveis para sanar qualquer dúvida ou alteração que possa surgir no processo;
- Implementação do componente;
- Implementação do show case + documentação;
- Implementação de testes;

### Testes

Todas as implementações realizadas dentro do **Bricks** devem ter a maior cobertura de testes possível, os testes devem ser validados no mínimo em cenários como:

- Testes relacionados ao componente no escopo **bricks**, sendo validado propriedades, funções, layout, callbacks, etc. Garantindo o funcionamento do componente e o que ele se propõem a entregar;

- Testes que visam ter uma validação de componentes já utilizados e de comportamento esperado, validando assim, se houve quebras, bugs ou qualquer efeito colateral junto a utilização do mesmo;

- Testes envolvendo a figura de um QA ao processo, o mesmo garantirá os cenários acima citados, testando o componente no show case, validando a documentação e caso for uma alteração ou adição de funcionalidade, testando no midgard todos os cenários onde o componente já é utilizado, garantindo a compatibilidade e funcionamento;

### Revisão de código

A revisão do código pode ser feita por qualquer desenvolvedor, porém é obrigatório o aceite de pelo menos um membro da **equipe responsável** pelo **Bricks**. Sem este aceite, não será possível a continuação do processo;

## Fechamento de versão

O fechamento de versão poderá acontecer tanto pela equipe responsável pelo **Bricks**, quanto pela que está responsável pela implementação. Seguindo o fluxo do processo definido, principalmente dos merges que geram code review.

## Bugs encontrados

Caso sejam encontrados bugs ou problemas em um componente, na qual a versão do **Bricks** já foi fechada, seguindo o fluxo definido ambos os times poderão realizar a correção e fazer o fechamento de uma nova versão.

## Equipe responsável

- Eduardo Rodrigues Reichert - [e-mail]
- Guilherme Anderzen Polido - [e-mail]
- Luiz Felipe Weber - [e-mail]
- Sanderson Cristian Silva - [e-mail]