
![](/assets/img/imagem_2024-02-04_202622872.png "Evoluindo na Programação: Lições de um Full Stack")

### **Evoluindo na Programação: Lições de um Full Stack**

Há quase um ano, entrei numa experiência muito divertida no mundo do desenvolvimento, participando ativamente do Dev em Dobro, ajudando no papel de instrutor e mentor. Durante esse período, não apenas compartilhei conhecimentos e esclareci dúvidas, mas também testemunhei o crescimento impressionante de inúmeros alunos, do zero à competência em desenvolvimento web.

Esta jornada reacendeu reflexões sobre meus próprio inicio na programação. Me lembro dos dias em que, sem uma orientação formal, cada linha de código que funcionava era um motivo de celebrar. Essa abordagem "go horse" no código, embora divertida, muitas vezes me deixava à deriva em um mar de práticas questionáveis e dúvidas horrendas.

Refletindo sobre essa trajetória, identifiquei três princípios fundamentais que teriam acelerado meu progresso e refinado minha abordagem ao desenvolvimento desde o início. São lições que transcenderam minha experiência com desenvolvimento. Aqui estão elas:

#### **1. Escrevendo Código para Humanos**

Na programação, a verdadeira arte eu vejo que é escrever código que seja facilmente compreendido por outros desenvolvedores. No início, muitos escrevem código pensando na máquina, performace e etc, mas a realidade é que nosso público principal são os colegas de equipe que vão ler, entender e modificar esse código. Simplificar a complexidade e priorizar a clareza não é apenas uma questão de cortesia profissional, mas uma habilidade essencial na construção de sistemas robustos e colaborativos.

Esse conceito, embora pareça básico, foi uma verdadeira mudança de paradigma para mim. No início, minha visão de programação era puramente técnica: eu via o código como um meio de instruir o computador, focando em como "falar" com a máquina, todo mundo de todos os cursos e trabalho falavam só sobre performance. Mas, com o tempo, percebi algo fundamental que o código é de dev para dev, não de dev para máquina.

A máquina, no final das contas, vai converte tudo em zeros e uns e não tem a menor preocupação com a legibilidade ou a elegância do código. São os nossos colegas que precisam navegar, entender e, muitas vezes, expandir ou corrigir o que escrevemos.

Vamos ilustrar isso com um exemplo prático: a função `groupBy`.

Primeiro se liga:

```javascript
const groupBy = (arr, groupFn) =>
  arr.reduce(
    (grouped, obj) => ({
      ...grouped,
      [groupFn(obj)]: [...(grouped[groupFn(obj)] || []), obj]
    }),
    {}
  )
```

Aqui, demonstramos que podemos condensar operações complexas em uma única linha. Embora isso possa nos fazer sentir mais experientes, na realidade, torna a compreensão do código muito mais difícil para qualquer pessoa que precise revisá-lo.

Agora, considere esta outra implementação:

```javascript
const groupBy = (arr, groupFn) => {
  const grouped = {}
  for (const obj of arr) {
    const groupName = groupFn(obj)
    if (!grouped[groupName]) {
      grouped[groupName] = []
    }
    grouped[groupName].push(obj)
  }
  return grouped
}
```

Esse código pode ser lido de cima para baixo, e é possível entender instantaneamente o que acontece em cada linha. Ele pode não ter a mesma "elegância" da versão anterior, mas sua legibilidade é imensamente superior. E é justamente isso que valorizamos: um código que qualquer pessoa na equipe possa revisitar no futuro e agradecer pela clareza.

Esse princípio de priorizar a legibilidade não só facilita a manutenção do código como também promove uma cultura de colaboração e aprendizado contínuo entre os desenvolvedores. Portanto, da próxima vez que você se sentar para codar, lembre de que está escrevendo para humanos, não para máquinas.

#### **2. Escondendo Informações Atrás das Cortinas**

Uma das maiores revelações que tive foi a eficácia de abstrair detalhes complexos por trás de funções claras e bem definidas. Isso não apenas melhora a legibilidade do código, mas também sua modularidade. Ao encapsular operações complexas, facilitamos a manutenção e incentivamos a reutilização do código.

Minha passagem pelo Dev em Dobro foi mais do que apenas um período de ensino; foi um lembrete constante do poder da educação contínua e do compartilhamento de conhecimento. Ver desenvolvedores emergentes abraçando esses princípios e aplicando-os em seus projetos reforça a crença de que, independentemente de onde começamos, o crescimento contínuo é sempre possível.

