Forem: Davi Firmino

Os "Maus Cheiros" do código

Davi Firmino — Mon, 26 Oct 2020 23:49:45 +0000

Descrição

Esse post tem o intuito de conversar um pouco sobre os "Maus Cheiros" do código, tendo como base o livro Refactoring: Improving the Design of Existing Code do Martin Fowler.
Se você nunca leu esse livro, você está perdendo uma ótima leitura que com certeza irá adicionar muito ao longo de sua carreira.

Os maus cheiros

Os maus cheiros do código são indícios de que um código precisa ser refatorado. Se trata de determinadas estruturas problemáticas que se repetem e podem causar problemas com o passar do tempo.
Não existe uma receita de bolo, iremos tratar de alguns indícios de que pode haver um problema e cabe a sua experiência e intuição decidir se vale ou não a pena refatorar.
Vamos entrar em detalhes sobre esses "cheiros".

Nome misterioso

Esse talvez seja o mais simples e comum de encontrarmos no dia a dia.
Quantas vezes não encontramos aquela variável teste no código ou até mesmo collection (coleção de que cara pálida?).
O livro constantemente nos lembra da importância de escolhermos bons nomes.
Ler um bom código tem que ser tão natural quanto ler um bom livro.
Existem alguns métodos que podemos usar para ajudar nesse ponto:

Pode parecer óbvio essa recomendação mas passamos o dia inteiro nomeando as coisas e escolher bons nomes realmente é uma tarefa difícil.

Código duplicado

Se você encontrar o mesmo código em 2 lugares diferentes pode ter certeza que não demora muito você modificar um e esquecer do outro e acabar quebrando alguma parte do seu sistema.
Um código pode se repetir em diversas formas e estruturas diferentes.
Se você encontrar uma expressão que está se repetindo podemos utilizar:

Função longa

Não existe uma regra para determinar quantas linhas uma função tem que ter.
Eu gosto da definição: "Uma função deve fazer bem uma coisa e apenas uma".
Podemos utilizar as seguintes técnicas:

Lista longa de parâmetros

Uma grande quantidade parâmetros na função pode ser um sinal de que ela não está fazendo somente uma coisa ou pode ser sinal de um código bem confuso de ler.
Algumas técnicas que nos ajudam:

Dados globais

Se você é programador javascript você sabe melhor que ninguém o problema de se possuir dados globais.
O problema de dados globais é que eles podem ser modificados em qualquer parte da sua aplicação tornando quase impossível (dependendo do tamanho da mesma) descobrir quem foi o infeliz que modificou eles.
Para isso, podemos utilizar:

Encapsular variável

Dados mutáveis

Mudança constante de dados pode acabar resultando em consequências inesperadas.
Mudamos no ponto A e as vezes ocorre um erro no ponto B pois esse novo ponto esperava algo diferente do que veio.
A programação funcional tem como um dos princípios a imutabilidade de dados, eles devem evoluir não mudar.
Vale a pena da uma olhada nesse conceito..
Uma lista de técnicas que nos ajudam:

Alteração divergente

Com certeza você já lidou com um projeto em que você olhou e pensou: "bom caso eu precise adicionar tal coisa é fácil é só alterar esses 5 funções dessa classe".
Nesse caso ambos os métodos estão na mesma classe e se você tem que mexer em vários lugares para fazer uma alteração convém tentar centralizar isso em um único método.
Podemos utilizar:

Cirurgia com rifle

Eu adoro essa definição, é ligeiramente parecida com a alteração divergente mas ao invés de ser a mesma classe para mudar uma determinada funcionalidade você tem que mexer em várias classes diferentes.
Se você tem que mexer em vários lugares, fica fácil esquecer de alterar algum ponto.
Podemos utilizar:

Inveja de Recursos

Acontece quando uma determinada função ou classe de um módulo gasta mais tempo se comunicando com outra função de outro módulo do que com o próprio módulo que ela está.
"É claro que há vários padrões sofisticados que violam essa regra. Da gangue dos quatro (GOF), Strategy e Visitor. Self Delegation de Kent Beck é outro. A regra geral básica é colocar junto aquilo que muda junto. Dados e os comportamentos que referenciam esse dado em geral mudam juntos - mas há exceções. Quando exceções ocorrem, movemos o comportamento para manter as alterações em um só lugar. Strategy e Visitor lhe permitem modificar facilmente o comportamento porque isolam a pequena dose de comportamento que deve ser sobrescrita, ao custo de mais acessos indiretos."
Podemos utilizar:

Agrupamento de dados

Dados que constantemente são usados juntos, deveriam possuir um agrupamento para eles.
Podemos utilizar:

Obsessão por primitivos

