DEV Community: Roberto Umbelino

Identificando Code Smells em JavaScript

Roberto Umbelino — Sat, 06 Jul 2024 01:05:00 +0000

Fala devs, tudo bem? Nesse post vou falar sobre um tópico importante que às vezes passa despercebido, que são os Code Smells. 🐽

📑 Sobre

Code Smells são sinais de que algo pode estar errado no seu código. Eles não são bugs propriamente ditos, mas indicam problemas de design que podem levar a bugs no futuro. Basicamente, são aqueles "toques" que fazem você pensar: "Hmm, isso pode causar problemas mais tarde." Vamos dar uma olhada em alguns exemplos em JavaScript! 😎

1. Duplicated Code (Código Duplicado)

Código duplicado é tipo quando você cola o mesmo trecho de código em várias partes do seu projeto, aí depois dá aquele nó e vira uma bagunça pra manter tudo certinho.

function calcularPrecoTotalComImposto(preco, taxaImposto) {
    return preco + (preco * taxaImposto);
}

function calcularPrecoTotalComDescontoEImposto(preco, desconto, taxaImposto) {
    const precoComDesconto = preco - desconto;
    // Código duplicado
    return precoComDesconto + (precoComDesconto * taxaImposto);
}

Refatorado:

// Código refatorado
function calcularPrecoTotalComImposto(preco, taxaImposto) {
    return preco + (preco * taxaImposto);
}

function calcularPrecoTotalComDescontoEImposto(preco, desconto, taxaImposto) {
    const precoComDesconto = preco - desconto;
    return calcularPrecoTotalComImposto(precoComDesconto, taxaImposto);
}

2. Long Method (Método Longo)

Um método longo é aquele que faz muitas operações em sequência, fazendo com que fique muito difícil de entender e modificar.

// Método longo
function processarPedido(pedido) {
    // Validar pedido
    if (!pedido.id || !pedido.itens || pedido.itens.length === 0) {
        throw new Error('Pedido inválido');
    }

    // Calcular preço total
    const precoTotalInicial = itens.reduce((total, item) => total + item.preco * item.quantidade, 0);

    // Aplicar desconto
    const precoComDesconto = pedido.desconto ? precoTotalInicial - pedido.desconto : precoTotalInicial;

    // Aplicar imposto    
    const taxaImposto = 0.1;
    const precoFinal = precoComDesconto + precoComDesconto * taxaImposto;

    // Finalizar pedido
    console.log(`Pedido ${pedido.id} processado com preço total ${precoFinal.toFixed(2)}`);
}

Refatorado:

// Método refatorado
function validarPedido(pedido) {
    if (!pedido.id || !pedido.itens || pedido.itens.length === 0) {
        throw new Error('Pedido inválido');
    }
}

function calcularPrecoTotal(itens, desconto = 0) {
    const precoTotal = itens.reduce((total, item) => total + item.preco * item.quantidade, 0);
    return precoTotal - desconto;
}

function aplicarImposto(precoTotal) {
    return precoTotal * 1.1;
}

function processarPedido(pedido) {
    validarPedido(pedido);
    const precoTotal = calcularPrecoTotal(pedido.itens, pedido.desconto);
    const precoTotalComImposto = aplicarImposto(precoTotal);
    console.log(`Pedido ${pedido.id} processado com preço total ${precoTotalComImposto.toFixed(2)}`);
}

3. Large Class (Classe Grande)

Uma classe grande tem muitas responsabilidades ou métodos, o que pode indicar que ela está fazendo mais do que deveria e pode ser difícil de manter.

// Classe grande
class Pedido {
    constructor(id, itens, desconto) {
        this.id = id;
        this.itens = itens;
        this.desconto = desconto;
    }

    validar() {
        if (!this.id || !this.itens || this.itens.length === 0) {
            throw new Error('Pedido inválido');
        }
    }

    calcularPrecoTotal() {
        const precoTotal = itens.reduce((total, item) => total + item.preco * item.quantidade, 0);
        return precoTotal - desconto;
    }

    aplicarImposto(precoTotal) {
        return precoTotal * 1.1;
    }

    processar() {
        this.validar();
        let precoTotal = this.calcularPrecoTotal();
        precoTotal = this.aplicarImposto(precoTotal);
        console.log(`Pedido ${this.id} processado com preço total ${precoTotal}`);
    }
}

Refatorado:

// Classes refatoradas
class ValidadorDePedido {
    static validar(pedido) {
        if (!pedido.id || !pedido.itens || pedido.itens.length === 0) {
            throw new Error('Pedido inválido');
        }
    }
}

class CalculadoraDePreco {
    static calcularPrecoTotal(itens, desconto = 0) {
        const precoTotal = itens.reduce((total, item) => total + item.preco * item.quantidade, 0);
        return precoTotal - desconto;
    }
}

class CalculadoraDeImposto {
    static aplicarImposto(precoTotal) {
        return precoTotal * 1.1;
    }
}

class ProcessadorDePedido {
    constructor(pedido) {
        this.pedido = pedido;
    }

    processar() {
        ValidadorDePedido.validar(this.pedido);
        const precoTotal = CalculadoraDePreco.calcularPrecoTotal(this.pedido.itens, this.pedido.desconto);
        const precoTotalComImposto = CalculadoraDeImposto.aplicarImposto(precoTotal);
        console.log(`Pedido ${this.pedido.id} processado com preço total ${precoTotalComImposto.toFixed(2)}`);
    }
}

4. Feature Envy (Inveja de Funcionalidade)

Feature Envy ocorre quando uma classe utiliza excessivamente métodos ou dados de outra classe, o que pode indicar uma distribuição inadequada de responsabilidades.

// Feature Envy
class Cliente {
    constructor(nome, endereco) {
        this.nome = nome;
        this.endereco = endereco;
    }
}

class Pedido {
    constructor(cliente, itens) {
        this.cliente = cliente;
        this.itens = itens;
    }

    imprimirEtiquetaDeEnvio() {
        console.log(`Envio para: ${this.cliente.nome}, ${this.cliente.endereco}`);
    }
}

Refatorado:

// Refatorado para mover a responsabilidade
class Cliente {
    constructor(nome, endereco) {
        this.nome = nome;
        this.endereco = endereco;
    }

    obterEtiquetaDeEnvio() {
        return `Envio para: ${this.nome}, ${this.endereco}`;
    }
}

class Pedido {
    constructor(cliente, itens) {
        this.cliente = cliente;
        this.itens = itens;
    }

    imprimirEtiquetaDeEnvio() {
        console.log(this.cliente.obterEtiquetaDeEnvio());
    }
}

5. Primitive Obsession (Obsessão por Primitivos)

Primitive Obsession é quando se utiliza primitivos (como strings e números) para representar conceitos que deveriam ser encapsulados em classes específicas, resultando em código menos legível e mais difícil de manter.

// Primitive Obsession
class Pedido {
    constructor(id, itens, codigoDesconto) {
        this.id = id;
        this.itens = itens;
        this.codigoDesconto = codigoDesconto;
    }

    aplicarDesconto() {
        if (this.codigoDesconto === 'SAVE10') {
            // Aplicar desconto de 10%
        } else if (this.codigoDesconto === 'SAVE20') {
            // Aplicar desconto de 20%
        }
    }
}

Refatorado:

// Refatorado para usar classes específicas
class Desconto {
    constructor(codigo, porcentagem) {
        this.codigo = codigo;
        this.porcentagem = porcentagem;
    }

    aplicar(precoTotal) {
        return precoTotal - (precoTotal * this.porcentagem / 100);
    }
}

class Pedido {
    constructor(id, itens, desconto) {
        this.id = id;
        this.itens = itens;
        this.desconto = desconto;
    }

    aplicarDesconto(precoTotal) {
        if (this.desconto) {
            return this.desconto.aplicar(precoTotal);
        }
        return precoTotal;
    }
}

Curtiu o post? Ainda há outros exemplos que poderiam ser citados, mas isso deixaria o post muito longo 😋, mas espero que esses exemplos ajudem de alguma forma a você conseguir identificar e corrigir os code smells no seu projeto. 🚀

Filtering in JOIN or WHERE in MySQL: Differences and Performance Impact

Roberto Umbelino — Sat, 22 Jun 2024 02:08:00 +0000

📑 About

The decision of where to apply a filter in an SQL query, either in JOIN or WHERE, depends on your intention and the logic of the query you are writing. Both approaches can be appropriate in different situations. I'll explain the differences between them:

Filtering in JOIN:

When you apply a filter in a JOIN clause, you are specifying the join conditions between tables. This means you are limiting which rows will be matched between the tables before applying the WHERE filter. This can be useful when you want to restrict the rows being combined to optimize the query and reduce the amount of processed data.

For example, if you are joining two tables and are only interested in rows where a certain column value matches, you can apply this filter in the JOIN to avoid combining unnecessary rows.

SELECT *
FROM table1
INNER JOIN table2 ON table1.id = table2.table1_id AND table1.value = 'some_value';

Filtering in WHERE:

The WHERE clause is used to apply filters to the query after the tables have been joined. This allows you to filter rows based on criteria involving columns from both tables after the join. This is useful when you need to perform more complex filters involving multiple tables.

SELECT *
FROM table1
INNER JOIN table2 ON table1.id = table2.table1_id
WHERE table1.value = 'some_value' AND table2.column = 'some_other_value';

🚀 Comparing Performance

Let's compare the performance of both approaches with some practical examples.

Example 1: Filtering in `JOIN`

EXPLAIN SELECT *
FROM table1
INNER JOIN table2 ON table1.id = table2.table1_id AND table1.value = 'some_value';

Example 2: Filtering in `WHERE`

EXPLAIN SELECT *
FROM table1
INNER JOIN table2 ON table1.id = table2.table1_id
WHERE table1.value = 'some_value';

Analyzing the execution plans (output of EXPLAIN), we can observe:

Filtering in JOIN:

🎯 MySQL can optimize the join by combining only the necessary rows according to the JOIN condition.

🚀 Fewer initially processed rows.
Filtering in WHERE:

🎯 MySQL performs the complete join first and then applies the additional filter.

🚀 More initially processed rows, but useful for complex conditions involving multiple tables.

📊 Performance Results

Filter in JOIN:

🟢 Faster execution in queries with large data sets where the initial filter significantly reduces the number of rows.

🟢 Lower memory and CPU usage.
Filter in WHERE:

🟢 Execution may be slower if the initial data set is large because more rows are combined before filtering.

🟢 Useful for complex filters involving multiple columns from different tables.

🔍 Conclusion

The choice of where to apply a filter depends on your specific needs and the logic of the query. Use filters in JOIN when you want to limit the combined rows from the start, optimizing data processing. Use filters in WHERE when you need complex filters involving multiple columns from different tables. In many cases, the difference in performance may be insignificant, but in queries with large data volumes, the correct choice can make a significant difference. Always test your queries in real scenarios to determine the best approach.

Proxy Pattern: A Practical Guide to Smarter Object Handling

Roberto Umbelino — Fri, 21 Jun 2024 18:17:36 +0000

The Proxy Pattern is an object-oriented programming concept that acts as a “substitute” or “representative” for another object. This pattern is very useful when we need to control access to an object or add extra functionalities without directly modifying its code. Basically, the Proxy acts as an intermediary between the client (who uses the object) and the real object, allowing the Proxy to manage this access in various ways.

❓ Why Use the Proxy Pattern?

Imagine you have an object that performs a heavy or time-consuming task, like loading data from a server. It might not be efficient or necessary to do this every time the object is accessed. With a Proxy, you can implement “lazy loading,” loading the data only when it’s really needed. Another common application is implementing security, where the Proxy can check permissions before allowing access to sensitive methods of the real object.

⚙️ How Does the Proxy Work?

The Proxy Pattern involves three main components:

Real Object: The object that contains the main logic or data.
Proxy: The intermediary that controls access to the real object.
Client: The entity that interacts with the Proxy instead of directly with the real object.

When the client requests something from the Proxy, it decides whether to forward the request to the real object, handle the request itself, or even deny access.

Let’s look at two practical examples to understand this better.

💾 Example 1: Caching with Proxy

First, we’ll define an object that simulates a database. Then, we’ll create a Proxy to cache the results of queries to this database.

🏗️ Step 1: Defining the Database Object

Let’s create an object that simulates a database with user data.

const database = {
  users: {
    1: { id: 1, name: "Alice" },
    2: { id: 2, name: "Bob" },
    3: { id: 3, name: "Charlie" },
  },
  getUser(id) {
    console.log(`Fetching user with id ${id} from database...`)
    return this.users[id]
  },
}

🛠️ Step 2: Creating the Proxy for Caching

Now, we’ll create a Proxy that caches the results of database queries.

const cacheHandler = {
  cache: {},
  get(target, prop, receiver) {
    if (prop === "getUser") {
      return (id) => {
        if (!this.cache[id]) {
          this.cache[id] = target.getUser(id)
          return this.cache[id]
        }

        console.log(`Fetching user with id ${id} from cache...`)
        return this.cache[id]
      }
    }

    return Reflect.get(target, prop, receiver)
  },
}

const dbProxy = new Proxy(database, cacheHandler)

🔄 Step 3: Using the Proxy

Now, let’s use the Proxy to access the database data and see if the caching works correctly.

console.log(dbProxy.getUser(1)) // Fetching user with id 1 from database...
console.log(dbProxy.getUser(1)) // Fetching user with id 1 from cache...
console.log(dbProxy.getUser(2)) // Fetching user with id 2 from database...
console.log(dbProxy.getUser(2)) // Fetching user with id 2 from cache...
console.log(dbProxy.getUser(3)) // Fetching user with id 3 from database...
console.log(dbProxy.getUser(3)) // Fetching user with id 3 from cache...

📊 Result

When you run this code, you’ll see that the first query for a specific user accesses the (simulated) database, and subsequent queries for the same user access the cache, avoiding the need to query the database again. Here’s the expected output:

Fetching user with id 1 from database...
{ id: 1, name: 'Alice' }
Fetching user with id 1 from cache...
{ id: 1, name: 'Alice' }
Fetching user with id 2 from database...
{ id: 2, name: 'Bob' }
Fetching user with id 2 from cache...
{ id: 2, name: 'Bob' }
Fetching user with id 3 from database...
{ id: 3, name: 'Charlie' }
Fetching user with id 3 from cache...
{ id: 3, name: 'Charlie' }

📝 Example 2: Form Validator with Proxy

Now, let’s create a Proxy to validate form data before it gets set on the object.

const form = {
  name: "",
  email: "",
  password: "",
}

const validator = {
  set(target, prop, value) {
    if (prop === "email" && !isValidEmail(value)) {
      throw new Error("Invalid email address")
    }

    if (prop === "password" && !isValidPassword(value)) {
      throw new Error("Password must contain at least 8 characters")
    }
    target[prop] = value
    return true
  },
}

const formProxy = new Proxy(form, validator)

function isValidEmail(email) {
  return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email)
}

function isValidPassword(password) {
  return password.length >= 8
}

formProxy.name = "John"
formProxy.email = "john.doe@example.com" // throws an Error: "Invalid email address"
formProxy.password = "1234" // throws an Error: "Password must contain at least 8 characters"

Here, the Proxy intercepts the value assignments to the form fields and validates them before allowing the update. If validation fails, an error is thrown, preventing invalid values from being set.

✅ Conclusion

The Proxy Pattern is a powerful tool for adding a layer of control and functionality over an object without directly modifying its code. With it, we can implement caching, lazy loading, input validation, access control, and much more in an organized and efficient way.

Why Specifying the Node.js Version is Essential

Roberto Umbelino — Thu, 20 Jun 2024 16:43:21 +0000

Hey everyone! Today we're going to talk about a super important practice in developing Node.js applications: specifying the Node.js version in your project's package.json file. It might seem like a small detail, but trust me, it can save you from a lot of headaches in the future. So, let's understand why this is crucial!

Why Specify the Node.js Version? 🤔

Consistency in Development: 🛠️ When working in a team, it's crucial that everyone uses the same version of Node.js. If each developer uses a different version, chaos can ensue, with mysterious bugs appearing only on one colleague's machine. By specifying the version in package.json, you ensure everyone is on the same page.
Code Compatibility: 🐞 New versions of Node.js bring new features but can also introduce changes that break compatibility with previous versions. If you don't specify a version, you might find that a dependency stops working or your code starts throwing errors after an update.
Aligned Production and Development Environments: 🌐 Imagine you developed and tested your application on one version of Node.js, but the server is running a different version when deploying to production. This can cause unexpected behaviors and hard-to-track errors. By specifying the version in package.json, you can configure your production environment to use the same version, avoiding unpleasant surprises.

How to Specify the Node.js Version in `package.json` 📜

It's quite simple. In your package.json, add a property called engines and specify the Node.js version your application requires. Here's a basic example:

{
  "name": "my-application",
  "version": "1.0.0",
  "description": "My awesome application",
  "main": "index.js",
  "scripts": {
    "start": "node index.js"
  },
  "engines": {
    "node": ">=14.0.0 <16.0.0"
  },
  "dependencies": {
    "express": "^4.17.1"
  }
}

In this example, we're stating that the application requires a Node.js version greater than or equal to 14.0.0 and less than 16.0.0. This helps keep everyone aligned and aware of the version that should be used.

Tools for Managing Node.js Versions 🧰

In addition to specifying the version in package.json, you can use tools to ensure the correct version is installed and active in your development environment. The most popular of these is nvm (Node Version Manager). With it, you can install multiple versions of Node.js and switch between them easily.

Install nvm: Follow the installation instructions on the official nvm GitHub repository.
Install a specific version of Node.js:

  nvm install 14

Use the installed version:

  nvm use 14

You can also create an .nvmrc file in your project, containing the Node.js version you want to use. Here's an example of how to create this file:

# Create an .nvmrc file in your project's root directory
echo "14" > .nvmrc

This .nvmrc file contains just the version number of Node.js you want to use. When you or another developer enters the project directory, simply run nvm use and nvm will automatically adjust the Node.js version.

Conclusion 🎯

