DEV Community: Matheus Castiglioni

Lei De Conway

Matheus Castiglioni — Fri, 09 Apr 2021 13:27:14 +0000

Construir softwares é algo que já fazemos há muito tempo e é algo ainda dificil e complexo de ser feito. Isso porque variaveis e contextos sempre mudam, assim como uma solução para o desenvolvimento de um aplicativo pode não dar certo para o desenvolvimento de um site ou a arquitetura para uma empresa de vinte anos pode não dar certo para uma empresa de seis meses.

Dessa forma por mais que a construção e desenvolvimento de softwares sejam assuntos relacionados à tecnologia, eles não são exatos e nenhum pouco binário, muito pelo contrário, são temas em constante mudança, evolução e aprendizados.

Um dos problemas que em algum momento vamos nos deparar é como estruturar nossos times de tecnologia e como isso vai afetar a arquitetura do nosso sistema ou produto em construção.

A lei de Conway

Em Abril de 1968, Melvin Conway declarou uma frase no artigo http://www.melconway.com/Home/Committees_Paper.html submetido à Harvar Business Review, que logo depois também foi citada por Fred Brooks em seu livro The Mythical Man Month onde foi apelidada de "Conway's law".

Conway introduziu o seguinte conceito:

Organizações que projetam sistemas são obrigadas a produzir projetos que são cópias das estruturas de comunicação dessas organizações

Por exemplo: Imagine que você precise criar um novo compilador, se durante o desenvolvimento desse novo compilador haver quatro grupos de pessoas trabalhando no mesmo, então, no final você irá obter um compilador de quatro passos.

Um outro exemplo seria quando utilizamos uma arquitetura em camadas (layered architecture), onde o time é separado por funções (camada do usuário, regra de negócio, armazenamento e por ai vai...), resolver problemas comuns que cortam verticalmente as camadas aumenta a sobrecarga de coordenação.

E por fim um ultimo exemplo mais real seria quando a gente precisa mudar um contrato entre dois serviços, onde o sucesso pode ser dificil dado a necessidade de coordenar e combinar essa mudança quando ambos os serviços são lidados por times diferentes.

Dessa forma podemos definir a lei de Conway:

A lei de Conway é um ditado que afirma que as organizações projetam sistemas que refletem sua própria estrutura de comunicação

Estrutura organizacional refletida em sistemas

Bem, se há um departamento de faturas, então haverá um sistema de faturas. Da mesma forma que se há um departamento financeiro, então também haverá um sistema financeiro.

Esses sistemas irão se integrar de uma forma que seja o espelho de como esses departamentos se comunicam, ou seja, a arquitetura desses sistemas irão refletir a estrutura de comunicação dos times que fazem parte do processo.

Então como resultado se o departamento de tecnologia é dividido em silos de capacidades técnicas, ou seja, um grupo focado na interface do usuário, outro focado no banco de dados, outro focado na infraestrutura e um último focado na API. Dessa forma a arquitetura final do sistema será muito próxima à esse estilo de comunicação:

Essa separação também é conhecida como habilidades funcionais, onde:

Interface do usuário: Pessoas desenvolvedoras front-end.
API: Pessoas desenvolvedoras back-end.
Banco de dados: Pessoas DBA's.
Infraestrutura: Pessoas responsáveis por soluções em cloud.

E qual o problema disso?

O problema de silos

Um dos problemas quando temos silos agrupados em capacidades técnicas é que sistemas são dinâmicos, sempre haverão mudanças e essas mudanças são conduzidas por N razões. Dessa forma quando houver alguma necessidade de mudança, vai ser necessário trabalho, orçamento e tempo de todos os grupos envolvidos.

Dessa forma Conway nos avisa:

Arquitetos de software devem prestar atenção não apenas para a arquitetura e design do software, mas, também para questões que envolvam: delegações, atribuições e coordenações de trabalhos entre times.

Em próximos post's iremos dar uma olhada sobre como podemos tentar resolver esse problema, ganhando eficiência, performance, tempo e orçamento quando mudanças precisam ocorrer, além de simplificar a necessidade de comunicação e sincronização do trabalho à ser feito.

Conclusão