Normalmente encontramos códigos que são obcecados pelos usos primitivos ao invés de criarem seus próprios tipos (leia como classe).
Podemos utilizar:

Switches repetidos

A grande maioria das instruções switch podem ser substituídas por polimorfismo.
O problema com o switch duplicados é que sempre que tiver uma mudança você terá que alterar eles.

Substituir condicional por polimorfismo

Laços

Quase sempre podemos alterar laços por funções mais declarativas que fazem mais com menos (map, filter, reduce...)

Substituir laços por pipeline

Elemento ocioso

É aquela classe ou função que imaginávamos que poderia crescer mas esse dia nunca chegou.
Podemos utilizar:

Campo temporário

As vezes em uma classe você vê um campo que só é definido em uma determinada circunstância, um código assim pode ser difícil de entender.
Tentar entender o porquê do campo aparecer em um momento e em outro não pode te deixar louco.
Podemos utilizar:

Cadeia de mensagem

Quando você pede um objeto que esse por sua vez pede outro objeto que esse pede outro objeto que pede outro (Já deu pra entender né?).
Isso gera um grande acoplamento na cadeia de navegação e uma mudança pode fazer com que tenhamos que alterar toda essa cadeia.
Podemos utilizar:

Intermediário

As vezes você encontra um objeto que não faz nada além de delegar para outros objetos.
Se tornando apenas um intermediário sem função concreta. Nesse contexto removemos esse intermediário deixando os objetos se comunicarem diretamente.
Podemos utilizar:

Classe Grande

As vezes encontramos classes que fazem mais de uma coisa ou com códigos duplicados.
Podemos utilizar:

Classes alternativas com interfaces diferentes

Quando você encontra classes diferentes com métodos diferentes mas que na prática fazem a mesma coisa.
Podemos utilizar:

Herança Recusada

Quando uma classe herda os dados mas não usa eles ou utilizam quase nenhum.
Podemos utilizar:

Comentários

Comentários não são ruins mas se eles são usados em excesso pode ser um sinal de que o código esteja muito difícil de compreender.

Conclusão

Como podemos ver escrever um código é uma tarefa complexa que em grande parte é tratado como se fosse algo trivial sem a atenção necessária.
Se você chegou a conclusão que ainda tem muito que melhorar quero te dizer que estamos juntos (eu também tenho muito que aprender inclusive muitas dessas técnicas listadas eu ainda estou longe de dominar).
Vou transcrever uma parte do livro clean code que acho que se encaixa com esse post (com quase tudo na verdade).
"lembre-se daquela piada sobre o violinista que se perdeu no caminho para a apresentação em um concerto? Ele aborda um senhor na esquina e lhe pergunta como chegar no Carnegie Hall. O senhor observa o violinista com seu violino debaixo do braço e diz: "Pratique, filho. Pratique!"

Nota

Ficou um post extenso e acredito que a grande maioria não irá ler até o fim, escrevo mais como uma forma de fixar o conteúdo aprendido e de distrair a cabeça nessa quarentena.
Sinta-se a vontade para oferecer sugestões de melhorias (Quem sabe não podemos aprender juntos) ou xingamentos.
Espero que não tenha violado nenhum direito autoral com esse post...
Esse post toca apenas a superfície de todo material oferecido no livro caso queira aprofundar sobre o assunto sugiro fortemente a compra do mesmo.
No mais é isso, pra quem chegou até aqui valeu falou.

Configurando React com Typescript sem CRA

Davi Firmino — Mon, 26 Oct 2020 02:47:57 +0000

Escrevo esse post pois não é fácil encontrar algum material que explique de forma eficiente como se montar um boilerplate com react e typescript sem o CRA (Create-React-App).
Embora a grande maioria dos casos o cra atenda perfeitamente, pode existir um determinado caso que em função da sua arquitetura você queira fazer um setup manual.
O cra é muito útil e longe de mim querer criticá-lo porém ele pode deixar sua arquitetura um pouco engessada.
Esse post irá explicar de forma detalhada cada passo do projeto, caso você não queira ler pule para o final do arquivo com o link do repositório.

Padrões

Antes de começarmos de fato, vamos definir alguns padrões para que o projeto não vire a casa da mãe joanna.
Para os commits utilizaremos o conventional commits

Começando

Primeiro vamos criar a nossa pasta para iniciar o projeto

mkdir boilerplate && cd boilerplate

Agora vamos iniciar o package.json

npm init -y

Vamos iniciar o git

git init

Vamos adicionar um biblioteca para ajudar a gente a manter o padrão das mensagens de commit.
git-commit-msg-linter

npm i -D git-commit-msg-linter

Vamos agora criar o .gitignore