Specifying the Node.js version in package.json might seem like a small detail, but it's an essential practice to maintain consistency and stability in your project. It avoids many compatibility issues and helps ensure your code works the same way in all environments, from development to production.

So, don't slack! The next time you start a Node.js project, make sure to specify the Node.js version in package.json and use tools like nvm to manage your versions. Your future self and your teammates will thank you! 🚀

Testing Your API with Fastify and Vitest: A Step-by-Step Guide

Roberto Umbelino — Thu, 20 Jun 2024 16:38:29 +0000

Hey there! Let's dive into how to test an API built with Fastify using Vitest and TypeScript. We'll focus on a simple health check route and make sure everything's working as it should.

Why Test an API?

Testing an API is super important to make sure everything is running smoothly. Automated tests help us catch bugs quickly and keep our code solid and reliable.

Setting Up the Environment

Let's start from scratch and set up our project. First, create a directory for the project and initialize a new Node.js project:

mkdir my-fastify-api
cd my-fastify-api
npm init -y

Next, let's install Fastify and TypeScript:

npm install fastify
npm install typescript ts-node @types/node --save-dev

Create a tsconfig.json file to configure TypeScript:

{
  "compilerOptions": {
    "target": "ESNext",
    "module": "CommonJS",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "outDir": "./dist",
    "rootDir": "./src"
  },
  "include": ["src/**/*.ts"]
}

Creating the Fastify Server

Now, let's set up a Fastify server with a simple health check route. Create a src directory and inside it, make an app.ts file:

// src/app.ts
import fastify from 'fastify';

const app = fastify();

app.get('/health-check', async (request, reply) => {
  return { status: 'ok' };
});

export default app;

Next, let's create the server.ts file to start the server:

// src/server.ts
import app from './app';

const start = async () => {
  try {
    await app.listen({ port: 3000 });
    console.log('Server is running on http://localhost:3000');
  } catch (err) {
    app.log.error(err);
    process.exit(1);
  }
};

start();

Installing Vitest

Now, let's install Vitest so we can write our tests:

npm install --save-dev vitest

Add the following scripts to your package.json:

"scripts": {
  "dev": "ts-node src/server.ts",
  "test": "vitest",
  "test:watch": "vitest --watch"
}

Writing Tests

Let's write a test for our health-check route. Create a tests directory and inside it, make a health-check.test.ts file:

// tests/health-check.test.ts
import app from '../src/app';
import { test, expect } from 'vitest';

test('GET /health-check should return status OK', async () => {
  const response = await app.inject({
    method: 'GET',
    url: '/health-check'
  });

  expect(response.statusCode).toBe(200);
  expect(response.json()).toEqual({ status: 'ok' });
});

Running the Tests

To run the tests, use this command:

npm test

If you want the tests to run continuously whenever you make changes, use:

npm run test:watch

Conclusion

And that's it! In this article, we saw how to set up a Fastify project with TypeScript from scratch and how to write tests for a simple route using Vitest. Testing your routes makes sure your API is always working correctly and helps avoid any nasty surprises later on. Happy coding!

DEV Community: Roberto Umbelino

Identificando Code Smells em JavaScript

📑 Sobre

1. Duplicated Code (Código Duplicado)

2. Long Method (Método Longo)

3. Large Class (Classe Grande)

4. Feature Envy (Inveja de Funcionalidade)

5. Primitive Obsession (Obsessão por Primitivos)

Filtering in JOIN or WHERE in MySQL: Differences and Performance Impact

📑 About

🚀 Comparing Performance

Example 1: Filtering in JOIN

Example 2: Filtering in WHERE

📊 Performance Results

🔍 Conclusion

Proxy Pattern: A Practical Guide to Smarter Object Handling

❓ Why Use the Proxy Pattern?

⚙️ How Does the Proxy Work?

💾 Example 1: Caching with Proxy

🏗️ Step 1: Defining the Database Object

🛠️ Step 2: Creating the Proxy for Caching

🔄 Step 3: Using the Proxy

📊 Result

📝 Example 2: Form Validator with Proxy

✅ Conclusion

Why Specifying the Node.js Version is Essential

Why Specify the Node.js Version? 🤔

How to Specify the Node.js Version in package.json 📜

Tools for Managing Node.js Versions 🧰

Conclusion 🎯

Testing Your API with Fastify and Vitest: A Step-by-Step Guide

Why Test an API?

Setting Up the Environment

Creating the Fastify Server

Installing Vitest

Writing Tests

Running the Tests

Conclusion

Example 1: Filtering in `JOIN`

Example 2: Filtering in `WHERE`

How to Specify the Node.js Version in `package.json` 📜