Nesse post vimos que existe uma tendencia em projetar arquiteturas de sistemas cuja a integração final será muito próxima da forma como é a estrutura de comunicação da empresa.

Abraços, até a próxima.

Originally published at https://blog.matheuscastiglioni.com.br on March 10, 2021.

Porque Variáveis e Funções Podem ser Acessadas Antes da Declaração

Matheus Castiglioni — Wed, 18 Mar 2020 23:03:48 +0000

Uma das linguagens mais utilizadas e famosas atualmente sem dúvida é o JavaScript, hoje em dia o mesmo está em todos os lugares, podemos criar aplicações e sistemas web, desenvolver API's no back-end e criar aplicativos móveis.

Apesar da popularidade, muitas pessoas não gostam do JavaScript, principalmente por algumas particularidades da linguagem ser bem diferente de outras.

Uma das coisas que me confundia quando eu comecei a utilizar o JavaScript era a possibilidade de utilizar variáveis ou funções antes de suas declarações e acredito que muitas pessoas também acham isso um tanto quanto estranho.

Nesse post vou tentar explicar como isso é possível.

Contexto de execução (context execution)

Antes de falarmos sobre variáveis e funções, precisamos entender alguns pequenos conceitos referente a linguagem JavaScript, o primeiro deles será context execution (contexto de execução).

Em JavaScript uma unidade fundamental de execução são as funções, nós usamos elas a todo momento, para calcular alguma coisa, performar efeitos colaterais (como mudar a UI), reutilização de códigos ou para tornar os códigos mais faceis de se entender. Também sabemos que uma função pode chamar outra função, que por sua vez pode chamar outra função e por ai vai...

Quando uma função chama outra, a execução dos códigos precisam voltar para a posição de onde ela havia sido chamada, ou seja:

const ola = nome => {
    console.log(nome)
}

const conversa = () => {
    ola('Matheus')
}

conversa()

Ao chamar a função conversa vamos chamar uma outra função (no caso ola), quando a função ola for executada, precisamos voltar para onde ela foi chamada, ou seja, para dentro da função conversa e continuar a execução.

Mas, você já se perguntou como as engines do JavaScript mantém rastreado todas essas funções em execução e retornando para posições específicas do código?

Em JavaScript existem dois principais tipos de código: Global e função.

Códigos globais (global code)

Esses códigos são definidos fora de todas as funções, ou seja, eles ficam soltos em nosso JavaScript.

Códigos de função (function code)

Esses códigos são definidos dentro de funções.

Quando nossos códigos estão sendo executados pelos motores (engines) JavaScript, cada declaração é executada sobre um certo contexto de execução (execution context) e como nós temos dois tipos de códigos, nos também temos dois tipos de contextos: Contextos de execução global (Global execution context) e Contexto de execução de função (function execution context).

A diferença mais significante entre eles é que existe apenas um contexto de execução global, ele é criado quando o JavaScript começa sua execução. Enquanto para cada invocação de função é criado um novo contexto de execução de funções.

Dessa maneira, é através desses contextos que o JavaScript consegue lidar com pausas, execuções e retornos.

Sabemos que o JavaScript é baseado em um modelo de execução single thread, ou seja, apenas um pedaço de código pode ser executado por vez. Sendo assim, toda vez que uma função é invocada, o contexto de execução atual é pausado e um novo contexto de execução de função é criado, do qual o código será avaliado. Depois que a função executou sua tarefa, ou seja, seus códigos foram executados, o contexto de execução dessa função geralmente é descartado e o contexto de execução anterior é restaurado.

Então é necessário manter ambos contextos rastreados, ou seja, precisamos de um contexto de execução em execução e outro contexto que está pausado.

O jeito mais facil de implementar essa funcionalidade seria através de stacks (pilhas), chamadas de execution context stack (pilha de contexto de execução).

Olhando nosso código de exemplo novamente:

// uma função que loga um nome
const ola = nome => {
    console.log(nome)
}

// uma função que chama outra função
const conversa = () => {
    ola('Matheus')
}

// uma chamada de função no código global
conversa()

Podemos exemplificar os contextos de execução da seguinte maneira:

Ambiente lexical (lexical environment)