echo "node_modules\ncoverage\npublic/js" > .gitignore

Vamos instalar o typescript

npm i -D typescript

Agora o types do node (para garantir a tipagem do node)

npm i -D @types/node

Vamos agora criar o arquivo de configuração do typescript

touch tsconfig.json

dentro dele vamos digitar o seguinte:

{
  "compilerOptions": {
    "target": "es6",
    "lib": [
      "dom",
      "dom.iterable",
      "esnext"
    ],
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "node",
    "jsx": "react",
    "rootDir": "src",
    "baseUrl": "src",
    "allowJs": true,
    "resolveJsonModule": true,
    "isolatedModules": false,
  },
  "include": [
    "src"
  ],
  "exclude": []
}

Caso você não entenda essas configurações você pode consultar aqui.

Agora vamos configurar o eslint, existem algumas formas para fazer isso eu vou escolher a que eu considero a mais fácil.

npx eslint --init

Vamos marcar a opção:
To check syntax and find problems
o code style será feito pelo prettier daqui a pouco
Depois marcamos:
JavaScript modules (import/export)
React
yes
Browser
JSON
yes

Vamos adicionar um plugin para que nosso lint consiga trabalhar com hooks:

npm i -D eslint-plugin-react-hooks

Agora vamos configurar o prettier:

npm i -D prettier eslint-config-prettier eslint-plugin-prettier

Agora vamos editar nosso .eslintrc.json:

{
    "env": {
        "browser": true,
        "es2021": true
    },
    "settings": {
      "react" : {
        "version": "detect"
      }
    },
    "extends": [
        "eslint:recommended",
        "plugin:react/recommended",
        "plugin:@typescript-eslint/recommended",
        "plugin:prettier/recommended"
    ],
    "parser": "@typescript-eslint/parser",
    "parserOptions": {
        "ecmaFeatures": {
            "jsx": true
        },
        "ecmaVersion": 12,
        "sourceType": "module"
    },
    "plugins": [
        "react",
        "@typescript-eslint",
        "react-hooks"
    ],
    "rules": {
      "react-hooks/rules-of-hooks": "error",
      "react-hooks/exhaustive-deps": "warn",
      "react/prop-types": "off",
      "@typescript-eslint/explicit-function-return-type": "error",
      "react/jsx-uses-react": "error",
      "react/jsx-uses-vars": "error"
    }
}

referências aqui

Vamos criar nosso .eslintignore

echo "node_modules\njest.config.js\ncoverage\npublic\nwebpack.config.js\n*.scss" > .eslintignore

Vamos criar nosso .prettierrc:

touch .prettierrc

Dentro dele vamos colocar:

{
  "trailingComma": "none",
  "semi": false,
  "singleQuote": true
}

referências aqui

Vamos adicionar um script de lint no nosso package.json para facilitar o trabalho:

"lint": "eslint src"

Vamos agora adicionar o lint-staged para poder executar ações em nossos arquivos que estão na staged area do git

npm i -D lint-staged

Vamos adicionar também o husky para criarmos hooks no git

npm i -D husky

vamos criar nosso arquivo .lintstagedrc

touch .lintstagedrc.json

dentro dele vamos colocar

{
  "*.{ts,tsx}" : [
      "eslint 'src/**' --fix ",
      "npm run test:staged"
  ]
}

vamos criar agora nosso huskyrc:

touch .huskyrc.json

dentro dele vamos colocar:

{
    "hooks": {
        "pre-commit": "lint-staged && npm run test:ci",
    }
}

Vamos agora configurar o jest para nossos testes

npm i -D jest @types/jest ts-jest

Vamos criar o arquivo de configuração do jest

touch jest.config.js

dentro dele

module.exports = {
  roots: ['<rootDir>/src'],
  collectCoverageFrom: ['<rootDir>/src/**/*.{ts,tsx}', '!**/*.d.ts'],
  coverageDirectory: 'coverage',
  testEnvironment: 'jsdom',
  transform: {
    '.+\\.(ts|tsx)$': 'ts-jest'
  },
  moduleNameMapper: {
    '\\.scss$': 'identity-obj-proxy'
  }
}

referências aqui

Vamos adicionar agora alguns scripts pra teste no package.json

"test": "jest --passWithNoTests --no-cache --verbose --runInBand",
"test:watch": "npm run test -- --watch",
"test:staged": "npm run test -- --findRelatedTests",
"test:ci": "npm run test -- --coverage",

Finalmente React \o/

Antes de prosseguir vamos certificar que seu projeto está igual ao meu:

Vamos começar instalando o react e o react dom

npm i react react-dom

e o types deles

npm i -D @types/react @types/react-dom