Espero que compartilhando essas lições, possa inspirar outros a refletirem sobre suas práticas de codificação e a buscarem sempre a evolução. Afinal, o desenvolvimento de software é uma jornada sem fim, repleta de aprendizados constantes e oportunidades de melhorar não apenas nossos códigos, mas também a nós mesmos como profissionais e mentores.

Para quem já mexeu com React, os hooks são um exemplo perfeito desse princípio:

```javascript
import React, { useState, useEffect } from "react"

function FriendListItem(props) {
  const [isOnline, setIsOnline] = useState(null)

  useEffect(() => {
    function handleStatusChange(status) {
      setIsOnline(status.isOnline)
    }

    ChatAPI.subscribeToFriendStatus(props.friend.id, handleStatusChange)
    return () => {
      ChatAPI.unsubscribeFromFriendStatus(props.friend.id, handleStatusChange)
    }
  })

  return (
    <li style={{ color: isOnline ? "green" : "black" }}>{props.friend.name}</li>
  )
}
```

Nesse caso, temos um componente que mostra um item de lista com a cor dinâmica baseada no status do amigo. Apesar de funcionar direitinho, esse código esconde dentro dele lógicas que não têm muito a ver com o propósito principal do componente `FriendListItem`.

Se a gente pegar essa lógica e criar um hook customizado chamado `useFriendStatus`, dá para simplificar o componente assim:

```javascript
import React, { useState, useEffect } from "react"

function FriendListItem(props) {
  const isOnline = useFriendStatus(props.friend.id)

  return (
    <li style={{ color: isOnline ? "green" : "black" }}>{props.friend.name}</li>
  )
}
```

Isso traz dois benefícios bem legais:

1. A gente pode reutilizar a lógica do `useFriendStatus` em outros lugares.
2. Simplificamos nosso componente para mostrar apenas o que realmente importa para sua funcionalidade.

Falando de um jeito mais amplo, o princípio de esconder informações é sobre colocar detalhes irrelevantes para trás de funções abstratas. Assim, a gente não precisa se preocupar com os detalhes de implementação dentro da função abstrata - podemos focar mais no que ela faz, ou seja, no nome da função que indica seu propósito.

Dessa forma, o código fica mais limpo, fácil de entender e manter, liberando mais tempo para a gente focar na solução dos problemas em vez de decifrar o que cada pedaço do código está fazendo.

#### **3. “Return Early” em Vez de Usar Coisas Aninhadas**

A ultima dica tem a ver especialmente com lidar com validações em rotas de API, é tentador cair na armadilha das condições aninhadas. O padrão "retorne cedo" simplifica a lógica, evitando a complexidade e melhorando a legibilidade do código. Adotar essa prática não só torna o código mais limpo, mas também facilita sua manutenção a longo prazo.

Veja só como geralmente a coisa começa:

```javascript
export const handler = async (req, res) => {
  if (req.method === "POST" || req.method === "OPTIONS") {
    const email = validateEmail(req.body.email)
    if (email) {
      const user = findUserByEmail(email)
      if (user) {
        return res.status(200).json({ user })
      } else {
        return res.status(404).json({ message: "Usuário não encontrado" })
      }
    } else {
      return res.status(422).json({ message: "Faltou o email" })
    }
  } else {
    return res.status(405).json({ message: "Esse método não rola" })
  }
}
```

Esse código pode não estar super complexo, mas já começa a ficar um pouco enrolado. O grande truque aqui é que, em vez de seguir uma linha reta, parece que a gente tá fazendo zig-zag pra entender o fluxo.

Agora, que tal a gente tentar um jeito diferente de escrever isso, utilizando o que chamamos de "Padrão de Retorno Antecipado"? Esse padrão ajuda a cortar o caminho quando algo não está nos conformes, deixando o fluxo mais lógico e direto.

Olha só como poderia ficar:

```javascript
export const handler = async (req, res) => {
  if (req.method !== "POST" && req.method !== "OPTIONS") {
    return res.status(405).json({ message: "Esse método não rola" })
  }

  const email = validateEmail(req.body.email)
  if (!email) {
    return res.status(422).json({ message: "Faltou o email" })
  }

  const user = findUserByEmail(email)
  if (!user) {
    return res.status(404).json({ message: "Usuário não encontrado" })
  }

  return res.status(200).json({ user })
}
```

Dessa forma, o código fica mais limpo e a gente consegue entender o que tá acontecendo passo a passo, de uma maneira bem mais tranquila. Ao invés de um monte de condicionais aninhados, a gente vai direto ao ponto e trata cada caso separadamente, deixando o caminho livre até chegar no resultado que a gente quer lá no final.

---

E﻿spero que essas dicas tenham sido úteis e que essas pequenas dicas te engrandeçam na sua jornada de estudos


Sabe quando você começa a codar e só quer que as coisas funcionem? Pois é, mas aí você descobre que rola fazer isso de um jeito bem mais top. Tem três coisas que, se você começar a usar agora, vão dar um up no seu código rapidinho.

3 Técnicas Pessoais Que Transformaram Minha Carreira em Desenvolvimento

<p>Objetos em JavaScript não são iteráveis como vetores ou cadeias de caracteres (não é possível percorrê-los com loops). Isso significa que você não pode aplicar diretamente <code>filter()</code>, o método de laço for, ou qualquer outro método de iteração em um objeto. Então, como se pode filtrar um objeto em JavaScript?</p>
<p>Isso é possível ao transformar o objeto em um vetor utilizando um dos métodos estáticos de objeto, tais como <code>Object.keys()</code>, <code>Object.values()</code> ou <code>Object.entries()</code>. Posteriormente, você pode empregar o método filter() para realizar a filtragem no vetor e gerar um novo vetor com os elementos que passaram pelo filtro.</p>
<p>Imagine que você possui um objeto que armazena detalhes de usuários, como nome, idade e profissão. Esses métodos estáticos de objeto têm a capacidade de retornar as chaves, os valores ou cada par de chave-valor na forma de um vetor.</p>
<pre><code class="language-javascript">const detalhesDoUsuario = {
  primeiroNome: "Lucas",
  sobrenome: "Kaique",
  nomeDeUsuario: "lucaoskaique",
  email: "me@lucaskaique.com.br",
  empresa: "Example Inc.",
  endereco: "1234 Exemplo",
  idade: 29,
  passatempo: "DJ"
}

let arrayDeChaves = Object.keys(detalhesDoUsuario)

console.log(arrayDeChaves)
</code></pre>
<p>Isso exibirá um vetor com as chaves do objeto:</p>
<p><code>['primeiroNome', 'sobrenome', 'nomeDeUsuario', 'email', 'empresa', 'endereco', 'idade', 'passatempo']</code>
Agora você pode empregar o método <code>filter()</code> para navegar pelo vetor e criar um novo vetor com os elementos filtrados:</p>
<pre><code class="language-javascript">let chavesFiltradas = arrayDeChaves.filter((chave) => chave.length > 5)

console.log(chavesFiltradas)
</code></pre>
<p>Isso resultará em um vetor de chaves cujo tamanho é superior a 5:</p>
<p><code>['primeiroNome', 'sobrenome', 'nomeDeUsuario', 'empresa', 'endereco', 'passatempo']</code>
No entanto, certamente você desejará realizar uma operação de filtragem mais significativa. Por exemplo, você pode querer filtrar pares de chave-valor do objeto que incluem um nome de um objeto extenso. Para isso, primeiramente obtenha as chaves, filtre-as e depois utilize o método reduce() para converter as chaves filtradas em um objeto com as chaves filtradas e seus respectivos valores:</p>
<pre><code class="language-javascript">const detalhesDoUsuario = {
  primeiroNome: "Lucas",
  sobrenome: "Kaique",
  nomeDeUsuario: "lucaoskaique",
  email: "me@lucaskaique.com.br",
  empresa: "Example Inc.",
  endereco: "1234 Exemplo",
  idade: 29,
  passatempo: "DJ"
}

const nomesDeUsuario = Object.keys(detalhesDoUsuario)
  .filter((chave) => chave.includes("Nome"))
  .reduce((objeto, chave) => {
    return Object.assign(objeto, {
      [chave]: detalhesDoUsuario[chave]
    })
  }, {})

console.log(nomesDeUsuario)
</code></pre>
<p>Isso resultará em um objeto com as chaves filtradas e seus respectivos valores:</p>
<pre><code class="language-json">{
  "primeiroNome": "Lucas",
  "sobrenome": "Kaique",
  "nomeDeUsuario": "lucaoskaique"
}
</code></pre>
<h3 id="user-content-em-síntese"><a href="#em-s%C3%ADntese">Em síntese</a></h3>
<p>Você aprendeu a filtrar um objeto em JavaScript convertendo ele em um array utilizando o método <code>filter()</code>.</p>
<p>Fonte
<a href="https://www.freecodecamp.org/news/filter-arrays-in-javascript/">https://www.freecodecamp.org/news/filter-arrays-in-javascript/</a></p>