Agora que entendemos um pouco mais sobre como funciona os contextos de execução, vamos dar uma olhada no lexical environment (ambiente lexical).

Considere o seguinte exemplo:

const nome = 'Matheus'
console.log(nome)

Nesse caso, sabemos que ao chamar a função log um novo contexto de execução será criado, mas, como a função log recebe o valor da variável nome? Esse processo se chama identifier resolution (resolução do identificador), basicamente a ideia é descobrir a qual variável um determinado identificador se refere, o contexto de execução faz isso através dos lexical environment.

Um lexical environment é um mecanismo interno do JavaScript para acompanhar o mapeamento de identificadores para variáveis específicas, voltando ao código anterior:

const nome = 'Matheus'
console.log(nome)

O lexical environment é consultado quando a variável nome é acessada, ou seja, na declaração do console.log.

Ambientes lexicals são uma implementação interna do mecanimo de escopos do JavaScript e geralmente as pessoas se referem à eles como escopos (scopes)

Geralmente um lexical environment é associado com uma estrutura de código específica, ele pode ser associado para uma função, bloco de código ou um catch (parte de try/catch) e cada estrutura pode ter seu próprio mapeamento de identificadores.

Tipos de variáveis em JavaScript

Em JavaScript podemos utilizar três palavras reservadas para definir variáveis: var, let e const. Elas se diferenciam em dois aspectos: mutabilidade e o relacionamento delas com o lexical environment.

Mutabilidade

Se categorizarmos a declaração de variável pelo aspecto mutabilidade, podemos colocar const de um lado e var/let do outro.

Todas as variáveis definidas com const são imutáveis, ou seja, o valor delas pode ser setado apenas uma vez.

Por outro lado, todas as variáveis definidas com var ou let podem ter seus valores mudados quantas vezes for necessário.

Lexical environment

Os três tipos de definição de variáveis (var, let e const) também podem ser categorizadas pelo relacionamento delas com o lexical environment (pelo escopo delas), podemos colocar var de um lado e let/const do outro.

Usando var

Quando nós usamos o tipo de definição var, a variável é definida na função mais próxima ou no ambiente lexical global (blocos são ignorados). Vamos dar uma olhada no seguinte exemplo:

// define uma variável global
var nome = 'Matheus'

const ola = () => {
    // define uma variável de função local
    var mensagem = 'Olá'
    for (var i = 0; i < 4; i++) {
        // define uma variável no for
        // dentro do loop podemos acessar variáveis de bloco, variáveis de função e variáveis globais
        var texto = mensagem + ' ' + nome
        console.log(texto)
    }
    // Variáveis do for também são acessíveis de fora do loop
    console.log(texto)
}

ola()

O que pode ser estranho com JavaScript e confunde bastante pessoas vindo de outras linguagens, é que nós podemos acessar variáveis definidas em códigos de bloco fora desses blocos.

Isso ocorre porque quando declaramos variáveis com a palavra reservada var elas sempre são registradas na função mais próxima ou no ambiente lexical global, sem se importar com escopos de bloco.

A ideia seria mais ou menos essa:

Repare que existem três lexical environments, um global, outro para a função ola e um para o for.

Usando let e const

Por conta desse comportamento um tanto quanto estranho, na versão ES6 do JavaScript foram adicionados dois novos tipos de declaração de variável let e const.

Diferente de var, eles definem as variáveis no lexical environment mais próximo (pode ser um bloco, um loop, uma função ou global).

Realizando algumas modificações no código anterior:

const nome = 'Matheus'

const ola = () => {
    const mensagem = 'Olá'
    for (let i = 0; i < 4; i++) {
        let texto = mensagem + ' ' + nome
        console.log(texto)
    }
}

ola()

A ideia seria mais ou menos essa:

Registrando identificadores com lexical environment

Um dos princípios da linguagem JavaScript é ser facil de usar, por isso, que não especificamos tipos de retornos em funções, tipos de parâmetros, tipos de variáveis, e por ai vai... E você já sabe que códigos JavaScript são executados linha por linha, vamos dar uma olhada no seguinte exemplo:

ola('Matheus')

function ola(nome) {
    console.log('Olá', nome)
}

Se os códigos são executados linha por linha, como podemos chamar a função ola antes de sua declaração? A execução do código JavaScript ocorre em duas fases:

A primeira fase é ativada sempre que um novo lexical environment é criado, nessa fase nenhum código é executado, mas, a engine do JavaScript visita e registra todas as variáveis e funções declaradas dentro do lexical environment atual.
Na segunda fase, ocorre execução do JavaScript depois que a primeira foi realizada, esse comportamento depende do tipo de declaração de variável (var, let e const) e o tipo de ambiente (global, função ou bloco).

O processo seria mais ou menos assim:

Se nós estamos criando um ambiente de função, o identificador implícito arguments é criado, junto com todos os outros parâmetros da função. Se não estamos lidando com um ambiente de função, esse passo é pulado.
Se nós estamos criando um global ou ambiente de função, o código atual é escaneado (sem entrar no corpo das funções) para funções de declaração (não para funções de expressão ou funções de flecha).
O código atual é escaneado para declarações de viariáveis com a palavra reservada var e definidas fora de outras funções.

Vamos olhar outro exemplo:

console.log(nome)

var nome = 'Matheus'

Nesse exemplo será logado undefined em nosso console, isso porque o primeiro passo será escanear e registrar o identificador para cada variável com o valor inicial undefined. O valor da variável será setado na segunda quando a execução dos códigos forem realmentes feitas.

Isso é porque variáveis do tipo var podem ter seus valores igual à undefined e serem acessadas antes de sua declaração.

Obs: Caso as variáveis fossem definidas com let ou const o JavaScript vai lançar um ReferenceError informando que não podemos acessar variáveis antes de sua declaração.

Conclusão

Nesse post vimos porque variáveis do tipo var podem ser acessadas antes de suas declarações e como funções de declaração podem ser chamadas antes de suas definições.

Também vimos alguns conceitos interessantes sobre JavaScript como: execution contexts, lexical environments, scopes, identifier resolution e identifiers.

Se você gostou desse post e quer ser notificado com novos post's, não deixe de assinar a newsletter e receber as novidades por email.

Até a próxima.

Referência:

Livro: Secrets of the JavaScript Ninja

Publicado originalmente em https://blog.matheuscastiglioni.com.br

Diminuindo Processamento com useMemo em React

Matheus Castiglioni — Wed, 04 Mar 2020 13:13:54 +0000

Cada vez mais nossos usuários exigem que os sistemas sejam mais rápidos e infelizmente algumas vezes deixamos passar pequenos detalhes que podem fazer toda diferença em ambientes de produção. Podemos adicionar toda regra para realizar lazy loading, code splitting, cache, aplicar técnias de performance, etc...

Mas, um detalhe muito importante é a quantidade de processamento que nossos componentes estão realizando, será que eles só processam aquilo que é necessário? Para exemplificar o problema, vamos começar criando um novo projeto em React:

create-react-app post-utilizando-use-memo

Obs: Sim, eu ainda prefiro utilizar o CRA instalado localmente na minha máquina.

Aguarde todo processo de download e configuração finalizar.

Uma vez que tudo terminou, podemos acessar nosso projeto:

cd post-utilizando-use-memo

E subir o servidor de desenvolvimento:

npm start

Com isso temos uma aplicação padrão do React rodando:

Vamos adicionar algumas funcionalidades:

Implementar um contador que poderá ser decrementado ou incrementado.
Implementar um botão para gerar um número aleatório e adicioná-lo em uma lista.

Chega de papo e vamos para os códigos.

Implementar um contador que poderá ser decrementado ou incrementado

Nesse momento não irei focar muito no React em si, então não irei passar por todos os passos explicando cada um, basicamente vamos abrir o App.js e realizar algumas modificações nos códigos do mesmo, o resultado será:

import React, { useState } from 'react';
import './App.css';

function App() {
  const [counter, updateCounter] = useState(0)

  const handleDecrement = () => updateCounter(counter - 1)

  const handleIncrement = () => updateCounter(counter + 1)

  return (
    <div className="App">
      <fieldset>
        <legend>Counter</legend>
        <p>Contador: {counter}</p>
        <button onClick={handleDecrement}>Decrementar</button>
        <button onClick={handleIncrement}>Incrementar</button>
      </fieldset>
    </div>
  );
}

export default App;

Após salvar as modificações, podemos voltar no navegador e ver que a interface do contador está pronta:

Isso deve ser o suficiente para nosso contador estar funcionando com suas duas opções (decrementar e incrementar), podemos testá-lo e ver que tudo funciona como o esperado:

Com a primeira funcionalidade pronta, vamos implementar a segunda.

Implementar um botão para gerar um número aleatório e adicioná-lo em uma lista

Assim como foi feito com o contador, não irei passar por todo o processo de implementação do número aleatório e sim disponibilizar o código final do App.js:

import React, { useState } from 'react';
import './App.css';

function App() {
  const [counter, updateCounter] = useState(0)
  const [numbers, updateNumbers] = useState([])

  const handleDecrement = () => updateCounter(counter - 1)
  const handleIncrement = () => updateCounter(counter + 1)
  const handleAdd = () => updateNumbers([
    ...numbers,
    Math.random().toFixed(2),
  ])

  return (
    <div className="App">
      <fieldset>
        <legend>Counter</legend>
        <p>Contador: {counter}</p>
        <button onClick={handleDecrement}>Decrementar</button>
        <button onClick={handleIncrement}>Incrementar</button>
      </fieldset>
      <fieldset>
        <legend>Números</legend>
        <ul>
          {numbers.map((n, i) => <li key={i}>{n}</li>)}
        </ul>
        <button onClick={handleAdd}>Adicionar</button>
      </fieldset>
    </div>
  );
}

export default App;

Com essas modificações feitas, devemos ter nossa listagem de números prontas:

E funcionando:

Maravilha, tudo funcionando como o esperado.

Visualizando o problema

Agora, vamos adicionar duas novas funcionalidades, queremos mostrar o contador com o valor dobrado e multiplicado por si, ou seja:

Caso o valor do contador seja 3, o valor dobrado será 2x3 = 6 e o valor multiplicado por si será 3x3 = 9

Como de costume, vamos modificar nosso App.js:

import React, { useState } from 'react';
import './App.css';

function App() {
  const [counter, updateCounter] = useState(0)
  const [numbers, updateNumbers] = useState([])
  const counterDouble = counter * 2
  const counterMult = counter * counter

  const handleDecrement = () => updateCounter(counter - 1)
  const handleIncrement = () => updateCounter(counter + 1)
  const handleAdd = () => updateNumbers([
    ...numbers,
    Math.random().toFixed(2),
  ])

  return (
    <div className="App">
      <fieldset>
        <legend>Counter</legend>
        <p>Contador: {counter}</p>
        <p>Contador dobrado: {counterDouble}</p>
        <p>Contador multiplicado: {counterMult}</p>
        <button onClick={handleDecrement}>Decrementar</button>
        <button onClick={handleIncrement}>Incrementar</button>
      </fieldset>
      <fieldset>
        <legend>Números</legend>
        <ul>
          {numbers.map((n, i) => <li key={i}>{n}</li>)}
        </ul>
        <button onClick={handleAdd}>Adicionar</button>
      </fieldset>
    </div>
  );
}

export default App;

Após realizar as devidas modificações e testes, podemos ver que tudo continua funcionando como o esperado. O problema é que nosso counterDouble e counterMult sempre estão sendo processados, mesmo que o valor do counter não mude, as multiplicações estão sendo processadas.

Para que esse problema fique mais claro, vamos adicionar um novo contador que será multiplicado por um valor randômico:

import React, { useState } from 'react';
import './App.css';

function App() {
  const [counter, updateCounter] = useState(0)
  const [numbers, updateNumbers] = useState([])
  const counterDouble = counter * 2
  const counterMult = counter * counter
  const counterRand = counter * Math.random()

  const handleDecrement = () => updateCounter(counter - 1)
  const handleIncrement = () => updateCounter(counter + 1)
  const handleAdd = () => updateNumbers([
    ...numbers,
    Math.random().toFixed(2),
  ])

  return (
    <div className="App">
      <fieldset>
        <legend>Counter</legend>
        <p>Contador: {counter}</p>
        <p>Contador dobrado: {counterDouble}</p>
        <p>Contador multiplicado: {counterMult}</p>
        <p>Contador randômicro: {counterRand}</p>
        <button onClick={handleDecrement}>Decrementar</button>
        <button onClick={handleIncrement}>Incrementar</button>
      </fieldset>
      <fieldset>
        <legend>Números</legend>
        <ul>
          {numbers.map((n, i) => <li key={i}>{n}</li>)}
        </ul>
        <button onClick={handleAdd}>Adicionar</button>
      </fieldset>
    </div>
  );
}

export default App;

Agora para testar, vamos incrementar o contador algumas vezes e depois adicionar alguns números para a listagem:

Repare que ao adicionar novos números na lista, o contador randômico também é atualizado, porém, o valor do contador não mudou, então esse processamento não deveria ser feito.

Cacheando processamento com useMemo

Para essas situações foi criado o hook chamado useMemo, com ele conseguimos garantir que o processamento das contas somente será realizado caso o valor do counter mude.

Para usá-lo devemos passar uma função como primeiro parâmetro, o retorno da função será o valor armazenado em nossa variável e como segundo parâmetro informamos um array, onde cada item do array será utilizado para verificar se o processamento deve ou não ser feito, por exemplo:

const counterDouble = useMemo(() => counter * 2, [counter])

Nesse trecho estamos passando uma arrow function como primeiro parâmetro, ela irá multiplicar o valor do counter por 2e logo em seguida retornar o resultado da multiplicação. Sendo assim, o resultado será armazenado na variável counterDouble.

Como segundo parâmetro, estamos passando um array com o state counter, isso porque ele é a variável que queremos utilizar como base para a verificação do processamento ou não, ou seja, caso o valor do counter mude o processamento deve ser feito, senão, o valor deve ser retornado da memória.

Essa pratica de memorizar um valor para economisar processamento é conhecida como memoized, por isso o hook chama useMemo (Memo de memoized). Caso queira saber mais sobre o assunto, recentemente postei um artigo no blog sobre o mesmo:

Memorizando Funções Em Javascript

Por fim, vamos refatorar nosso App.js para fazer uso do useMemo em nossas variáveis computadas:

import React, { useMemo, useState } from 'react';
import './App.css';

function App() {
  const [counter, updateCounter] = useState(0)
  const [numbers, updateNumbers] = useState([])
  const counterDouble = useMemo(() => counter * 2, [counter])
  const counterMult = useMemo(() => counter * counter, [counter])
  const counterRand = useMemo(() => counter * Math.random(), [counter])

  const handleDecrement = () => updateCounter(counter - 1)
  const handleIncrement = () => updateCounter(counter + 1)
  const handleAdd = () => updateNumbers([
    ...numbers,
    Math.random().toFixed(2),
  ])

  return (
    <div className="App">
      <fieldset>
        <legend>Counter</legend>
        <p>Contador: {counter}</p>
        <p>Contador dobrado: {counterDouble}</p>
        <p>Contador multiplicado: {counterMult}</p>
        <p>Contador randômicro: {counterRand}</p>
        <button onClick={handleDecrement}>Decrementar</button>
        <button onClick={handleIncrement}>Incrementar</button>
      </fieldset>
      <fieldset>
        <legend>Números</legend>
        <ul>
          {numbers.map((n, i) => <li key={i}>{n}</li>)}
        </ul>
        <button onClick={handleAdd}>Adicionar</button>
      </fieldset>
    </div>
  );
}

export default App;

Com essas modificações, podemos realizar o teste novamente, ou seja, incrementar o contador algumas vezes e depois adicionar alguns números para a listagem:

Repare que agora ao adicionar novos itens na listagem, os valores do contador não mudam, isso porque o valor do contador não mudou, sendo assim, não é necessário processá-lo novamente e o valor é pego da memória.

Conclusão

Nesse post vimos como podemos utilizar o hook useMemo para memorizar resultados e economizar no processamento de variáveis.

Abraços, até a próxima.

Originalmente publicado em: https://blog.matheuscastiglioni.com.br