## Introdução

A aplicação consistia em vendas de ingressos esportivos e estava utilizando a infraestrutura do Google: Firebase, Firestore (Banco de dados principal), Cloud Functions e Storage 
e o frontend/backend na Vercel com Next.js (Edge Functions e server components).

Ninguém sabia exatamente o porquê, mas o custo era alto e estava aumentando consideravelmente em pouco tempo. Parte da equipe já tentava reduzir este custo, mas algumas propostas estavam se baseando em adicionar componentes de arquitetura — como implementar um sistema de cache distribuído com Redis — sem validar, na minha visão, o problema central.

Minha abordagem foi diferente: entender a arquitetura e a aplicação mais a fundo, encontrar, medir e corrigir erros antes de adicionar mais complexidade.

N﻿este post vou explicar como eu encontrei o gargalo de custo e como cheguei no resultado mostrado na imagem abaixo

![Comparativo dos resumos de faturamento do firebase antes e depois da redução de custo](/images/frame-5-2-.png "Comparativo dos resumos de faturamento do firebase antes e depois da redução de custo")

## Primeiro passo: análise da arquitetura

Para entender o que estava acontecendo, comecei mapeando:

* A arquitetura (system design) da aplicação;
* Principais funcionalidades;
* Fluxos mais acessados;
* Relatórios das queries;
* Padrões da aplicação e códigos.

Como eu não conhecia a plataforma a fundo e precisava ser rápido, procurei inicialmente por gargalos óbvios. Fiz algumas melhorias, mas o impacto ainda não foi tão significativo quanto eu gostaria.\
Ficou claro que havia algo mais profundo acontecendo.

## Investigando utilização × custos

Com cerca de **11 mil usuários diários**, era esperado um volume moderado de queries.\
Porém, o painel de métricas mostrava consultas sendo executadas em uma escala completamente fora do normal — milhares de queries diariamente.

E o que tornava isso mais estranho: observando o relatório de custos, o maior gasto **não era a quantidade de queries**, mas sim o **tráfego de dados (egress)**, equivalente a **95% do total**.

Isso indicava que havia um problema sério nessas consultas. Além de serem muitas, traziam **muitos dados**.\
E a grande pergunta era:

> **Será que todos esses dados estavam realmente sendo utilizados?**

## O ponto crítico: o catálogo público de eventos

Ao rastrear as queries mais caras, cheguei à principal funcionalidade do sistema: um **catálogo público**, onde cards listam informações para que os usuários visualizem os produtos — bem semelhante a um catálogo comum com imagem e dados básicos.

E foi aí que encontrei o caos:

* A principal query era chamada **mais de 8 vezes por renderização**, gerando um volume desnecessário de consultas.
* Não havia uso de `select`: todos os atributos da coleção eram retornados, embora os cards usassem apenas alguns.
* Entre esses atributos existiam **imagens em Base64**, algo que nunca deveria estar salvo em um banco como o Firestore.
* Componentes duplicavam consultas já realizadas, misturando `fetch` com React Query e estados locais.
* Não havia paginação nem filtros no backend: tudo era filtrado no frontend.

Em resumo: **muitos dados, muitas vezes, sem necessidade**.

## Solução: refatoração da tela removendo toda a gambiarra e utilizando boas práticas de software

### 1° Remodelagem da consulta

Reescrevi a query utilizando um `where` mais restrito e com `select`, trazendo somente os atributos necessários para os cards.\
Removi completamente o Base64, que além de ser um problema, nem estava sendo utilizado.

```javascript
// Exemplo de consulta no firebase usando select + dbadmin.
const snapshot = await dbAdmin
      .collection(collectionName)
      .where('display', '==', true)
      .select(
        'name',
        'eventUrl',
        'eventCategory',
        'city',
        'state',
        'organizerName',
        'initialDate',
        'finalDate',
        'finished',
        'eventDay',
        'eventMounth',
        'hour',
        'display',
      )
      .get();
```

### 2° Refatoração dos componentes

Os cards passaram a exibir exclusivamente os dados vindos da query da tela, apenas uma vez.\
Eles deixaram de fazer requests internas, evitando mistura de responsabilidades.\
Com isso, a tela ficou mais simples, mais leve e muito mais fácil de manter.

### 3° Padronização do acesso aos dados e cache

Na tela principal, além de termos agora uma fonte única de dados, também padronizei o uso do `fetch`, recomendado pelo Next.js, incluindo seu sistema de cache nativo.\
Esse cache ajudou a reduzir chamadas repetidas de requisições idênticas.

```javascript
// Exemplo de chamada utilizando fetch + cache do next
const resHome = await fetch('api/eventos', { next: { revalidate: 300 } });
```

Com o tempo, ficou evidente que houve uma degradação daquela tela e da forma como o código tinha sido escrito — inclusive muito código gerado por IA sem revisão.\
Sei que muitas vezes temos pressa para implementar, e a pressão por entregas rápidas acontece. Mas, nesse caso, a falta de boas práticas e de um código manutenível custou **muito dinheiro**.

## Resultado: economia imediata

**Antes da refatoração:** R$ 300 por dia\
**Depois da refatoração:** R$ 29–30 por dia

![Relatorio mostrando o custo diário reduzido de um dia R$ 300 para o outro R$ 28](/images/screenshot_3.png "Relatorio mostrando o custo diário reduzido de um dia para o outro")

Uma redução acima de **90%**, sem mudar nenhuma funcionalidade da aplicação e sem adicionar novos componentes à arquitetura — apenas escrevendo o software da maneira correta.

Além da economia, o sistema ficou mais rápido e mais fácil de manter.

## Conclusão

Confesso que foi muito gratificante ver o gráfico de custos despencando. Ali estava registrado que a qualidade que busco entregar no meu trabalho não é para enfeitar ou para gerar “códigos bonitos”.\
**Qualidade é um requisito que impacta diretamente o financeiro de uma solução.**

Aplicar engenharia e usar boas práticas será sempre um excelente investimento, permitindo que sua solução cresça de maneira saudável — não apenas reduzindo custos, mas também suportando atualizações e novas oportunidades de mercado.

Um cliente me procurou porque a conta do Firebase passou dos R$ 11 mil por mês — e ninguém sabia exatamente por quê

Como reduzi os custos de infraestrutura em 90% usando apenas boas práticas de software

## I﻿ntrodução

Anteriormente fizemos uma câmera para poder tirar fotos usando o navegador, vamos agora evoluir a solução e gravar pequenos vídeos usando a mesma estrutura mais adicionando um novo recurso.

## Antes de começar!

I﻿remos utilizar como base o projeto de câmera feita no post anterior, ele é bem simples e caso você não tenha visto é só acessar aqui: **[Como criar uma câmera utilizando Javascript HTML5 e CSS3](https://www.gustavooliveira.dev/articles/como-criar-uma-camera-utilizando-javascript-html5-e-css3)**

V﻿imos no post anterior que a câmera é acessada pela api do navegador acessada pela função ***navigator.mediaDevices.getUserMedia*** e que ela só funciona em um contexto seguro, seja ele *localhost* ou usando *https* ([documentação oficial](https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia#privacy_and_security)) se atente a isso caso a sua câmera não esteja funcionando.

## Vamos ao trabalho

## P﻿asso 1: Ajustando o layout

B﻿asicamente a estrutura é a mesma, fiz apenas algumas alterações e adicionei alguns controles que uma câmera de vídeo precisa. A câmera aberta antes de gravar ficou assim: ⁣

![layout da camera de video usando html](/images/passo-1-layout.png "layout da camera de video usando html")

E﻿ quando está gravando:

![camera html enquanto grava o video](/images/passo-1-layout-gravando.png "camera html enquanto grava o video")

o﻿ código HTML: 

```html
 <div id="dialog-camera" class="absolute w-screen h-screen bg-stone-900 z-10 hidden">

        <div class="w-full h-full" id="video-preview-container">
          <video class="w-full h-full" autoplay id="video-preview"></video>

          <div id="timer" class="absolute bottom-20 w-fit mx-auto left-0 right-0 text-white z-10 hidden">00:00</div>
          <div
            class="absolute bottom-3 text-center z-10 grid grid-cols-3 p-2 justify-center place-items-center items-center w-full 
                      landscape:grid-rows-3  landscape:grid-cols-1 landscape:right-3 landscape:w-fit landscape:top-0 landscape:bottom-0">
            <i id="btn-close-dialog" class="fa-solid fa-xmark w-12 text-white text-3xl"></i>
            <i id="btn-recording"
              class="fa-solid fa-circle-dot text-[48px] w-12 rounded-full text-white bg-red-500 text-4xl "></i>
            <i id="btn-stop-recording"
              class="fa-solid fa-circle-stop text-[48px] w-12 rounded-full text-white bg-red-500 text-4xl hidden"></i>
            <i id="btn-toggle-camera" class="fa-solid fa-camera-rotate w-12 text-white text-3xl"></i>
          </div>
        </div>

        <div id="photo-preview-container" class="w-full h-full items-center justify-center hidden">
          <video class="w-full landscape:w-fit landscape:h-[75%]" controls id="video-preview-recorded"></video>
          <div id="actions-preview" class="absolute bottom-3 z-10 flex p-2 justify-around items-center w-full 
            landscape:flex-col-reverse landscape:right-3 landscape:w-fit landscape:top-0 landscape:bottom-0">
            <button id="btn-repeat" class="text-white px-3 py-2 ">Repetir</button>
            <button id="btn-ok" class="text-white px-3 py-2 ">OK</button>
          </div>
        </div>

      </div>
```

**Observação**: Estou mostrando somente o código alterado, caso queira acessar o código completo ***[acesse aqui](https://github.com/GustavoGcdo/camera-with-js/blob/master/index-camera-video.html)***

## P﻿asso 2: Recuperando elementos HTML e declaração das variáveis de controle

No início da minha tag *<script>* declarei as variáveis que serão utilizadas para recuperar os elementos referentes a câmera, os controles mais genéricos como botões de abrir/fechar a câmera e logo depois as minhas variáveis de controle que me ajudarão a manter o estado da câmera.

```javascript
  // recuperando elementos da camera de video
  const videoPreview = document.querySelector('#video-preview');
  const btnCamera = document.querySelector('#btn-recording');
  const btnStopCamera = document.querySelector('#btn-stop-recording');
  const videoPreviewContainer = document.querySelector('#video-preview-container');
  const photoPreviewContainer = document.querySelector('#photo-preview-container');
  const previewRecorded = document.querySelector('#video-preview-recorded');
  const timer = document.querySelector('#timer');
  
  // recuperando elementos de controle genericos
  const dialogCamera = document.querySelector('#dialog-camera');
  const btnToggleCamera = document.querySelector('#btn-toggle-camera');
  const btnOpenCamera = document.querySelector('#btn-open-camera');
  const btnCloseDialog = document.querySelector('#btn-close-dialog');
  const btnRepeat = document.querySelector('#btn-repeat');
  const btnOk = document.querySelector('#btn-ok');
  
  // declarando variaveis de controle
  let currentFacingMode = 'environment';
  let mediaRecorder;
  let streamCamera;
  let secondsElapsed = 0;
  let intervalId;
```

## P﻿asso 3: Iniciar/Pausar a câmera

I﻿niciar a câmera é exatamente igual para quando vamos fazer uma câmera apenas para tirar uma foto. Primeiro declaramos uma função que será responsável por chamar a api *getUserMedia* do navegador que caso obtenha sucesso irá retornar um stream no qual vamos direcionar para um objeto de vídeo e também iremos salvar este stream nas nossas variáveis de controle, pois iremos usar tanto para a gravação quanto para parar a câmera quando não estivermos usando.

```javascript
  const startCamera = (facingMode = 'environment') => {
    stopCamera();
    navigator.mediaDevices.getUserMedia({
      video: {
        facingMode,
        width: {
          max: 1980,
          ideal: 1024
        },
        height: {
          max: 1080,
          ideal: 768
        }
      }
    }).then((stream) => {
      videoPreview.srcObject = stream;
      streamCamera = stream;
    })
  }
 
```

**L﻿inha 17:** Note que estamos usando a variável ***streamCamera*** anteriormente declarada para armazenar o stream.

P﻿ara parar a câmera usaremos o stream do vídeo e percorremos cada track chamando o método ***stop*** de cada uma.

```javascript
 const stopCamera = () => {
    if (videoPreview.srcObject) {
      const stream = videoPreview.srcObject;
      const tracks = stream.getTracks().forEach((track) => track.stop());
    }
  }
```

U﻿samos o método ***startCamera*** sempre que usuário abre a câmera pela primeira vez ou quando ele precisa trocar o modo câmera frontal ou traseira. Como mostra as funções a seguir:

```javascript
  btnOpenCamera.addEventListener('click', () => {
    dialogCamera.classList.toggle('hidden');
    photoPreviewContainer.classList.add('hidden');
    videoPreviewContainer.classList.remove('hidden');

    startCamera(currentFacingMode);
  });

  btnToggleCamera.addEventListener('click', () => {
    if (currentFacingMode == 'environment') {
      currentFacingMode = 'user';
    } else {
      currentFacingMode = 'environment'
    }

    startCamera(currentFacingMode);
  })
```

## P﻿asso 4: Gravar um vídeo

Para gravar um vídeo vamos precisar de um objeto chamado **MediaRecorder** ele será o responsável por obter através do stream gerado da câmera pequenos pedaços que chamamos de ***chunks*** que iremos armazenar na memória e quando a gravação terminar juntaremos os *chunks* em um arquivo único no formato *Blob.* 

Para isso acontecer de forma organizada vamos criar algumas funções para separar cada responsabilidade deste processo.

```javascript
const startRecording = () => {
    btnCamera.classList.toggle('hidden');
    btnStopCamera.classList.toggle('hidden');
    btnToggleCamera.classList.toggle('hidden');
    timer.classList.toggle('hidden');
    secondsElapsed = 0;

    mediaRecorder = new MediaRecorder(streamCamera, {
      mimeType: 'video/webm;codecs=vp8'
    });

    const chunks = [];
    mediaRecorder.ondataavailable = (event) => {      
      chunks.push(event.data);
    }

    mediaRecorder.onstop = () => {
      const blob = new Blob(chunks, { type: 'video/mp4' });
      const urlPreview = URL.createObjectURL(blob);
      previewRecorded.src = urlPreview;

      photoPreviewContainer.classList.replace('hidden', 'flex');
      videoPreviewContainer.classList.toggle('hidden');

      mediaRecorder = null;
      stopTimer();
    }

    const CHUNK_SIZE = 1000; // 1 seg
    mediaRecorder.start(CHUNK_SIZE);
    startTimer();
  }
```

A﻿ função principal é a **startRecording** vamos observar cada parte para entender o que está acontecendo.

**L﻿inhas 2-5**: Estamos removendo da tela o botão de gravação e de troca de câmera (já que durante a gravação não é permitido trocar entre as câmeras)

**L﻿inha 6**: Estamos zerando o contador do vídeo.

**L﻿inhas 8-10**: Instanciamos um novo objeto **MediaRecorder** passando o **streamCamera** (nosso stream que está inicializado) e o parâmetro de gravação ***mimeType*** para que ele saiba que é um vídeo e qual codec de gravação. 

**L﻿inhas 12-15**: Declaramos um array para armazenar os pedaços do video (*chunks*) e na função logo após estamos adicionando ao array conforme recebemos os pedaços pelo callback ***ondataavailable*** do objeto **mediaRecorder**.

**L﻿inhas 17-27**: Aqui estamos tratando quando a gravação for parada pelo usuário que é escutada a partir do callback **onstop**. 

Na ***linha 18*** pegamos os chunks e passamos para uma nova instância do objeto Blob com o parâmetro de *video/mp4* que será o formato de saída do vídeo, já na **linha 19** geramos uma URL local para podermos mostrar na pré-visualização do vídeo setado na **linha 20**.

Em sequência estamos:

\- Habilitando o preview do vídeo gravado (linha 22);

\- Escondendo a câmera (linha 23);

\- Zerando o objeto mediaRecorder (linha 25);

\- Parando o timer (linha 26).

**L﻿inhas 29-31:** Definimos o tamanho do *chunk* em 1 segundo, iniciamos a gravação juntamente com o timer.

A﻿ função que chama o ***startRecording*** é essa:

```javascript
 btnCamera.addEventListener('click', () => {
    startRecording();
  });
```

P﻿ara parar de gravar o vídeo iremos usar a função: 

```javascript
const stopRecording = () => {
    streamCamera.getTracks().forEach((track) => track.stop());
    mediaRecorder.stop();
  }
```

E iremos chamar a função no clique do botão de stop:

```javascript
  btnStopCamera.addEventListener('click', () => {
    stopRecording();
  })
```

### Funções que manipulam o timer (iniciar, formatar e parar)

**Observação:** Estas são apenas funções genéricas geradas pelo chatGPT para formatar os segundos passados no formato 00:00 e atualizar o texto da div do timer.

```javascript
  const formatTime = (seconds) => {
    const minutes = Math.floor((seconds % 3600) / 60).toString().padStart(2, '0');
    const secs = (seconds % 60).toString().padStart(2, '0');
    return `${minutes}:${secs}`;
  }

  const startTimer = () => {
    intervalId = setInterval(() => {
      secondsElapsed++;
      timer.textContent = formatTime(secondsElapsed);
    }, 1000);
  }

  const stopTimer = () => {
    timer.textContent = '00:00';
    clearInterval(intervalId);
  }
```

A﻿pós gravar se deu tudo certo, a tela ficará assim:

![Pré-visualização do video gravado](/images/apos-gravacao.png "Pré-visualização do video gravado")

### F﻿unções utilizadas para manipular a tela e resetar os controles

```javascript
 resetControls = () => {
    btnCamera.classList.remove('hidden');
    btnStopCamera.classList.add('hidden');
    btnToggleCamera.classList.remove('hidden');

    timer.classList.add('hidden');
    secondsElapsed = 0;
    stopTimer();
  }
 
 btnCloseDialog.addEventListener('click', () => {
    dialogCamera.classList.toggle('hidden');

    resetControls();
    stopCamera();
  });

  btnRepeat.addEventListener('click', () => {
    previewRecorded.src = '';

    photoPreviewContainer.classList.replace('flex', 'hidden');
    videoPreviewContainer.classList.toggle('hidden');

    resetControls();
    startCamera();
  });

  btnOk.addEventListener('click', () => {
    dialogCamera.classList.toggle('hidden');
    photoPreviewContainer.classList.replace('flex', 'hidden');
    videoPreviewContainer.classList.toggle('hidden');

    resetControls();
    stopCamera();
  });
```

**D﻿ICA:** É﻿ muito importante que você pare a utilização da câmera quando não estiver utilizando para evitar que sua aplicação use muita memória ou tenha problemas futuros ao tentar abrir uma câmera que ficou aberta por engano. Por isso chamamos o **stopCamera** nas **linhas 15 e 34** 

## Código-fonte

T﻿odo código-fonte tanto deste exemplo quanto do tutorial anterior se encontra neste repositório [github](https://github.com/GustavoGcdo/camera-with-js)

## Conclusão

Antes de finalizar, gostaria de agradecer à Michelle Corrêa pelo contato e pela dúvida, que inspirou a criação deste post. Espero que o conteúdo tenha sido útil e ajudado a entender melhor como funciona a gravação de vídeos utilizando os recursos do navegador. Muito obrigado a todos!

Caso tenham dúvidas podem deixar nos comentários aqui em baixo ou me mandar em um dos meus contatos deixados na página [sobre mim](https://www.gustavooliveira.dev/about).

Aprenda como implementar uma câmera e gravar pequenos videos usando html, javascript e css de forma simples

Como gravar vídeos usando HTML Javascript e CSS

## Introdução

Recentemente precisei implementar uma câmera na web utilizando as apis nativas do javascript para resolver um problema relacionado ao conflito do uso de memória com câmeras nativas e o navegador onde estava sendo executado a aplicação.

## Contexto do problema

Temos uma aplicação web que em uma das suas principais funcionalidades era tirar várias fotos e gravar vídeos além de coletar outras informações de texto e como toda aplicação client side isso tudo fica na memória do navegador até o usuário subir para o backend. 

Mas o problema era que no tempo de tirar as fotos e abrir o aplicativo de câmera do próprio celular, o sistema operacional estava resetando o processo do navegador, limpando o que havia sido preenchido nos formulários com as imagens tiradas. 

Após várias tentativas de otimização de memória e pesquisas na internet, encontrei alguém com o mesmo problema no stackoverflow e não foi nada animador.

> [L﻿ink](https://stackoverflow.com/questions/14274727/android-browser-refreshes-page-after-selecting-file-via-input-element) para a discussão original

![](https://lh5.googleusercontent.com/jzQ-NJDqdRDodIi6ZOnf0wqIWOoic_GIa_lXg3PiZoshJldOgdNi1NYyIsLtuIdImx2fJgJHV0aCouG8CRNVTBZ6J2BH731JfODUXIIt-pl-lRcQE9DNrnzO_6qvtPuk3ZVd3PLS28baJyPkq1iGXBI)

## Solução

Como eu precisava trazer uma solução em um curto prazo, eu não poderia sugerir que tínhamos que refazer toda a solução web para nativa então decidi usar javascript, html e css para criar uma câmera na web evitando assim que o usuário saísse da aplicação, ganhando um pouco de tempo para planejar uma solução definitiva.

## Mãos à obra

Agora que já temos um contexto e uma motivação, bora ver como ficou a implementação dessa câmera passo a passo. 

Ferramentas utilizadas:

* HTML, CSS, Javascript
* TailwindCSS (Para facilitar a estilização)
* Font-awesome (Para os ícones da câmera)

Optei por utilizar essas ferramentas no exemplo para focar mais na funcionalidade, assim você pode utilizar este exemplo e transportar para qualquer outro framework como React, Angular ou Vue.js.

### INFORMAÇÃO IMPORTANTE!

\- As funções que acessam câmera só funcionam em um contexto seguro como **localhost** ou **https** por questões de segurança implementadas pelo navegador ([veja o link](https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia#privacy_and_security))

## Passo 1: Layout da câmera

Tentei reproduzir o mais próximo a uma câmera de celular padrão. O resultado ficou assim:

![preview do layout da camera](/images/passo-1-1.png "Preview do layout da camera")

O código html:

![código html com a estrutura básica da camera](/images/passo-1.png "Código html com a estrutura básica da camera")

Explicações importantes

**Linha 34:** div que irá conter o preview da câmera e suas ações;

**Linha 35:** tag de vídeo que será utilizado para mostrar o que a câmera está captando.

**Linha 36:** tag canvas que será responsável por tirar um “snapshot” da pré-visualização do vídeo, no nosso caso vai servir para nossa foto.

**Linha 45:** div que agrupa os elementos que serão utilizados para visualizar a foto tirada e suas ações.

**Linha 48-49:** tag de imagem que será responsável por mostrar a imagem tirada. É importante acrescentar o atributo ***'crossorigin="anonymous"'***, pois o resultado do snapshot será uma url criada a partir de um Blob que talvez o navegador não conheça e impeça de ser usada.

## Passo 2: Pré-Visualizar a câmera

![código javascript com a função de start para a camera](/images/passo-2.png "Código javascript com a função de start para a camera")

Para pré-visualizar a câmera é preciso pedir a permissão ao usuário, fazemos isso através do método ***navigator.mediaDevices.getUserMedia (linha 73)*** que já recebe por parâmetro as configurações que vamos usar na câmera.

Descrição dos parâmetros que estamos usando:

**video.facingMode**: tipo de câmera ‘user’ para frontal ou ‘environment’ para as outras câmeras;

**video.width** e **video.height**: resolução do vídeo altura e largura (aceita ideal, max, min);

> Todas as propriedades podem ser encontradas na documentação oficial [aqui](https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia).

Após a permissão concedida, a promise do método getUserMedia retorna um objeto stream que configuramos como fonte para o elemento de vídeo, mostrando o assim preview da câmera. (linha 86). 

Não podemos esquecer de chamar o método startCamera (linha 90) logo após para que tudo isso possa acontecer.

## Passo 3: Tirar uma foto

![](/images/passo-3.png)

**Linha 92-96**: Recuperamos os elementos que iremos manipular para tirar a foto (btnCamera, canvas), ocultar o preview da câmera (videoPreviewContainer) e mostrar a foto tirada (photoPreviewContainer, photoPreview).

**Linha 98:** Definimos o método que irá tirar o snapshot quando o botão camera for clicado. Dentro do método:

* Definimos o tamanho da foto que será gerada a partir do tamanho do vídeo (linhas 99 e 100).
* Configuramos o contexto 2d para o objeto canvas (linha 101)
* Capturamos o momento do vídeoPreview desenhando ele no canvas (linha 103)
* Convertemos o resultado em um objeto Blob (linha 105)
* Criamos uma url a partir do objeto blob e configuramos no preview da foto (linha 106)
* Ocultamos o preview da câmera e habilitamos o preview da foto (linhas 107 e 108)

## Passo 4: Troca entre as câmeras

![código javascript para troca entre as cameras](/images/passo-4.png "Código javascript para troca entre as cameras")

**Linha 118:** Recuperação do botão de troca de câmera no DOM;

**Linhas 120-124:** Verificando qual câmera está ativa no momento através da variável de escopo mais global currentFacingMode e alternando entre as câmeras.

**Linha 126:** Inicializando a câmera passando o novo facingMode. 

#### Modificação no método "*startCamera*":

![alteração código método start e novo metódo stopCamera](/images/passo-4-2.png "Alteração código método start e novo metódo stopCamera")

Adicionei um novo método chamado **stopCamera (linhas 90-95)** para desabilitar a câmera atual (verificando se ela está ativa antes) e possibilitando a troca entre as duas câmeras. Daí é só chamar este método toda vez que precisarmos inicializar a câmera com novas propriedades **(linha 72)**;

**Observação:** Caso o dispositivo não suporte o facingMode: ‘user’ que corresponde a câmera frontal, o método **getUserMedia** sempre inicializará com a câmera padrão (*environment*). 

## Código-fonte

T﻿odo código-fonte do exemplo se encontra neste repositório do [github](https://github.com/GustavoGcdo/camera-with-js);

T﻿ambém está publicado na vercel e pode ser acessado por esse [link](https://camera-with-js.vercel.app/).

## Conclusão

E﻿spero que tenham gostado e aprendido um pouco com este tutorial assim como eu. Caso tenham dúvidas podem deixar nos comentários aqui em baixo ou me mandar em um dos meus contatos deixados na página [sobre mim](https://www.gustavooliveira.dev/about).

Como construir um componente do zero que acessa sua câmera  e tira foto utilizando apenas as funcionalidades nativas do navegador

Como criar uma câmera utilizando Javascript HTML5 e CSS3

## Introdução

“Software em funcionamento mais que documentação abrangente”, este é talvez um dos valores mais mal interpretados do manifesto desde que a metodologia ágil se tornou tão popular. Com tanta “velocidade” (ou pressa) para produzir sistemas acabamos utilizando esta frase como desculpa para não documentar ou não dar a devida importância a uma boa documentação.

A consequência disso, principalmente em arquitetura de software, está mais perto do que pensamos: falta de organização e padronização, desenvolvedores em ilhas de conhecimento, dificuldade de agregar novas pessoas e claro dificuldade de visualizar problemas que afetam não só o próprio desenvolvimento como também o negócio.

## C4 model para documentar e visualizar arquitetura de software

[Simon Brown](https://simonbrown.je/), o criador do modelo C4 Model conseguiu trazer de forma clara e objetiva uma forma de como podemos criar uma boa documentação de arquitetura. Um dos seus grandes pontos fortes na minha opinião é a facilidade de comunicar arquitetura em diferentes níveis de detalhes, conectando as diferentes partes interessadas, de dentro e também de fora do desenvolvimento, com o que realmente precisam e querem saber. Além disso, proporciona uma melhor integração de novas pessoas e ajuda tanto na análise quanto na avaliação da arquitetura vigente.

## Visualização em 4 níveis de abstração

C4 model, em geral, é dividido em 4 níveis de abstrações (os 4 Cs), cada um com seus respectivos público-alvos e recomendações. A ideia do criador é como se você estivesse ampliando um mapa e obtendo mais detalhes sobre determinado local. São eles:

1. Contexto
2. Container
3. Componente
4. Código

## Aprendendo na prática!

Para explicar e exemplificar cada um, vamos utilizar uma modelagem de um sistema de vendas simples. Assim espero ajudar você a aprender e quem sabe até usar este artigo como guia para criar os seus próprios diagramas.

### Nível de Contexto

Aqui está o começo de tudo. Estamos em uma visão de mais alto nível da arquitetura, então o foco aqui não está nos detalhes de tecnologia, e sim nas interações com personas e sistemas, sejam próprios ou externos.

![diagrama de contexto](/images/contexto.png "Diagrama de contexto")

**Público-alvo:** todos, técnicos e não técnicos, dentro e fora da equipe de desenvolvimento de software.

Conseguimos identificar de cara as principais personas (Cliente e Administrador), ambas interagindo com o sistema principal, que por sua vez tem duas dependências externas (Sistema de Pagamento e Sistema de Envio de E-mails). Essas informações, mesmo que aparentemente simples, já são relevantes para diversas tomadas de decisões de arquitetura, tais como: discutir qual serviço pode ser escolhido para o sistema de pagamento ou qual a expectativa de quantidade de acessos pelos clientes.

### Nível de Container

Ampliando a visão na caixa azul representando o sistema de vendas, chegamos no nível de container, e neste nível já podemos ver um pouco mais de detalhes. Aqui o foco é ter a visão de alto nível de como as responsabilidades do sistema serão divididas em unidades implantáveis e também como elas irão se comunicar. 

**Observação:** Não confunda com containers docker, por mais que coincidentemente a maioria das caixinhas pode se tornar um container docker, não é verdade que todos serão.

![diagrama de container](/images/container.png "Diagrama de container")

**Público-alvo:** pessoas técnicas dentro e fora da equipe de desenvolvimento de software; incluindo arquitetos de software, desenvolvedores e equipe de operações/suporte.

Focando no nosso exemplo, fica evidente que estamos nos preparando para uma carga de eventos que pode ser alta, e por isso o container para lidar com mensageria com seu próprio banco. Alguns podem até estar se perguntando: não seria melhor colocar um microsserviço para lidar com pedidos? e sim! E acredito que é justamente isso que essa visão nos proporciona, “visualizar” onde podemos melhorar ou simplificar dependendo do contexto de negócio e suas restrições. 

Fica simples visualizar como o sistema irá tomar forma e ainda comunicar isso com outras pessoas. Eu inclusive já utilizei essa visão para planejar uma implantação com o time de infraestrutura, e tudo ficou mais claro.

### Nível de Componentes

Escolhendo o container do backend para ampliarmos, podemos ver que aqui temos muito mais detalhes. Nesta visão, o foco é ver como o container é composto de vários componentes, cada um com suas responsabilidades e comunicações. Esses componentes podem ser um conjunto de classes, módulos e até mesmo um grupo de funções, contanto que consiga comunicar bem o que faz e por que está ali.

**\
Observação:** para fins de exemplo e a imagem não ficar tão carregada utilizei apenas os componentes referentes ao registro de pedido.

![diagrama de componentes](/images/componente.png "Diagrama de componentes")

**Público-alvo:** arquitetos e desenvolvedores de software.

Observando o exemplo, conseguimos ver o papel de cada componente, integrações e também ter uma boa ideia do fluxo que o dado (pedido no caso) irá passar. Mesmo sem nunca termos visto o sistema, fica evidente quais lugares devemos olhar se precisarmos de algo referente ao registro de pedido.

Como podemos ver, esse é um diagrama que pode ser bem mais frágil as mudanças devido à quantidade de detalhes, então, somente faça se ele agregar valor ao time ou projeto.

### Nível de Código

Por fim, chegamos ao último nível de “zoom”, agora ampliando algum componente para visualizar como ele é implementado. Podemos usar o diagrama de classe UML ou similares (Algumas IDEs geram este tipo de diagrama)

O próprio autor recomenda utilizar somente em componentes extremamente importantes ou complexos.

![diagrama de codigo](/images/codigo.png "Diagrama de codigo")

**Público-alvo:** arquitetos e desenvolvedores de software.

No exemplo ampliamos o componente “Registrar Pedido Use Case”, utilizei este diagrama para comunicar a inversão de dependências, objeto de retorno e uma possível exceção. Você pode acrescentar detalhamento, como nome de propriedades ou até mesmo com seus parâmetros caso precise. Confesso que, desde quando passei a usar o C4 model para documentar os sistemas onde trabalho, ainda não precisei chegar a este nível de detalhe. Mas mesmo assim, é válido tê-lo na caixa de ferramentas para quando for necessário discutir algo mais baixo nível ou entender um cenário complexo de uma implementação.

## Conclusão

Minhas experiências adotando o modelo C4 foram bastante positivas. Ele não só me ajudou na organização, nas estratégias e nas decisões relacionadas à arquitetura dos softwares, mas também se mostrou uma ferramenta valiosa de comunicação com outras equipes e pessoas não técnicas. Contudo, recomendo sempre analisar bem e utilizar o modelo de forma estratégica para agregar valor, escolhendo cuidadosamente os níveis de detalhes que o time e projeto precisam, bem como o público que consumirá as informações. Não faça apenas por fazer, pois só gerará burocracia e logo será abandonado.



## Links úteis

\- <https://c4model.com/> (O site oficial tem muita informação boa e clara além de ter várias dicas de ferramentas para criar os diagramas e outros diagramas, recomendo muito dar uma olhada)

\-﻿ <https://draw.io/> (Utilizei essa ferramenta para produzir os diagramas, é bem fácil de utilizar para exemplos mais simples)

\- <https://www.youtube.com/watch?v=f0Dp6Ob2guc> (Uma live top do Arquiteto das galáxias sobre o assunto)

Nunca foi tão necessário criar uma boa documentação até você precisar de uma! Vamos explorar o modelo C4 para documentação de arquitetura de software e como ele pode simplificar alguns aspectos que antes eram difíceis de serem padronizados

Visualização de sistemas com C4 model

## Introdução

Já faz um bom tempo que a plataforma heroku anunciou mudanças no plano gratuito ([mais detalhes](https://www.youtube.com/watch?v=8f9y6P5H7Go)). Quando soube nem liguei muito, mas agora que resolvi retomar com as atividades do blog percebi que teria que dar um jeito, pois era lá que estava hospedado o antigo CMS deste blog.

## Um pouco da história da criação do blog

Lembro que na época o objetivo era criar algo para poder compartilhar experiências pessoais e documentar meu aprendizado, então pensei: vou criar um blog! Com o blog eu poderia colocar em prática o que estava estudando e também ajudar alguém que esteja querendo aprender algo comigo.

Escolhi fazer o blog utilizando Next.js e para a gestão de conteúdo o strapi um headless CMS. O processo de desenvolvimento foi bem legal e aprendi muita coisa, porém depois que terminei fiquei pensando “será que precisava de toda essa arquitetura apenas para um blog simples?”. 

Claro que para um ambiente de testes e projeto pessoal era super válido, mas não sei se recomendaria criar toda essa estrutura, pelo menos não de início.

## Estrutura antes da atualização

Na antiga estrutura, o servidor do CMS ficava hospedado dentro do heroku com o banco de dados postgreSQL e o frontend em Next.js hospedado na vercel.

![diagrama com a estrutura anterior](/images/estrutura-antiga.png "Diagrama com a estrutura anterior")

Utilizando os recursos de geração estática do Next.js através das funções **getStaticProps** e **getStaticPaths** o frontend buscava os dados da api dos posts e dados que eram dinâmicos das páginas e gerava no build toda a parte estática necessária para poder ser indexado pelos buscadores. 

O mais legal é que se o conteúdo muda o Next faz o fetch novamente para gerar as páginas conforme os novos dados e caso contrário ele os mantém como estavam.

E o que me deixou impressionado é que quando o serviço de banco de dados foi desligado do heroku e a api do strapi parou de funcionar, o blog continuou com as páginas normalmente sem quebrar por falta do conteúdo. 

Gostei de trabalhar com essas ferramentas e inclusive já apliquei essa stack em projetos onde trabalho. Porém, a﻿nalisando essa arquitetura e o "problema" que eu queria resolver (um blog simples onde somente eu faço manutenção e escrevo o conteúdo) vi que era exagero demais. E﻿sse é um dos casos onde vale lembrar do padrão de design **[KISS "Keep it Simple, Stupid"](https://www.interaction-design.org/literature/article/kiss-keep-it-simple-stupid-a-design-principle)** traduzindo de forma livre, mantenha isso estupidamente simples.



## Modificações e atualizações

A primeira e a mais importante modificação: precisava trocar o CMS.  Pesquisei e vi algumas alternativas, até que conheci o Netlify CMS pelo blog do Willian Justen [neste post aqui](https://willianjusten.com.br/usando-netlify-cms-com-nextjs-vercel-e-github) - inclusive recomendo muito o conteúdo desse cara - gostei bastante de como ele funciona e iria suprir minhas necessidades.

### Netlify CMS e a estrutura nova

Para quem não conhece o Netlify é um CMS que usa o git para gerenciar o conteúdo e esse conteúdo fica todo dentro do projeto, então não tem a necessidade um banco de dados ou servidor separado.

![diagrama da estrutura nova](/images/estrutura-nova-cms.png "Diagrama da estrutura nova")

### Configuração Vercel/Next.js

A configuração dentro do next é bem simples. Seguindo a [documentação](https://www.netlifycms.org/docs/add-to-your-site/) basta criar uma pasta onde ficará o cms dentro do diretório **/public** e configurar dois arquivos **index.html** e **config.yml**. 

![estrutura de pastas para configurar o cms](/images/estrutura-pastas-cms-0.png "Estrutura de pastas para configurar o cms")

Dentro do arquivo **config.yml** é bem tranquilo configurar suas coleções de dados e seus respectivos campos, qual a pasta onde ele vai usar para colocar o conteúdo e mídias. Segue minha configuração:

```yaml
backend:
  name: github
  repo: GustavoGcdo/personal-blog
  branch: master
  squash_merges: true ## Estrategia de juntar todos commits em um quando publicar
  base_url: https://www.gustavooliveira.dev/
  auth_endpoint: api/auth/ ## Endpoint para autenticação com git

media_folder: "public/images"
public_folder: "/images"
publish_mode: editorial_workflow ## Habilitar modo workflow
slug:
  encoding: 'ascii'
  clean_accents: true

collections:
  - name: posts
    label: posts
    folder: posts 
    create: true 
    slug: '{{slug}}' 
    fields:
      - { label: 'Layout', name: 'layout', widget: 'hidden', default: 'post' }
      - { label: 'Date', name: 'publishedAt', widget: 'datetime', format: 'YYYY-MM-DD hh:mm:ss' }
      - { label: 'Post Image', name: 'image', widget: 'image', required: true }
      - { label: 'Title', name: 'title', widget: 'string' }
      - { label: 'Description', name: 'description', widget: 'string' }
      - { label: 'Body', name: 'body', widget: 'markdown' }
```

Para autenticar usando a vercel/next seguir os seguintes passos: 

1. Certificar que na **config.yml** o ***auth_endpoint*** está configurado para **api/auth** (confira linha 7 do arquivo acima).
2. Instalação do pacote [@openlab/vercel-netlify-cms-github](https://www.npmjs.com/package/@openlab/vercel-netlify-cms-github) e configuração dos arquivos **api/auth.ts** e **api/callback.ts**.

   ```typescript
   // src/pages/api/auth.ts
   export { auth as default } from '@openlab/vercel-netlify-cms-github'
   ```

   ```typescript
   // src/pages/api/callback.ts
   export { callback as default } from '@openlab/vercel-netlify-cms-github'
   ```
3. Configurar um “new OAuth App” para permitir autenticação dentro do github (<https://github.com/settings/developers>)

   ![Configuração do aplicativo OAuth github](/images/register-on-github.png "Configuração do aplicativo OAuth github")
4. Copiar as keys geradas no github

   ![Keys github](/images/github-keys.png "Keys github")
5. Configurar as keys do git como *OAUTH_CLIENT_ID* e *OAUTH_CLIENT_SECRET* nas variáveis de ambiente da Vercel.

   ![Variáveis de ambiente na vercel](/images/env-vercel.png "Variáveis de ambiente na vercel")

Com isso configurado, é só entrar com github e já terá acesso ao CMS.

### Workflow

Ainda nas configurações, o netlify também nos permite habilitar o *editorial_workflow*, um modo de publicação que utiliza pull requests para gerenciar em qual estágio está o seu conteúdo, no meu caso os posts.

![Workflow netlify cms](/images/workflow-publish.png "Workflow netlify cms")

Dessa forma é possível gerenciar visualmente o que está sendo feito e quando o conteúdo está pronto é só clicar em publicar que a branch do post é mergeada com a branch principal e estará disponível para deploy.

![Pull request no github controlado pelo netlify](/images/pull-request.png "Pull request no github controlado pelo netlify")

**Bônus**: Atualmente publicando o projeto na Vercel ainda é possível ver uma versão com essas branchs antes de serem publicadas, conseguindo avaliar como ficaria em produção e também criar comentários.

![Interface de adicionar comentário vercel em um aversão ainda não publicada](/images/comentario-vercel-2.png "Interface de adicionar comentário vercel em um aversão ainda não publicada")

### Next.js 13

A segunda atualização foi mais para experimentar algumas coisas da nova versão do Next.js 13, vi que tinha bastante coisa legal e que poderia ser aplicada.

A primeira coisa que fiz foi atualizar a versão do React.js para a 18 e logo em seguida atualizei a versão do Next.js para a última versão estável.

S﻿ei que não é novidade, mas ainda não tinha atualizado o projeto para usar o diretório "**src"** então também já aproveitei e fiz. Achei que ficou bem mais organizado.

![Estrutura de pastas utilizando src](/images/estrutura-src.png "Estrutura de pastas utilizando src")

Das novas funcionalidades do Next.js as que apliquei no projeto foram:

* **Next/font:** Utilização de um novo sistema de carregamento de fontes auto-hospedadas para melhorar o desempenho e evitar o ***layout shift*** (Aquela piscada na tela onde pode se perceber a troca de fonte quando há um certo delay na rede)
* **Next/image:** A nova versão ﻿﻿trouxe diversas otimizações de desempenho e facilidades de configuração.

Existem outras funcionalidades que ainda não apliquei aqui, mas pretendo utilizar como o **novo diretório app** e também os **ServerComponents** que estão bastante interessantes.

Caso queiram conhecer todas as novidades confira [aqui](https://nextjs.org/blog/next-13)

## Conclusão

Experimentar e aprender novas tecnologias é sempre muito empolgante, eu particularmente gostei muito do resultado e com certeza me animou para crescer ainda mais. Espero que tenham gostado do conteúdo e ter motivado vocês a continuarem um projeto ou até mesmo iniciar um novo.

Voltando a escrever aqui no blog, e já começando com novidades! Conheça a arquitetura do blog, o porquê decidi mudar o CMS para uma plataforma mais simples e testando algumas das novas funcionalidades do Next.js 13.

Novidades blog: Migrando para Netlify CMS e atualização para Next.js 13


### Introdução

O assunto desenvolvimento Ágil para mim sempre foi muito controverso. Quanto mais estudava sobre o assunto ou conversava com outros desenvolvedores, mais tinha a impressão que na prática não funcionava muito bem. Os interesses em sua maioria pareciam estar em microgerenciar pessoas ou fazer entregas correndo sem dar tanta atenção a qualidade, isso não condizia com o que eu lia na literatura sobre ser “ágil”. Confesso que até já tentei aplicar na equipe que faço parte tempos atrás, mas não obtive sucesso, hoje sei que estava fazendo errado.

Foi a partir dessas experiências e pensamentos que me interessei e comprei o livro de Robert. C Martin: **Desenvolvimento Ágil Limpo - De volta às origens**. Sou um grande fã do autor e nada melhor para explicar o assunto a alguém que esteve lá no dia em que tudo começou. A leitura do livro foi muito esclarecedora e com certeza me fez refletir sobre o tema e seu verdadeiro propósito me inspirando em compartilhar com vocês o que aprendi.

### Primeiro de tudo: Manifesto Ágil

O manifesto é onde tudo começou, provavelmente você já deve ter visto por aí. Ele foi criado por volta dos anos 2001 em Snowbird onde várias pessoas importantes de diferentes processos se reuniram para conversar sobre processos leves. Dentre eles Kent Beck, o criador da XP e o próprio autor do livro em que me refiro chegaram a quatro princípios onde concentraram toda a essência da metodologia. São eles:

**Pessoas e interações**, mais que processos e ferramentas;

**Validação de software**, mais que documentação exaustiva e longa;

**Colaboração com o cliente**, mais que negociação de contratos;

**Resposta a mudanças**, mais que seguir um plano cegamente;

Podemos ver que os princípios aparentemente são simples, mas dentro de cada um existe um profundo conhecimento que tange várias áreas do software desde o desenvolvimento até o negócio.

O importante é notar que cada princípio está dividido em dois pontos: o lado esquerdo da vírgula nos mostra o que deveríamos dar mais atenção, contudo não exclui o lado direito, ambos são complementares. Por exemplo, ter uma boa validação de software é bom mas não significa que não se deve ter nenhuma documentação, responder a mudanças não exclui ter um planejamento e por aí vai.

### Não é sobre andar rápido, é sobre andar bem

“Muitos acham que a agilidade é sobre fazer as coisas rapidamente. Mas não é. Nunca se tratou de fazer as coisas rapidamente. A metodologia ágil é saber, o mais cedo possível, o quanto estamos ferrados.” Uncle Bob

Gostei tanto dessa frase do autor que coloquei na descrição desse post. Segundo ele, desenvolvimento ágil não é sobre andar rápido, mas sim andar bem, andar com consciência. É uma análise constante para boas tomadas de decisões de negócio, tudo isso aliado às boas práticas, com certeza, trarão os resultados esperados para o projeto.

Separei em alguns tópicos o que achei ser mais importante saber sobre a essência da metodologia ágil, como:

- Trabalhar de forma ágil é como correr uma maratona: não adianta disparar na largada e morrer no caminho, deve-se manter um ritmo sustentável.
- Agilidade nos possibilita gerar dados para que possamos tomar boas decisões, sejam elas técnicas ou de negócio. A através desses dados também vamos ser melhores em definir nossas estimativas e expectativas;
- Os ciclos de análise, estimativas, planejamento, implementação e feedback nunca acabam. A menos quando o cliente já está satisfeito com o que foi entregue, são esses ciclos curtos que vão nos ajudar na melhoria contínua e respostas a mudanças.
- Ser ágil é não abrir mão da qualidade, muito pelo contrário _“A única forma de avançar rápido é fazer as coisas bem feitas”_
- As entregas devem conter valor de negócio agregado. Por esse motivo os interessados devem participar dos ciclos ativamente e contribuir na priorização das funcionalidades.
- Profissionalismo,. Ambos os lados têm que assumir riscos e fazer o que deve ser feito. Devemos ser claros e exigentes no que estamos produzindo, pois isso pode e vai impactar a vida das pessoas.

#### Restrição tripla

Outro ponto que gostaria de destacar é sobre o gerenciamento da _restrição tripla_. Conhecer e saber lidar com ela, certamente irá nos dar mais consciência na tomada de decisões de nossos projetos.

Basicamente consiste em quatro interesses: **Bom, Rápido, barato e concluído,** nos quais você pode escolher apenas **três.**

Você pode querer que um projeto seja _bom, rápido e barato_ mas ele certamente não será **concluído;**
Ou então pode querer um projeto: bom, barato e concluído, porém ele não será **rápido**.

> 💡 Com base nos dados gerados durante os ciclos de entrega, as partes interessadas devem determinar o quão bom, rápido, barato e concluído o projeto será. Isso também é considerado quando são realizadas mudanças no escopo, no cronograma, na equipe e na qualidade.

### Relação com Extreme Programing (XP) e suas práticas

O autor destaca que uma das metodologias que mais representam os princípios do manifesto ágil em seus processos é a XP. No seu ciclo de vida e práticas recomendadas podemos ver uma forma mais aplicada a cada um dos princípios ágeis.

O ciclo de vida na XP está subdivido em três círculos, cada um representa uma area: o mais externo representa as práticas de negócio, o círculo do meio as práticas relacionadas a equipe e o mais interno as práticas técnicas.

![Ciclo de vida XP.svg](/images/Ciclo_de_vida_XP.svg)

#### Práticas de negócio:

- **Planejamento do jogo:** É a prática na qual serão divididas funcionalidades, histórias e tarefas. Nessa etapa, são decididas as estimativas e prioridades em relação ao cronograma.
- **Pequenas Versões:** orienta a equipe a trabalhar em pedaços pequenos do projeto
- **Testes de Aceitação:** É aqui onde se define como uma funcionalidade, história ou tarefa realmente está “concluída” (importante dizer que estamos falando do ponto de vista do usuário, não adianta “terminar” e o usuário não conseguir usar!)
- **Equipe como um todo:** Esta prática consiste em deixar claro os papéis e que todos estão trabalhando juntos para atingir o mesmo objetivo.

#### Práticas de equipe:

- **Ritmo Sustentável:** Busca por uma velocidade de equipe mais uniforme.
- **Propriedade coletiva:** Garantir com que a equipe toda tenha conhecimento sobre o projeto e não individualize o mesmo.
- **Integração Contínua:** Manter a equipe com foco em fechar o ciclo de feedback com frequência.
- **Uso de metáforas:** é a prática que cria e promove uma boa comunicação entre todas as partes interessadas.

#### Práticas técnicas:

- **Programação em dupla:** É a prática que promove o conhecimento compartilhado entre a equipe técnica, analisando e colaborando entre si.
- **Design Simples:** Esta prática guia a equipe para evitar desperdício de esforço.
- **Refatoração:** incentiva a melhoria contínua e o refinamento de todos os produtos de trabalho.
- **Desenvolvimento Orientado a Testes:** É a segurança que a equipe técnica usa com o objetivo de avançar rapidamente, mantendo a mais alta qualidade.

### Conclusão

Confesso que sempre que ouvia falar sobre esse assunto tinha um pé atrás. Muito era apenas aparência, no final , todo mundo ainda fazia gambiarras e trabalhava além das horas combinadas para entregar. Acredito que seja muito cedo para falar se estou totalmente errado, é preciso ter mais experiências na área. Ainda assim, posso dizer que através do que li, voltei a acreditar que é possível fazer algo bom, com qualidade e seguindo ciclos de melhoria contínua.

Sobre o livro, recomendo demais. Aliás, considero todos os livros de Robert C. Martin referências para qualquer desenvolvedor ou líder técnico. Fiquei curioso em saber mais sobre as práticas da XP, tenho certeza que vou atrás desse conhecimento.

Após a leitura e algumas análises me senti confiante, e estou tentando aplicar novamente na minha equipe, agora sim, com a visão e maneira correta. Adianto que já estou colhendo resultados bastante satisfatórios e talvez até faça um outro post para contar como tem sido minha experiência nessa jornada.


Muitos acham que a agilidade é sobre fazer as coisas rapidamente. Mas não é. Nunca se tratou de fazer as coisas rapidamente. A metodologia ágil é saber, o mais cedo possível, o quanto estamos ferrados.

Seja bem vindo!

Estou muito feliz em poder compartilhar minhas experiencias com você, espero que possa te ajudar em alguma coisa.