Infelizmente, os objetos JavaScript não possuem uma função filter(). Mas isso não significa que você não pode usar filter() para filtrar objetos, você só precisa ser capaz de iterar sobre um objeto e convertê-lo em um array usando Object.entries().

Como Filtrar um Objeto no JavaScript


Uma vez que se decide avançar com o aprendizado do **React**, hooks estão entre as primeiras coisas a aprender (e se frustrar). Hooks são partes essenciais do **React**, já que foram criados para resolver vários problemas que apareceram nas primeiras versões do **React**, quando todo o render era feito dentro das funções do ciclo de vida do componente, como **componentDidMount()**, **componentWillMount()**, **componentDidUpdate()**.

Dito isso, os primeiros hooks que todos começam a usar são **useState()** e **useEffect()**. O primeiro é usado para gerenciamento de estado e controle de quando o componente deve ser renderizado novamente, enquanto o segundo se comporta de forma um tanto semelhante às funções do ciclo de vida mencionadas acima.

O hook **useEffect()** pode receber dois parâmetros: o primeiro é uma função de retorno de chamada, enquanto o segundo é opcional e define quando esse hook deve ser chamado.

```javascript
  useEffect((prevProps) => { // prevProps são opcionais e têm alguns usos específicos. Compare com o que acontece com as funções do ciclo de vida.
    // Conteúdo da função personalizada…
    conteúdo da função personalizada…

    return () => {
      // Código para executar quando o componente é desmontado ou quando as dependências mudam
      // Ajuda a evitar vazamentos de memória e comportamento inesperado
    };
  }, [dependências em forma de array]);
```

Um ponto que confunde muitos iniciantes é como o segundo parâmetro funciona. Aqui está um resumo:

> Caso A: Se nada for adicionado, então **useEffect** será executado a cada mudança de estado dentro do componente atual.
>
> _Caso B: Se um array vazio for adicionado (\[]), então o **useEffect** será executado apenas uma vez quando o componente for montado._
>
> _Caso C: Se algum array for fornecido (\[estado]), então **useEffect** será executado toda vez que o estado mudar._
>
> _Caso D: Se algum array for fornecido (\[estado1, estado2, …], **useEffect** será executado toda vez que **QUALQUER** um desses estados mudar._

Agora que revisamos como o **useEffect** funciona, é essencial aprofundar-se em uma técnica de otimização conhecida como _memoização_. _Memoização_ ajuda a prevenir renderizações desnecessárias e pode melhorar significativamente o desempenho dos seus componentes, especialmente ao lidar com arrays de dependências no **useEffect**.

A ideia principal do hook **useEffect** é sincronizar a transferência de dados com **APIs** externas ou outro sistema, como quando você está acessando um banco de dados ou esperando que uma requisição **HTTP** seja completada. O problema é que tendemos a usar esse hook em toda situação possível dentro do nosso código, especialmente nos _Casos A_ e C mencionados acima, e o código pode se tornar incrivelmente ilegível com apenas algumas linhas de código, incluindo disparar um loop se você mudar um dos estados no array de dependências durante o processo.

Isso também pode tornar seu código ineficiente, já que o useEffect funciona como se você estivesse se afastando para executar algum código e depois voltando para a thread principal. Isso poderia ser mais eficiente.

Ótimo, agora você sabe que, às vezes, **useEffect** não é a melhor solução. Agora vamos olhar cada caso em detalhe.

Vamos falar sobre cada um dos casos de uso em detalhe:

> Caso A — Sem array de dependência: Este deve ser abolido do seu código, pois certamente disparará cálculos desnecessários toda vez que um estado mudar. Neste caso, você deve especificar quais estados realmente devem disparar essa função usando um array de dependências.
>
> _Caso B — Array de dependência vazio: Este é um dos bons, a única recomendação que posso fornecer é manter apenas um destes para cada componente e envolver seu conteúdo em uma função._
>
> _Caso C — Apenas um estado de dependência. Está ok usar se você está processando dados externos. Caso contrário, você deve mudá-lo para a solução que irei fornecer abaixo._
>
> _Caso C_ — Múltiplos estados de dependência no mesmo **useEffect**. Este é o que considero o mais problemático. Recomendo que você tente desembaraçar os estados em diferentes hooks useEffect antes de qualquer coisa, pois isso torna seu código muito ilegível.

Agora para a solução que prometi. Vamos considerar estes dois Componentes (Pai e Filho):

```javascript
// ParentComponent.js
import React, { useState, useEffect } from 'react';
import ChildComponent from './ChildComponent';

function ParentComponent() {
  const [contagem, setContagem] = useState(0);
  const [mensagem, setMensagem] = useState('Olá do Pai!');

useEffect(() => {
 setMensagem(`Botão clicado ${contagem} vezes!`);
},[contagem]}

  return (
      <ChildComponent contagem={contagem} mensagem={mensagem} setContagem={setContagem} />
  );
}

export default ParentComponent;

// ChildComponent.js
import React from 'react';

function ChildComponent({ contagem, mensagem, setContagem }) {
  return (
    <div>
      <h3>Componente Filho</h3>
      <p>Contagem recebida do Pai: {contagem}</p>
      <p>Mensagem recebida do Pai: {mensagem}</p>
      <button onClick={() => {setContagem(contagem+1)}>Clique em mim</button>
    </div>
  );
}

export default ChildComponent;
```

Agora vamos explicar o que está acontecendo aqui:

> 1 — Uma vez que o usuário clica no botão no Componente Filho, mudamos o estado "contagem" incrementando 1. Isso levará um ciclo de renderização para acontecer e mudar o estado.
>
> _2 — Uma vez que o estado "contagem" muda, o componente filho será renderizado novamente e também disparará o hook **useEffect** em ambos os componentes, o que disparará a mudança no estado "mensagem". Novamente, isso só acontecerá no próximo render._
>
> _3 — Quando o estado "mensagem" muda, então outra renderização acontece nos componentes mudando a mensagem._
>
> _Neste caso, acabamos tendo duas renderizações. Pode não parecer muito, mas pode crescer em grande escala uma vez que você tem mais estados em jogo._
>
> _Agora veja o que acontece quando fazemos as seguintes mudanças nos componentes:_

```javascript
// ParentComponent.js
import React, { useState } from 'react';
import ChildComponent from './ChildComponent';

function ParentComponent() {
  const [contagem, setContagem] = useState(0);
  const [mensagem, setMensagem] = useState('Olá do Pai!');
const incrementarContagem = () => {
 setContagem(contagem + 1);
setMensagem(`Botão clicado ${contagem + 1} vezes!`);
}

  return (
      <ChildComponent contagem={contagem} mensagem={mensagem}
        callbackFunction={incrementarContagem} />
  );
}

export default ParentComponent;

// ChildComponent.js
import React from 'react';

function ChildComponent({ contagem, mensagem, callbackFunction }) {
  return (
    <div>
      <h3>Componente Filho</h3>
      <p>Contagem recebida do Pai: {contagem}</p>
      <p>Mensagem recebida do Pai: {mensagem}</p>
      <button onClick={callbackFunction}>Clique em mim</button>
    </div>
  );
}

export default ChildComponent;
```

Mudamos o código para passar uma **Função de Retorno de Chamada** para o Componente Filho. Você pode notar que:

> - Não temos mais um useEffect definido no Componente Pai. Isso torna o código mais fácil de ler, já que podemos entender nosso código como, digamos, mais linear e de um único thread do que o original.
> - _Não precisamos esperar dois ciclos de renderização para exibir nossa mensagem final, ou pior, renderizar ambos os componentes duas vezes._
> - _Podemos separar preocupações entre componentes, tornando-os mais reutilizáveis e mais fáceis de ler ou adaptar, já que podemos colocar o que quisermos na função de retorno de chamada._
> - _Ambos os estados mudam ao mesmo tempo, evitando o encadeamento de declarações **useEffect**._

Em conclusão, os insights fornecidos aqui oferecem orientação valiosa, mas é importante reconhecer que desenvolvimento de software é uma área dinâmica, e as soluções serão sempre as mesmas para sempre. O hook useEffect é uma parte importante do React, mas nem sempre é a melhor solução.

Obrigado pela leitura!

T﻿ranslated from \[[https://blog.stackademic.com/why-you-should-avoid-using-useeffect-hook-in-react-and-what-to-do-instead-740660e33420]](https://blog.stackademic.com/why-you-should-avoid-using-useeffect-hook-in-react-and-what-to-do-instead-740660e33420)


React: Você está Usando useEffect() Errado, Faça Isso em Vez Disso