na raiz do projeto vamos criar uma pasta com o nome de public

mkdir public

dentro dessa pasta vamos criar um index.html com o seguinte conteudo

<!DOCTYPE html>
<html lang="pt-br">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Document</title>
</head>
<body>
  <div id="app"></div>
  <script src="js/bundle.js"></script>
</body>
</html>

dentro de public vamos criar uma pasta js

vamos instalar e configurar o webpack agora

npm i -D webpack webpack-cli webpack-dev-server

vamos criar o arquivo do webpack.config.js na raiz do projeto
e dentro dele vamos adicionar o seguinte

const path = require('path')
const { CleanWebpackPlugin } = require('clean-webpack-plugin')

module.exports = env => {
  const mode = env.development ? 'development' : 'production'
  return {
    mode,
    entry: path.join(__dirname, 'src', 'index.tsx'),
    output: {
      path: path.join(__dirname, 'public', 'js'),
      publicPath: path.join('public', 'js'),
      filename: 'bundle.js'
    },
    resolve: {
      extensions: ['.ts', '.tsx', '.js', '.scss', '.css'],
    },
    module: {
      rules: [{
        test: /\.ts(x?)$/,
        loader: 'ts-loader',
        exclude: /node_modules/
      }, {
        test: /\.(s)css$/,
        use: [{
          loader: 'style-loader'
        }, {
          loader: 'css-loader',
          options: {
            modules: true
          }
        }, {
          loader: 'sass-loader'
        }]
      }]
    },
    devServer: {
      contentBase: path.join(__dirname, 'public'),
      writeToDisk: true,
      historyApiFallback: true,
      open: true
    },
    plugins: [
      new CleanWebpackPlugin(),
    ]
  }
}

vamos adicionar os plugins necessários pra fazer o webpack funcionar:

npm i -D clean-webpack-plugin node-sass sass-loader css-loader style-loader ts-loader

Analisando dependências:

clean-webpack-plugin - Plugin para limpar a pasta de build (ajuda com o cache).
node-sass - Para conseguir usar sass dentro do node
css-loader - Para que o webpack entenda algumas coisas como: @import, url()...
style-loader - para o webpack consiga colocar o style no DOM.
sass-loader - Loader para que o webpack consiga trabalhar com sass
ts-loader - Para o webpack entender o typescript

Vamos criar uma pasta src e dentro dela um arquivo sass-module.d.ts com o seguinte:

declare module '*.scss' {
  const content: { [className: string]: string }
  export = content
}

dentro de src vamos criar o arquivo index.tsx com o seguinte conteúdo:

import React from 'react'
import ReactDOM from 'react-dom'
import App from './components/App'

ReactDOM.render(<App />, document.getElementById('app'))

dentro de src vamos criar a pasta components e criar o App.tsx
com o seguinte conteúdo:

import React from 'react'
import Styles from './App-styles.scss'

const App: React.FC = () => {
  return (
    <h1 data-testid="teste" className={Styles.h1}>
      Glória a Deuxxx
    </h1>
  )
}

export default App

ainda dentro de components vamos criar o App-styles.scss:

.h1 {
  color: tomato;
}

E vamos criar um arquivo App.spec.tsx vazio por enquanto.
Por fim adicionamos o script de start e build no package.json:

 "start": "webpack serve --env development",
 "build": "webpack --env production",

Nossa estrutura até aqui:

Preparando os testes no react

antes da gente começar a configurar os testes temos que instalar um pacote identity-obj-proxy para que o jest não "encrenque"com o sass.

npm i -D identity-obj-proxy

Nosso conf do jest já está configurado para utilizar essa dependências você pode ir lá rever o arquivo caso ache necessário.

Vamos adicionar o testing-library

npm i -D @testing-library/react

Agora dentro do App.spec.tsx vamos adicionar:

import React from 'react'
import { render } from '@testing-library/react'
import App from './App'

describe('teste do boilerPlate', () => {
  test('App', () => {
    const { getByTestId } = render(<App />)
    const h1 = getByTestId('teste')
    expect(h1.innerHTML).toBe('Glória a Deuxxx')
  })
})

Tudo pronto

Foi um post longo acho que ninguém vai ler tudo mas a minha intenção foi mais explicar em detalhes do que simplesmente um código pra copiar e colar.
Esse é o respositório do boilerplate:
https://github.com/dfirmino/react-boilerplate
Qualquer dúvida, sugestão ou xingamento é só mandar lá no git.
Valeu Falou

Dicas

Podemos configurar o lint para ser executado após o save do arquivo, vou colocar um exemplo do meu settings do vscode mas aconselho da uma pesquisada na internet e ajustar no seu: