DEV Community: Cristiano Gonçalves ⛩️

Entendendo renderização no browser: Como o DOM é gerado?

Cristiano Gonçalves ⛩️ — Sun, 10 Nov 2024 18:11:19 +0000

Nos artigos anteriores nós aprendemos sobre o DOM e sobre o CSSOM, se você ainda tem dúvidas sobre essas duas palavrinhas recomendo fazer a leitura dos dois posts abaixo:

Recapitulando, o DOM é uma estrutura que o navegador utiliza para renderizar a nossa página. Porém, os dados da internet não são trafegados em forma de DOM, logo precisa existir um processo antes do DOM ficar pronto para o navegador consumir.

Nesse momento você pode estar se perguntando como os dados trafegam na internet?

Sempre que acessamos um site acontece uma troca em um padrão que chamamos de cliente x servidor.

Nessa troca o cliente (seu navegador) pede para acessar o site www.cristiano.dev para o servidor, que respondem com todo o conteúdo do site solicitado, mas esse conteúdo vem em forma de bytes e de uma forma que está distante do html/css/js que conhecemos.

O que o browser vai receber do servidor é uma sequência de bytes.

Para esse pequeno trecho de html disponibilizado pelo servidor:

<!doctype html>
<html>
  <head>
    <title>Um título</title>
  </head>
  <body>
    <a href="#">Um link</a>
    <h1>Um cabeçalho</h1>
  </body>
</html>

O navegador receberia em bytes mais ou menos assim:

3C21646F63747970652068746D6C3E0A3C68746D6C3E0A20203C686561643E0A202020203C7469746C653E556D2074C3AD74756C6F3C2F7469746C653E0A20203C2F686561643E0A20203C626F64793E0A202020203C6120687265663D2223223E556D206C696E6B3C2F613E0A202020203C68313E556D2063616265C3A7616C686F3C2F68313E0A20203C2F626F64793E0A3C2F68746D6C3E

Porém, o navegador não consegue renderizar uma página apenas com essa informação. Para que o nosso layout seja montado, o navegador vai executar alguns passos antes de ter o DOM.

Esses passo são:

Conversão
Tokenização
Lexing

Conversão: Bytes para caracteres

Nessa etapa o navegador lê os dados brutos da rede ou de um disco e os converte para caracteres com base na codificação(encoding) especificada no arquivo, por exemplo, UTF-8.

Basicamente é a etapa em que o navegador transforma bytes para o código no formato que escrevemos no nosso dia a dia.

Tokenização: Caracteres para tokens

Nessa etapa o navegador converte strings de caracteres em pequenas unidades chamadas tokens. Todo início, final de tag e conteúdo são contabilizados, além disso, cada token possui um conjunto de regras específicos.

Por exemplo, a tag <a> possui atributos diferentes da tag <strong>

Sem essa etapa teremos apenas um monte de texto sem significado para o navegador e no fim desse processo o nosso html base seria tokenizado assim:

<!doctype html> ➔ Token: DOCTYPE, Valor: html
<html> ➔ Token: StartTag, Nome: html
<head> ➔ Token: StartTag, Nome: head
<title> ➔ Token: StartTag, Nome: title
Exemplo de título ➔ Token: Character, Dados: Exemplo de título
</title> ➔ Token: EndTag, Nome: title
<p> ➔ Token: StartTag, Nome: p
Olá, mundo! ➔ Token: Character, Dados: Olá, mundo!
</p> ➔ Token: EndTag, Nome: p

Um token é uma palavra ou símbolo individual em um texto. A "tokenização" é o processo de dividir um texto em palavras, frases ou símbolos menores.

Lexing: Tokens para nodes

A etapa de lexing(análise léxica) é responsável por converter os tokens em objetos, mas isso ainda não é o DOM. Nesse momento o navegador está gerando partes isoladas do DOM, onde cada tag será transformada em um objeto com atributos que tragam informações relacionadas a atributos, tags pai, tags filhas, etc.

O resultado após o lexing da nossa tag

seria algo assim:

{
  "type": "Element",
  "tagName": "p",
  "attributes": [],
  "children": [
    {
      "type": "Text",
      "content": "Olá, mundo!"
    }
  ]
}

Construção do DOM: Nodes para DOM

Finalmente chegamos na etapa de construção do DOM!

