## 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.