Nesse momento o navegador vai considerar as relações entre as tags html e vai juntar os nodes em uma estrutura de dados em árvore que represente essas relações de forma hierárquica. Por exemplo: o objeto html é pai do objeto body, o body é pai do objeto paragraph, até que toda a representação do documento seja criada.

Ao fim da construção o nosso html de exemplo se torna uma árvore de objetos como esta:

{
  "type": "Document",
  "children": [
    {
      "type": "Element",
      "tagName": "html",
      "children": [
        {
          "type": "Element",
          "tagName": "head",
          "children": [
            {
              "type": "Element",
              "tagName": "title",
              "children": [
                {
                  "type": "Text",
                  "content": "Exemplo de título"
                }
              ]
            }
          ]
        },
        {
          "type": "Element",
          "tagName": "body",
          "children": [
            {
              "type": "Element",
              "tagName": "p",
              "children": [
                {
                  "type": "Text",
                  "content": "Olá, mundo!"
                }
              ]
            }
          ]
        }
      ]
    }
  ]
}

Recapitulando

O processo para construção do DOM é complexo e acontece nas seguintes etapas:

Conversão: O html é recebido pelo navegador e convertido de bytes para caracteres.
Tokenização: Os caracteres são transformados em tokens que representam as partes do html (tags, atributos, textos).
Lexing: Os tokens são organizados em nós de objetos
DOM: Os objetos são organizados em uma estrutura de dados do tipo árvore de forma hierárquica.

Para o CSSOM também acontece um processo semelhante, composto por conversão, tokenização e lexing.

Conclusão

Você deve estar se perguntando onde você vai aplicar esse conhecimento ao longo do seu dia a dia desenvolvendo...

É verdade que esse tipo de informação não vai ser requisitada com frequência, mas é importante entender como os navegadores, a principal ferramenta de trabalho de frontends, funcionam na sua essência.

Esse conhecimento também vai ser muito valioso para entender os próximos temas que iremos abordar por aqui: Paint, repaint, flow e reflow.

Muito obrigado!!

Obrigado por ter chegado até aqui!

Espero que tenha aprendido algo novo ao longo dessa leitura.

Até a próxima!

Referências

Constructing the Object Model

Desconstruindo a Web: Renderização De Páginas

Entendendo renderização no browser: CSSOM

Cristiano Gonçalves ⛩️ — Fri, 08 Nov 2024 12:10:01 +0000

Hey, esse artigo faz parte de uma série sobre renderização no browser. Se você ainda não leu os artigos passados, da uma conferida nos links abaixo:

Entendendo renderização no browser: DOM

No último artigo, exploramos como o HTML é processado pelo navegador através da DOM (Document Object Model), que define a estrutura da página web. Porém, uma página web não é feita apenas de HTML e algo que muitos ainda não sabem é que o CSS também possui sua própria representação em forma de objeto, chamada CSSOM (CSS Object Model).

O navegador utiliza a CSSOM em conjunto com a DOM para construir a página, combinando estrutura (HTML) e estilos (CSS), resultando em uma apresentação visual harmoniosa.

Neste artigo, vamos aprofundar nosso conhecimento sobre a CSSOM, entendendo sua estrutura, importância e como ela pode ser manipulada.

O que é o CSSOM?

Assim como a DOM, o CSSOM é uma estrutura de dados hierárquica, mas sua função é representar o CSS de um documento web.

O CSSOM é gerado pelos navegadores após o carregamento e processamento dos arquivos de estilo. Embora seja construído separadamente da DOM, ambos trabalham em conjunto para que o navegador possa montar a página com a estrutura correta (DOM) e aplicar os estilos apropriados (CSSOM).

A principal função do CSSOM é fornecer ao navegador um "mapa" detalhado dos estilos que devem ser aplicados a cada elemento da página.

Veja abaixo uma representação visual do CSSOM:

No código essa representação ficaria assim:

body {
  font-size: 16px;
}

div {
  width: 200px;
  height: 100px;
  background: blue;
}

a {
  color: red;
  text-decoration: none;
}

h1 {
  font-weight: bold;
}

E a árvore DOM referente ao CSSOM que vimos anteriormente é representada da seguinte forma:

Manipulando o CSSOM

Os navegadores nos fornecem um conjunto de APIs que permitem a manipulação do CSS utilizando javascript. Ela é semelhante a API do DOM, mas para CSS ao invés de HTML.

Com o uso dessa API nós conseguimos ler e manipular o CSS de uma página de forma dinâmica.

A maneira mais simples de você manipular estilos é por meio da propriedade style presente no document.

Para acessar e manipular um elemento do CSSOM pela primeira vez, abra o console do navegador e execute o seguinte código:

document.body.style.background = "gray";
console.log(document.body.style.background); // gray

Após executar o trecho de código acima recomendo que inspecione os elementos da página e analisem o body. Notem que agora o nosso body tem um estilo inline e vai estar mais ou menos dessa forma:

<body style="background: gray;"></body>

Isso acontece porque alterar a propriedade style de um elemento só tem efeito para estilos inlines.
A mesma lógica se aplica para leitura de propriedades do style. Se você executar o código abaixo não vai ter nenhum retorno, pois nenhum momento definimos a propriedade color usando estilo inline.

console.log(document.body.style.background); // '''

Conseguimos adicionar ou alterar qualquer propriedade CSS da nossa página seguindo sempre o padrão elemento.style.nomeDaProprieda.

Outra forma de manipular os estilos inline são por meio de alguns métodos presentes no style.

setProperty: com esse método você consegue adicionar ou altera o valor de uma propriedade inline.

document.body.style.setProperty("background", "red");

// Agora execute o próximo comando

document.body.style.setProperty("background", "blue");

getPropertyValue: com esse método você consegue acessar o valor de uma propriedade inline.

document.body.style.getPropertyValue("background"); // blue

removeProperty: com esse método você consegue remover uma propriedade inline.

document.body.style.removeProperty("background");

O getComputedStyle funciona apenas para leitura. Você conseguirá acessar a informação sobre estilo de qualquer elemento ou pseudo elemento, mas não conseguirá fazer alterações.

E os estilos que não são inlines?

Escrever estilos inline não é algo muito comum, por isso também conseguimos acessar os estilos computados, aquele que definimos na nossa folha de estilo. Para isso podemos acessar e manipular diretamente nossa folha de estilos.

Execute o trecho de código abaixo no console do seu navegador:

document.styleSheets;

Com ele você vai ter acesso a todas as folhas de estilos declaradas no head do seu html.

Essas folhas de estilos são retornada em formato de lista(parece, mas não é um array) e você pode acessar por meio do índice.

document.styleSheets[1];

Daqui em diante recomendo executar os testes em outro local, pois esse blog é feito com tailwind css e a manipulação da folha de estilo fica mais complicada.

Acesse essa página e execute os comando no console dela.

document.styleSheets[0].cssRules;

Ao executar o código acima você terá acesso a todos o css presentes na folha de estilo. Seguindo a mesma lógica anterior você pode acessar os elementos por meio de índice.

document.styleSheets[0].cssRules[3];

No código acima eu estou acessando a declaração de estilo do body da página.

document.styleSheets[0].cssRules[3].style.background = "red";

Acessando a propriedade style conseguimos adicionar ou alterar qualquer propriedade CSS, mas sem escrever estilos inlines.

Recomendo que brinque um pouco mais com essa api mudando os índices e alterando o CSS de diversos elementos.

Conclusão

Assim como o DOM o CSSOM é uma representação em forma de arvore utilizada pelos navegadores para o processo de renderização.

Podemos acessar todo o CSS da página e manipulá-lo livremente utilizando javascript. Saber executar esse tipo de operação é essencial para compreender ferramentas de CSS como styled componentes, linária etc.

O conhecimento de base é o mais importante, mas é constantemente negligenciado.
No contexto do desenvolvimento web, conhecer html, css, javascript e como o navegador funciona é essencial. Com essa base sólida, você vai conseguir aprender qualquer tecnologia que derive desses fundamentos.

Muito obrigado!!

Obrigado por ter chegado até aqui!

Espero que tenha aprendido algo novo ao longo dessa leitura.

Até a próxima!

Referências

CSS Object Model

Constructing the Object Model

CSSOM — Modelo de Objeto CSS

An Introduction and Guide to the CSS Object Model (CSSOM)

Entendendo renderização no browser: DOM

Cristiano Gonçalves ⛩️ — Thu, 07 Nov 2024 11:50:18 +0000

Conhecer bem a ferramenta com a qual trabalhamos é um passo importante para evoluir em nossa carreira. Já imaginou um eletricista que não entenda como a corrente elétrica funciona? E já pensou em um desenvolvedor front-end que não compreenda como os navegadores funcionam? Pois é, isso é algo muito comum. Pouquíssimos desenvolvedores front-end entendem o processo que o navegador segue para montar uma página. E, apesar de ser um processo simples, ele é muito importante e, infelizmente, ignorado.

Hoje vamos começar uma jornada para entender o processo realizado pelos navegadores cada vez que criamos uma tag HTML, manipulamos algo com JavaScript ou mudamos uma cor com CSS.

O que é renderização?

Quando construímos uma casa, passamos por diversas etapas. Primeiro, fazemos a fundação, depois construímos as paredes, adicionamos o telhado, fazemos o acabamento (reboco, piso etc.) e, por fim, adicionamos os móveis e eletrodomésticos. A construção de um site segue um processo semelhante. Primeiro, criamos a fundação (HTML), depois adicionamos o acabamento (CSS) e, por fim, a interatividade (JavaScript). Em outras palavras, a renderização é o processo pelo qual o navegador transforma o código em algo visual e interativo para o usuário.

O processo de renderização

A renderização de uma página web é um processo complexo, por isso o navegador divide essa renderização em pequenas atividades, como construção do DOM e do CSSOM, paint, repaint, flow e reflow.

São muitos conceitos, porém hoje iremos focar nosso estudo no DOM.

DOM

O DOM (Document Objet Model) é uma representação em forma de estrutura de dados utilizada para representar hierarquicamente um documento html. A palavra hierarquicamente é importante, pois o DOM tem o visual de uma árvore, onde cada elemento é um nó que pode ter filhos que também podem ter filhos. Exatamente como na imagem abaixo:

No código essa representação ficaria assim:

<!doctype html>
<html>
  <head>
    <title>Um título</title>
  </head>
  <body>
    <a href="#">Um link</a>
    <h1>Um cabeçalho</h1>
  </body>
</html>

Os navegadores utilizam essa representação, seguindo os padrões W3C DOM e WHATWG DOM, como um guia para identificar quais elementos devem ser renderizados na tela e qual a hierarquia eles devem seguir.

Estrutura do DOM

O DOM é composto por diversos objetos, são eles: document, nodes, elements, attributes e texto.

Document(documento): Essa é a raiz da nossa árvore, a tag <html>
Node(nó): Cada parte da nossa árvore é um nó. O document é um nó, um elemento é um nó e os filhos desse elemento também é um nó.
Element(elemento): O nó do tipo elemento representa uma tag. A tag <p> é um nó do tipo elemento.
Attribute(atributo): Esse objeto representa o atributo de cada elemento. Class é o atributo da nossa tag div <div class="minha-classe">.
Text(texto): Geralmente esse é o último nível da árvore. O texto que vai ser exibido em tela.

Todos os objetos que compõem o DOM podem ser manipulados utilizando javascript através da api DOM disponível em todos os navegadores modernos.

Manipulando o DOM

No desenvolvimento moderno, com ferramentas como React, Vue ou Angular, a necessidade de manipular diretamente o DOM tem se tornado cada vez mais rara.

Isso ocorre porque cada atualização no DOM é um processo custoso em termos de desempenho. Tecnologias como React foram criadas justamente para otimizar essas operações, permitindo a manipulação eficiente da interface sem sacrificar a performance. No entanto, há cenários específicos em que a manipulação direta do DOM ainda será necessária, e quando esse momento chegar, é importante estar preparado(a).

Para acessar e manipular um elemento do DOM pela primeira vez, abra o console do navegador e execute o seguinte código:

const elemento = document.getElementById("estruturadodom");
elemento.textContent = "Manipulando o DOM";

Na primeira linha buscamos um elemento que tem o id estruturadodom, cada seção do meu blog tem o titulo como id.
Na segunda linha alteramos a propriedade textContent do nosso elemento.

Esse trecho foi para exemplificar, por isso a simplicidade. Grande parte das iterações que você encontra ao longo da internet acontecem por meio de alterações e atualizações do DOM.

Recomendo acessar os sites que você já tem costume e começar a analisar as iterações que acontecem e se possível tente replicá-las. Esse é um ótimo exercício para aumentar sua fluência
em manipulação de DOM.

Conclusão

O DOM é uma representação em forma de arvore utilizada pelos navegadores para o processo de renderização.

Podemos acessar elementos dessa árvore e manipulá-los livremente utilizando javascript. Saber executar esse tipo de operação é essencial para compreender frameworks e bibliotecas como react, angular e vue.

Muito obrigado!!

Obrigado por ter chegado até aqui!

Espero que tenha aprendido algo novo ao longo dessa leitura.

Até a próxima!

Referências

MDN - O que é o DOM

Alura - O que é o DOM

Hostinger - O que é o DOM

Padrões React: Container/Presentational

Cristiano Gonçalves ⛩️ — Wed, 23 Aug 2023 22:44:35 +0000

Fala, galera! Hoje vou começar uma pequena série focada em padrões.

Inicialmente ela vai ser focada em padrões do React, mas futuramente pretendo expandir para padrões de projetos de modo geral.

Um ponto super importante é que antes de tentar aplicar qualquer padrão de código/projeto etc é preciso entender qual problema ele vai resolver. Nunca aplique um padrão(pattern) só por capricho, pois toda escolha técnica é rodeada por prós e contras.

Qual o problema?

Uma das premissas dos frameworks frontends modernos, como o nosso querido react, é componentizar e escrever código com responsabilidades bem definidas. É como as antigas linhas de montagem, onde cada pessoa tem seu papel muito bem definido e essa pessoa é especialista em executar uma única função em diversos cenários. Uma pessoa especialista em apertar parafusos vai conseguir apertar o parafuso de um carro ou de um computador.
Sei que é um exemplo bem abstrato... Mas o grande ponto é entender que a separação de responsabilidades pode e deve ser aplicada na construção das suas aplicações e esse tipo de separação facilita o reaproveitamento.

Depois dessa explicação você nota algum problema ao analisar o código abaixo?



function MusicList() {
  const [musics, setMusics] = useState([]);
  const [loading, setLoading] = useState(false);

  useEffect(() => {}, [
    function getMusics() {
      ... alguma regra de negócio antes de buscar músicas
      setLoading(true);
      fetch("api-de-musicas.com")
        .then(res => res.json())
        .then(res => {
          setMusics(res.musics);
          setLoading(false);
        });
    },
  ]);

  if (props.loading) {
    return <p>Carregando..</p>;
  }
  return (
    <div>
      {props.musics.map(music => (
        <li key={music.id}>
          <h3>{music.name}</h3>
          <h4>{music.artist}</h4>
        </li>
      ))}
    </div>
}

O padrão Container & Presentational

O código acima tem um component que faz mais de uma coisa... ele não é "especialista" em nada. O padrão Container & Presentational tem o objetivo de resolver esse problema, separando lógica e regras de negócios em components do tipo container e interface em components do tipo presentational.

Ainda não entendeu o que diferencia um component container de um component presentational?

Container: Se você precisa exibir uma lista de músicas o component container não vai se preocupar em como você vai exibir, ele vai se preocupa com o que vai ser exibido. A chamada na api para buscar as músicas, o agrupamento das músicas por categoria ou qualquer tipo de tratamento será feito por esse tipo de component.
Presentational: Esse é um component apenas de apresentação, onde seu único objetivo é exibir informações em tela e cuidar das interações com o usuário. No exemplo da lista de músicas esse component vai ser responsável por exibir as músicas em formato de grade ou lista, exibir a capa do album quadrada ou arredondada e tudo que diz respeito a forma que a informação será apresentada, pois esse é um presentational component(component de apresentação).

Vamos reescrever o mesmo trecho de código que vimos anteriormente, mas agora aplicando o padrão que acabamos de aprender.

Exemplo de um component container:



function MusicListContainer() {
  const [musics, setMusics] = useState([]);
  const [loading, setLoading] = useState(false);

  useEffect(() => {}, [
    function getMusics() {
       ... alguma regra de negócio antes de buscar músicas
      setLoading(true);
      fetch("api-de-musicas.com")
        .then(res => res.json())
        .then(res => {
          setMusics(res.musics);
          setLoading(false);
        });
    },
  ]);

  return <MusicList musics={musics} loading={loading} />;
}

Exemplo de um component presentational:



function MusicList(props) {

  if (props.loading) {

    return <p>Carregando..</p>;

  }

  return (

    <div>

      {props.musics.map(music => (

        <li key={music.id}>

          <h3>{music.name}</h3>

          <h4>{music.artist}</h4>

        </li>

      ))}

    </div>

  );

}

O que ganho fazendo isso?

Esse é um padrão bem simples, mas que traz alguns ganhos interessantes, são eles:

Separação das responsabilidades. No exemplo acima ficou bem claro qual component era responsável por cuidar de regras de negócio e qual é responsável apenas por apresentar dados para o usuário.
Reutilização. Nosso component de MusicList pode ser utilizado em diversos cenários em que precisamos exibir músicas. Sejam músicas de resultados de uma busca ou as músicas favoritas de um usuário.
Testabilidade. Testar components de apresentação sem regra de negócio é muito simples, pois precisamos apenas passar props e nos preocupar com o comportamento do component e não com chamadas de api e etc.

Devo utilizar sempre esse padrão?

É importante sempre tentar separar ao máximo as responsabilidades do seu código, porém o padrão Container & Presentational não é algo mais recomendado pela comunidade, pois conseguimos fazer esse mesmo tipo de separação utilizando hooks de uma maneira bem mais elegante.

Mas não se espante se encontrar projetos que ainda utilizem essa abordagem, pois ela resolveu muitos problemas em tempos de components de classes. Apesar de não ser algo que você vai sair aplicando em todos os cenários no seu dia a dia, conhecer como os padrões do react foram evoluindo é essencial para entender como estamos resolvendo os problemas atuais.

Isso é tudo, pessoal!

Fico feliz que você chegou até aqui e espero que tenha aprendido algo novo ao longo dessa leitura. Em breve irei trazer mais artigos abordando outros padrões do react. Até mais!

Referências

Meus erros e aprendizados em 1 ano como Tech Lead

Cristiano Gonçalves ⛩️ — Fri, 05 Aug 2022 21:10:00 +0000

Faz um 1 ano e 3 meses que aceitei oficialmente um desafio para ocupar o cargo de Tech Lead na Zak, uma posição que me preparei bastante para ocupar, ou ao menos achei ter me preparado o suficiente.... Porém, a medida que os dias iam passando, o time ia se estruturando e as situações foram aparecendo, eu percebi que não estava tão preparado como imaginei.

Errei bastante, questionei minha capacidade enquanto líder, tive vontade de desistir, mas também recebi feedbacks de que estava fazendo um bom trabalho. E é por isso que estou confortável em escrever um texto compartilhando alguns dos meus aprendizados, pois esse era o tipo de conteúdo que poderia ter me ajudado no início da minha jornada enquanto líder.

Qual o papel de um Dev e de um Tech Lead?

Antes de falar sobre erros e acertos é preciso entender quais as diferenças entre um Dev e um Tech Lead. De maneira bastante prática o Dev tem um perfil executor e na grande maioria das vezes não possuem dependências. Enquanto um Tech Lead tem a função de liderar uma equipe, conduzindo o time, gerenciando o projeto, mantendo uma boa comunicação com outras equipes da empresa e auxiliando na evolução técnica dos seus liderados.

Agora que você já tem uma ideia básica sobre a diferença entre o dev e tech lead vamos aos principais erros que cometi e aprendizados que tive a medida que fui avançando no dia-a-dia de um líder técnico.

Não delegar

Esse foi um dos meus principais erros e foi algo que custou bastante da minha saúde física e mental... Inicialmente eu não tinha entendido que não estava mais no perfil de executor e segui acumulando atribuições que deveriam ser direcionadas para o time.

Isso me deixou extremamente sobrecarregado e meu desempenho enquanto líder não estava sendo dos melhores, pois não estava focando no time e sim nas tarefas. Além disso, o cansaço físico e mental foram aumentando e não importava o quanto eu dormisse, o cansaço continuava.

As coisas só começaram a fluir quando eu entendi que não iria conseguir fazer tudo sozinho. Que precisava confiar no meu time e que agora o meu papel era o de garantir o sucesso dos meus liderados na execução das tarefas. Inicialmente foi bem difícil virar essa chavinha, pois um dia você é responsável por duas ou três tarefas na sprint e no outro dia você é responsável pelo sucesso de dez ou quinze tarefas de todo o seu time.

Toda sua independência passa a ser uma dependência, pois sem o sucesso do time você não tem sucesso.

Não entender a capacidade do time

Quando me tornei tech lead eu já tinha bastante contexto sobre o projeto e dominava bastante das regras de negócio, por isso, eu tinha facilidade em resolver determinados problemas com mais velocidade que os devs menos experientes do projeto, algo esperado... Porém, sempre que o time tinha alguma dificuldade eu pensava "eu consigo resolver isso rapidinho" e por causa desse pensamento o planejamento do meu time tinha diversos problemas, pois eu planejava para o time pensando estar planejando para mim.

O planejamento do time melhorou expressivamente quando eu entendi que cada pessoa tem um ritmo diferente e que eu precisava entender qual era a velocidade do time independente da minha velocidade de desenvolvimento. E que meu trabalho era buscar soluções para que a eficiência do time aumentasse cada vez mais. Não interessa o quão rápido eu possa resolver o problema e sim o quanto eu posso auxiliar meu time para resolver o problema com a melhor qualidade e velocidade possível.

O papel de um tech lead é entender a capacidade do time e encontrar formas de aumentar a produtividade do mesmo.

Sem um time engajado nada vai funcionar

Existem diversas formas de engajar uma pessoa... não vou me aprofundar nisso, pois cada pessoa é singular e cada time tem uma configuração diferente. Mas enquanto líder, o grande ponto é encontrar uma forma de mostrar o valor do trabalho para seus liderados, pois isso é um dos pontos-chave para manter um time engajado.
Enquanto eu apenas passava tarefas e cobrava sem mostrar o porquê de cada decisão e o impacto que elas traziam para o negócio, o sentimento do time não era dos melhores. Isso mudou quando eles passaram a enxergar o valor das suas entregas e se sentiram mais envolvidas em todo o processo.
Demonstrar esse valor não é uma coisa simples, pois as pessoas têm dificuldade em enxergar valor nas pequenas coisas, porém uma forma de contornar isso é utilizando métricas de forma que o time entenda sua evolução, seus pontos de falhas e suas conquistas sem um ar analítico de julgamento. Dessa forma, as métricas podem ser sua maior aliada no engajamento do time, desde que você as utilize com propósito de dar visibilidade e de conduzi-los do ponto A ao ponto B sempre visando a melhoria constante ao invés do julgamento continuo.

O sentimento de trabalhar em algo que não gera resultados é péssimo, então um líder precisa cuidar para que o time enxergue o real valor de cada detalhe que vocês trabalharem juntos.

Ser transparente é essencial

Desde meu primeiro dia enquanto líder, eu optei por ser bastante transparente com minha equipe. Eles sempre souberam quando as coisas estavam indo bem, quando as coisas não estavam indo bem, quando eu estava muito confiante ou quando eu estava com a confiança baixa. Para alguns isso é algo negativo, pois tem pessoas que acreditam que o líder precisa ser uma figura inabalável, que não demonstra suas inseguranças para o time... em outras palavas, nada humano.

Eu optei pelo caminho da transparência, pois meu time precisa confiar em mim nos momentos bons e nos momentos ruins e isso é algo muito difícil, porem, em 1 ano e 3 meses como Tech Lead, com diversas configurações diferentes de times e com liderados de perfis diferentes, ser transparente foi o que me ajudou construir boas relações e ser uma figura confiável para os meus liderados.

É claro que você precisa ser responsável, consciente e prezar sempre pelo bem-estar do seu time, então podem existir situações em que a transparência pode mais atrapalhar do que ajudar, mas isso não pode ser algo corriqueiro. E até nesse tipo de situação, sempre que possível, é importante ser transparente do porquê você não foi transparente.

Quando você é acessível e transparente com o seu time uma relação de confiança é construida, o que facilita todo o trabalho.

E chegamos ao fim

Esse foi a primeira vez que abordei um conteúdo não técnico... Confesso que foi bem mais difícil de expressar tudo em palavras, mas espero que tenha sido claro e te ajude de alguma forma.

Ao longo da minha jornada eu tive mais erros, aprendizados, frustrações e alegrias no cargo de Tech Lead, mas vou deixar para falar mais sobre em outra ocasião.

Muito obrigado por chegar até aqui e até a próxima!

Minha jornada criando 30 sites em 30 dias

Cristiano Gonçalves ⛩️ — Tue, 02 Aug 2022 00:28:36 +0000

Quem nunca achou uma vaga maneira e pensou em enviar um currículo, mas desistiu por não ter o que mostrar? E quantas vezes alegamos que não tivemos oportunidade de trabalhar com a tecnologia X ou Y?

Muitas vezes damos a desculpa de não ter um portfólio por nunca ter trabalhado, algumas pessoas até alegam que não constroem projetos fictícios por falta de ideias. Pois bem, que bom que temos uma comunidade maravilhosa que está sempre disposta a criar formas de ajudar.

Nesse post eu vou contar um pouco sobre minha jornada com o desafio 30 Days 30 Sites.

Aceitando o desafio

Tudo começou quando descobri a hashtag #100DaysOfCode no twitter, fui navegando de post em post até que cheguei na hashtag #30Days30Sites e descobri esse projeto magnífico, que consiste em enviar um email por dia durante 30 dias com um tema e uma página de exemplo. Depois disso é só colocar a mão na massa e desenvolver.

Novas tecnologias

Um dos pontos fortes desse desafio é a liberdade que é dada para o participante, pois ele nos entrega apenas um tema e deixa todo o resto a nosso critério, essa é uma boa forma de experimentar diversas tecnologias e isso vai nos permitir adquirir um conhecimento prático, coisa que não conseguimos apenas lendo um livro ou fazendo um curso.\
Durante a minha trajetória eu pude trabalhar na prática durante grande parte do desafio com PUG, SASS, GULP e Mobile First. A possibilidade de trabalhar com Mobile First em mais de 20 projetos me deu uma bagagem considerável sobre desenvolvimento responsivo, coisa que antes eu não tinha segurança para desenvolver e sempre ficava buscando algum framework para todas as ocasiões.\
Na reta final eu ainda tive a oportunidade de usar o CSS Grid e consegui bons resultados ao utiliza-lo.

Trabalhando com temas que gosto

Como havia dito anteriormente, o desafio nos possibilita liberdade para construir aquilo que desejamos. Graças a isso pude construir sites de temas que gosto e isso dá uma certa motivação para continuar.

Nem tudo são flores…

O desafio propõe a criação de 30 sites em 30 dias, entretanto nem sempre é possível concluir durante o prazo. Sempre aparecem complicações que acabam atrapalhando o processo, porém não desanime e siga em frente.\
Eu iniciei minha jornada no fim do semestre da faculdade, ou seja, fiz algo muito arriscado… Sempre precisava estudar para alguma prova ou fazer algum trabalho, e isso acabava comprometendo meu progresso com a criação dos sites. Fiquei alguns dias sem codar e teve momentos em que eu tirava 1 ou 2 horas para fazer um site, verificando todos os sites da para perceber quais foram feito nessa situação.

Recebendo e dando feedbacks

~~Todo mundo precisa de um site~~Todo mundo precisa de um feedback! Essa é uma das partes mais importantes do desafio, pois é com ela que encontramos a possibilidade de melhorar e até mesmo forças para continuar. Mas esteja preparado para receber criticas construtivas sobre o seu trabalho, também esteja preparado para não se inflar de orgulho quando receber elogios. Com os feedbacks também temos a oportunidade de conhecer novas pessoas e contribuir com o crescimento delas.

Os feedbacks em geral são dados no Twitter ou por meio do grupo do facebook, onde você simplesmente compartilha seu trabalho e recebe opiniões sobre ele.

Durante os feedbacks, provavelmente você vai precisar explicar como fez determinada parte do site ou como utilizar determinada tecnologia. Isso é muito bom, pois é explicando que se aprende!

Como eu disse logo ali em cima, “Todo mundo precisa de um feedback!”. Outras pessoas também estão fazendo o desafio e você não só pode, mas DEVE, dar feedbacks sobre os trabalhos, seja dando dicas de como melhorar ou simplesmente tirando dúvidas.

Alguns trabalhos

Os temas que recebemos diariamente são bastante diversificados e nos dão a possibilidade de construir sites de vários tipos. Esses são alguns dos que mais curti o resultado.

Você pode conferir todos os trabalhos aqui, onde eu listo as tecnologias que usei em cada site. E pode verificar os códigos no meu github.

Outros dailys

Esse não é o único desafio, existem diversos outros e alguns deles estão listados nesse repositório, da uma olhada que provavelmente vai ter um que se encaixe no que você precisa.

Atualmente eu estou fazendo mais um daily, o dailycssimages. Em breve vou fazer um post sobre ele, mas se quiser ver um pouco dos resultados é só olhar no meu codepen.

Conclusão

Concluir essa jornada não vai me garantir um emprego, mas me garantiu muito conhecimento e crescimento. É claro que os projetos não foram feitos da melhor forma possível e ainda tenho muito a melhorar, mas o importante do desafio é o comprometimento e a busca continua por melhorias.\
Nessa caminhada*o que realmente importa não é o resultado final, mas sim o processo*. A conclusão desse desafio não mostra apenas que sou capaz de construir sites, ela mostra o comprometimento e a vontade de crescimento.

E você? O que está esperando para se desafiar?

Obrigado por ler até aqui!! Se curtiu esse post compartilha com seus amigos e deixa um comentário caso inicie um desafio.