DEV Community: Jesús Mejías Leiva

Code smell | Side Effects

Jesús Mejías Leiva — Wed, 29 Nov 2023 13:09:25 +0000

Hello, today I am writing again and in this post I am going to introduce you to how we incur in a frequently common code smell called "Side Effects," which occurs when a function modifies an external state beyond its own scope.

Cause

Side effects arise when a function alters variables outside its scope, leading to unexpected behaviors and complicating code comprehension.

Example

let total = 0

function addToTotal(value: number): void {
  total += value
  console.log(`Total is now: ${total}`)
}

addToTotal(5)

Solution

An effective solution is to avoid side effects by using pure functions that do not modify external states. Instead of changing global variables, the function should return a new state.

function addToTotal(currentTotal: number, value: number): number {
  const newTotal = currentTotal + value
  console.log(`Total is now: ${newTotal}`)
  return newTotal
}

let currentTotal = 0
currentTotal = addToTotal(currentTotal, 5)

Benefits

Improves Readability: By eliminating side effects, the code becomes clearer and more understandable, making it easier for developers to grasp the execution flow without unexpected surprises.
Facilitates Maintenance: Side-effect-free functions are easier to maintain as their behavior is confined to their scope, avoiding potential conflicts with other parts of the program.
Reduces Unexpected Errors: By avoiding external modifications, the likelihood of subtle errors arising from unexpected changes in variable states is minimized.
Promotes Predictability: Functions without side effects yield consistent results, promoting code predictability and facilitating unit testing.
Enhances Scalability: Code that avoids side effects is more modular and adaptable, easing scalability as the system grows and evolves.

Thanks for reading me 😊

The importance of prioritizing code optimization for humans rather than machine

Jesús Mejías Leiva — Tue, 05 Sep 2023 12:25:01 +0000

In the world of programming, the search for efficiency is a constant. Developers often face the decision to write highly optimized but less readable and maintainable code, or prioritize clarity and ease of maintenance to the detriment of efficiency. In this article, I will present my arguments to justify why in most software projects it is more important to prioritize the optimization of code for humans instead of doing it for machines, highlighting the benefits of maintainability and readability in software development, and why this practice in most cases exceeds the advantages of efficiency.

Long-term maintainability

One of the main arguments in favor of prioritizing the readability and maintainability of the code is the fact that the useful life of most software projects extends far beyond the initial phase of development. As a program evolves and is updated, development teams change, and new developers join the project, a quick and accurate understanding of existing code becomes a critical factor.

If you opt for an extreme optimization approach that sacrifices clarity, it is likely that unnecessary obstacles will be created for future developers. This can result in an increase in maintenance costs, since troubleshooting, bug fixes and updates become more difficult and error-prone.

Effective collaboration

The readability of the code is essential for effective collaboration in software development. Development teams are usually made up of multiple members who work in different parts of the project. The clarity in the code facilitates communication between developers and allows a better understanding of how the various parts of the system work.

When the code is illegible or lacks adequate feedback, collaboration becomes less efficient. Developers can waste time trying to understand what a colleague did or debug problems that could have been avoided with clearer code.

Time and resources

Although extreme optimization can offer efficiency gains in terms of execution speed, these gains are often negligible compared to the time and resources needed to achieve that optimization. The search for extreme efficiency usually requires more development time, which can delay the delivery of the final product.

In addition, the time invested in extreme optimization could be used more effectively in improving functionality, correcting errors or implementing additional features that provide real value to the end user.

Adaptability and scalability

The prioritization of readability and maintainability also translates into greater adaptability and scalability of the software. A well-structured and easy-to-understand code is easier to modify and expand according to the changing needs of the project. In contrast, an excessively optimized code could require significant rewriting to make changes, resulting in greater rigidity and additional costs.

The lowest cost of hardware versus the salary cost of development

In the constant search for efficiency in software development, it is essential to consider how the lower price of hardware today can influence our decisions about code optimization. The reality is that the cost of human resources, in terms of salaries and benefits, is considerably higher than the cost of the hardware needed to run most modern applications.

The evolution of hardware

The technology industry has witnessed surprising advances in computing power and storage capacity over the years. What used to require expensive servers and high-performance equipment in the past, can now be run effectively on much more affordable hardware. Cloud servers and cost-effective web hosting options have democratized access to state-of-the-art hardware resources.

The cost of software development

On the other hand, the cost of hiring and retaining highly trained software developers has increased significantly. Developers are a valuable resource and competitive salaries, benefits, training and retention are essential investments for companies. In addition, as technology advances, the demand for specialized developers also increases, which can lead to greater competition and even higher costs.

Balance between human resources and hardware

From this perspective, the decision to prioritize the optimization of the code for humans, focusing on readability and maintainability, makes even more sense. Even if additional hardware is required to maintain optimal performance, this cost is usually lower compared to the salaries and expenses associated with software development.

When we optimize the code to be clearer and easier to maintain, we reduce the time that developers must invest in understanding and modifying the existing code. This translates into a more efficient use of human resources and, ultimately, long-term cost savings.

Conclusions

While the efficiency in the execution of the code is still important, the cost-benefit ratio of investing in more powerful hardware instead of additional human resources is increasingly evident. Current technology gives us the ability to run applications efficiently on affordable hardware, while the cost of developers remains a significant factor in the development budget.

Therefore, prioritizing code optimization for humans, by improving readability and maintainability, becomes an intelligent economic strategy that benefits both the company and developers, by ensuring efficient and sustainable software development in the long term.

Thanks for reading me 😊

Code smell | Hardcoded fake data in tests

Jesús Mejías Leiva — Sun, 21 May 2023 17:36:33 +0000

Hello, today I am writing again and in this post I am going to introduce you to how we incur in a frequently common code smell called Hardcoded fake data in tests, this code smell occurs when you see fake data that is needed for tests within the same test file.

Cause

When fake data is observed in the test files making them difficult to read and maintain.

Example

Suppose we have the following type to represent a user:

export type User = {
  id: string
  firstName: string
  lastName: string
  email: string
  phone: string
  active: boolean
}

And some functions inside a utils file to apply different filters to an array of users:

export const filterByActivated = (users: User[]): User[] =>
  users.filter((user) => user.active)

export const filterByValidEmail = (users: User[]): User[] => {
  const VALID_EMAIL_REGEX =
    /^(([^<>()[\]\\.,;:\s@"]+(\.[^<>()[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/

  return users.filter((user) => VALID_EMAIL_REGEX.test(user.email))
}

Now let's see how the tests of the functions of our utils would look like:

// utils.test.ts
import { User } from './types/User'
import { filterByActivated, filterByValidEmail } from './utils'

describe('utils', () => {
  it('filterByActivated', () => {
    const mockActivatedUser: User = {
      id: '1',
      firstName: 'Jhon',
      lastName: 'deville',
      email: 'test@test.com',
      phone: '000000000',
      active: true
    }

    const mockDeactivatedUser: User = {
      id: '2',
      firstName: 'Marta',
      lastName: 'deville',
      email: 'test@test.com',
      phone: '100000000',
      active: false
    }

    const activatedUsers = filterByActivated([
      mockActivatedUser,
      mockDeactivatedUser
    ])

    expect(activatedUsers).toEqual([mockActivatedUser])
  })

  it('filterByValidEmail', () => {
    const mockUserWithValidEmail = {
      id: '1',
      firstName: 'Jhon',
      lastName: 'deville',
      email: 'test@test.com',
      phone: '000000000',
      active: true
    }

    const mockUserWithInvalidEmail = {
      id: '2',
      firstName: 'Marta',
      lastName: 'deville',
      email: 'test.com',
      phone: '100000000',
      active: true
    }

    const usersWithValidEmails = filterByValidEmail([
      mockUserWithValidEmail,
      mockUserWithInvalidEmail
    ])

    expect(usersWithValidEmails).toEqual([mockUserWithValidEmail])
  })
})

Apparently it seems like a quite innocuous test but it is hiding several problems that we will find when having to make some change in the User type, for example if we were asked to add a new field to it it would cause a forced modification of all the tests that depend on it. of it and have the fake data hardcoded.

This should not happen and the answer is very simple, why should I modify the test suite if I add a field, for example, to store the user's date of birth? What relationship does this field have with my tests? correct, the answer is none, hence it does not make sense to have to modify them, and this is not the worst, if we extend this practice through our code, as you will suppose, each change in the User type will cause cascading changes of all the tests related to it, which doesn't make any sense.

Solution

To solve this smell we will rely on two libraries, in our case when using typescript we will use the compatible versions of:

Fishery, will help us build factories based on types, in our case we will use User, in this way we will centralize the changes of it in a single point.
Faker-js, provides us with a very complete API to generate fake data of different types randomly.

In the event that your language is not compatible with these libraries, it will be necessary to look for alternatives or build your own small factory utility.

If we put both together we can create users based on a data model with fake random data.

Sounds good right? Let's see how this factory would look like:

// UserFactory.ts
import { Factory } from 'fishery'
import { faker } from '@faker-js/faker'

import { User } from '../types/User'

export default Factory.define<User>(({ sequence }) => ({
  id: `${sequence}`,
  firstName: faker.name.firstName(),
  lastName: faker.name.lastName(),
  email: faker.internet.email(),
  phone: faker.phone.number('+34 ### ### ###'),
  active: faker.datatype.boolean()
}))

Now we will use the factory in our tests as follows:

// utils.test.ts
import userFactory from './factories/userFactory'

import { filterByActivated, filterByValidEmail } from './utils'

describe('userFilter', () => {
  it('filterByActivated', () => {
    const mockActivatedUser = userFactory.build({
      active: true
    })

    const mockDeactivatedUser = userFactory.build({
      active: false
    })

    const activatedUsers = filterByActivated([
      mockActivatedUser,
      mockDeactivatedUser
    ])

    expect(activatedUsers).toEqual([mockActivatedUser])
  })

  it('filterByValidEmail', () => {
    const mockUserWithValidEmail = userFactory.build()

    const mockUserWithInvalidEmail = userFactory.build({
      email: 'test.test'
    })

    const usersWithValidEmails = filterByValidEmail([
      mockUserWithValidEmail,
      mockUserWithInvalidEmail
    ])

    expect(usersWithValidEmails).toEqual([mockUserWithValidEmail])
  })
})

As can be seen, in addition to making our tests much cleaner, we gain a lot in flexibility and maintainability, since if we are now asked to add a field to our User type where we are going to store date of birth, we will only have one modification point, the factory of our tests, in this case our tests do not have to worry about said change.

Benefits

Flexibility
maintainability
Readability
Greater robustness by having to support the cases derived from the creation of content randomly
Type inference if we use typescript

Thanks for reading me 😊

Design pattern | Criteria

Jesús Mejías Leiva — Sun, 19 Mar 2023 12:04:25 +0000

We start this new series with the pattern called Criteria,
This pattern allows you to build search queries using a common interface,
which makes the code much more modular and flexible.

Uses cases without Criteria pattern

I have assembled the examples with Typescript but the implementation of said pattern is equally valid for other languages.

Let's see an example where the use of the Criteria pattern can help us.

First of all we are going to create a very simple type to define what is a Client for our domain:

interface Client {
  name: string;
  age: number;
  gender: 'M' | 'F',
  city: string
}

then suppose we have to perform several filters to the following list of clients:

const clients: Client[] = [
  { name: 'Ana', age: 25, gender: 'F', city: 'Madrid' },
  { name: 'John', age: 15, gender: 'M', city: 'London' },
  { name: 'Marta', age: 14, gender: 'F', city: 'Madrid' },
  { name: 'Luis', age: 30, gender: 'M', city: 'Barcelona' }
]

Clients who are over 15 years old:

const clients: Client[] = [
  { name: 'Ana', age: 25, gender: 'F', city: 'Madrid' },
  { name: 'John', age: 15, gender: 'M', city: 'London' },
  { name: 'Marta', age: 14, gender: 'F', city: 'Madrid' },
  { name: 'Luis', age: 30, gender: 'M', city: 'Barcelona' }
]

clients.filter(client => client.age > 15)

/*
[
  { name: 'Ana', age: 25, gender: 'F', city: 'Madrid' },
  { name: 'Luis', age: 30, gender: 'M', city: 'Barcelona' }
];
*/

Now we are going to complicate the query a bit,
imagine that we are asked to obtain the clients whose age is older than 20 and younger than 30 years old,
who are women and your city is Madrid or Barcelona

const clients: Client[] = [
  { name: 'Ana', age: 25, gender: 'F', city: 'Madrid' },
  { name: 'John', age: 15, gender: 'M', city: 'London' },
  { name: 'Marta', age: 14, gender: 'F', city: 'Madrid' },
  { name: 'Luis', age: 30, gender: 'M', city: 'Barcelona' }
]

clients.filter(client =>
  (client.age > 20 && client.age < 30) &&
  client.gender === "F" &&
  (client.city === 'Madrid' || client.city === 'Barcelona')
)

/*
[
  { name: 'Ana', age: 25, gender: 'F', city: 'Madrid' }
];
*/

As we can see, things start to get complicated and it starts to be difficult to maintain and read,
In addition, at the semantic level there is a large margin for improvement,
for this, we will see how we can improve these aspects by applying the Criteria pattern.

Same complex use case with Criteria pattern

We start by creating the interface that will define our Criteria, we will use typescript generics for it
to gain flexibility:

interface Criteria<T> {
  meetCriteria(items: T[]): T[]
}

We continue creating a Composite class that implements our Criteria interface, it will also allow us to
maintaining an array of criterias to apply and of course the implementation of the required meetCriteria method
upon implementation, the addCriteria method will allow us to add criteria that will function as AND:

class CompositeCriteria<T> implements Criteria<T> {
  private criteriaList: Criteria<T>[] = []

  addCriteria(criteria: Criteria<T>): void {
    this.criteriaList.push(criteria)
  }

  meetCriteria(items: T[]): T[] {
    let result = items

    for (const criteria of this.criteriaList) {
      result = criteria.meetCriteria(result)
    }

    return result
  }
}

Finally, as I mentioned above, the addCriteria when adding criteria to a list would work implicitly
as an AND therefore we will need to make an implementation to be able to do OR operations:

class OrCriteria<T> implements Criteria<T> {
  constructor(private firstCriteria: Criteria<T>, private secondCriteria: Criteria<T>) {}

  meetCriteria(items: T[]): T[] {
    const firstResult = this.firstCriteria.meetCriteria(items)
    const secondResult = this.secondCriteria.meetCriteria(items)

    return Array.from(new Set([...firstResult, ...secondResult]))
  }
}

How to use this new Criteria API

First of all we will create some queries which will help us in the construction of our filter:

const ageOlderThanTwentyYearsCriteria = {
  meetCriteria(items: Client[]): Client[] {
    return items.filter((client) => client.age > 20)
  }
};

const ageYoungerThanThirtyYearsCriteria = {
  meetCriteria(items: Client[]): Client[] {
    return items.filter((client) => client.age < 30)
  }
}

const madridCityCriteria = {
  meetCriteria(items: Client[]): Client[] {
    return items.filter((client) => client.city === 'Madrid')
  }
}

const barcelonaCityCriteria = {
  meetCriteria(items: Client[]): Client[] {
    return items.filter((client) => client.city === 'Barcelona')
  }
}

const femaleCriteria = {
  meetCriteria(items: Client[]): Client[] {
    return items.filter((client) => client.gender === 'F')
  }
}

This is where the magic happens since we will be able to mount the filtering to our liking and with much greater semantics,
I am sure that if I give you this code you will know very quickly which filter is being built:

const clients: Client[] = [
  { name: 'Ana', age: 25, gender: 'F', city: 'Madrid' },
  { name: 'John', age: 15, gender: 'M', city: 'London' },
  { name: 'Marta', age: 14, gender: 'F', city: 'Madrid' },
  { name: 'Luis', age: 30, gender: 'M', city: 'Barcelona' }
]

const compositeCriteria = new CompositeCriteria<Client>()

compositeCriteria.addCriteria(ageOlderThanTwentyYearsCriteria)

compositeCriteria.addCriteria(ageYoungerThanThirtyYearsCriteria)

compositeCriteria.addCriteria(
  new OrCriteria(
    madridCityCriteria,
    barcelonaCityCriteria
  )
)

compositeCriteria.addCriteria(femaleCriteria)

compositeCriteria.meetCriteria(clients)

/* Same result
[
  { name: 'Ana', age: 25, gender: 'F', city: 'Madrid' }
];
*/

Benefits

Better maintainability of code.
Better readability.
Allows you to make complex filters more easily.
Move code to semantics of our domain.

Thanks for reading me 😊

Code Smell | Switch Statements

Jesús Mejías Leiva — Tue, 31 Jan 2023 09:19:02 +0000

Hello, today I am writing again and this post I am going to introduce you to how we incur in a frequently common
code smell called Switch Statements, is caused by the abusive use of the switch statements in our code.

The use of the switch structure is perfectly valid

I do not seek to try to avoid its use in 100% of cases but in a large percentage in which it will harm us.

Cause

The abusive use of the switch statements.

As I mentioned above, it is not always advisable to eliminate the switch, an example of this is the design patterns,
in particular I would highlight the so-called Factory Method or
Abstract Factory, it is very frequent to see its use.

Example

Let's see an example of a switch statement that is not very advisable to use:

type Fruit = 'apple' | 'banana' | 'orange' | 'pineapple' | 'raspberry'

const getFruitEmoji = (fruit: Fruit) => {
  switch (fruit) {
    case 'apple':
      return '🍎'
    case 'banana':
      return '🍌'
    case 'orange':
      return '🍊'
    case 'pineapple':
      return '🍍'
    default:
      return '🍇'
  }
}

Solution

We will replace the switch with a simple object which will allow us to search by key.

type Fruit = 'apple' | 'banana' | 'orange' | 'pineapple' | 'raspberry'

const getFruitEmoji = (fruit: Fruit) => {
  const FRUIT_EMOJI_MAP = {
    apple: '🍎',
    banana: '🍌',
    orange: '🍊',
    pineapple: '🍍',
    raspberry: '🍇'
  }

  return fruitEmojiMap[fruit] 
}

I have created a small example to show one of the most common ways to eliminate this smell,
especially in functional programming, the example could be more complicated if instead of emojis with function calls,
but the way to proceed would be the same.

To correct this smell in object-oriented programming, it is common to use polymorphism if necessary,
we must always analyze our code beforehand.

Benefits

Less code.
Improves legibility.
Improves maintainability, you can export this object and use in a others parts of your application.

Thanks for reading me 😊

Code Smell | Too Many Imports

Jesús Mejías Leiva — Thu, 20 Oct 2022 10:43:34 +0000

Hello, today I am writing again and this time I am going to introduce you to how we incur in a very common code smell called Too Many Import, is caused by the abusive use of imports in components, classes or any other type of module of our project.

Cause

It seems like a very harmless Code Smell but it can indicate that we are breaking very important principles such as:

Coupling
Low cohesion
Violation of the SRP (Single Responsibility Principle)

Example

In the following example we can see how up to 13 imports are carried out, which should lead us to think if our component does not have too many responsibilities:

import one from "...";
import two from "...";
import three from "...";
import four from "...";
import five from "...";
import six from "...";
import seven from "...";
import eight from "...";
import nine from "...";
import ten from "...";
import eleven from "...";
import twelve from "...";
import thirteen from "...";


export default function Example() {
  //... code
}

Solutions

In the first place, it may seem a bit obvious, but we should review the use of these imports and assess if they are all essential for the correct functioning of the component.
As you can imagine, the solution to this involves separating responsibilities and dividing this component into several smaller ones or even extracting logic to hooks, although in this case, in order not to introduce many concepts, we will propose a solution based on dividing it into several smaller components:

FirstComponent

import one from "...";
import two from "...";
import three from "...";
import four from "...";
import five from "...";

export default function FirstComponent() {
  //... code
}

SecondComponent

import six from "...";
import seven from "...";
import eight from "...";
import nine from "...";

export default function SecondComponent() {
  //... code
}

ThirdComponent

import ten from "...";
import eleven from "...";
import twelve from "...";
import thirteen from "...";

export default function ThirdComponent() {
  //... code
}

Finally the ExampleComponent , it would stay like this:

import FirstComponent from "./FirstComponent";
import SecondComponent from "./SecondComponent";
import ThirdComponent from "./ThirdComponent";

export default function Example() {
  //... code
}

We can see that we have reduced the number of import by a large number, but this does not end here, by making this division we are delegating the responsibilities to each component.

Warning!

Therefore, like every Code Smell, this one must be carefully analyzed before applying any solution, since a hasty decision can cause some side effects.

Not all are advantages, below we will see some disadvantages that we must consider when applying these splits:

In some cases we can incur in a premature optimization, especially in small projects that do not need much maintenance.
They can have many components, classes etc if the project has considerable dimensions.

Bonus Track

To help us take more into account the number of imports we can use our linter, for example in the case of using eslint we have a rule inside the eslint-plugin-import plugin called import/max-dependencies
which we can configure to help us with this smell.

Thanks for reading me 😊

Code Smell | Magic Numbers

Jesús Mejías Leiva — Tue, 16 Aug 2022 12:30:00 +0000

Hello, today we are back with the code smells refactoring series and in this case we are going to talk about code smell called Magic Numbers, this code smell can be detect when we use a number that lacks the proper semantics.

Cause

Numbers lacking semantics make calculations harder to read.

Example

As we can see in the following example we have 2 magic numbers that are quite easy to detect since it is really complex to know what type of calculation we are performing simply by observing these values: 4.50 and 0.21

function calculateTotal(subtotal) {
  const total = subtotal + 4.50;
  return total + (total * 0.21);
}

Solution

By extracting both numbers to constants and giving them semantics we can see that the code is much more readable.

const SHIPPING_FEE = 4.50;
const SALES_TAX = 0.21;

function calculateTotal(subtotal) {
  const total = subtotal + SHIPPING_FEE;
  return total + (total * SALES_TAX);
}

Benefits

Improvement the readability and maintainability of the code.
You will make the next person who needs to go through that part of the code very happy 😋 jiji

Thanks for reading me 😊

Standardize imports with ESLint

Jesús Mejías Leiva — Fri, 08 Jul 2022 09:18:41 +0000

Adding this configuration will significantly improve the readability of our imports since they will follow a standard which we will define in said rule, let's see some small examples.

Requirements

In this article it will be assumed that ESLint is already configured in the project, if you do not have any configuration you must follow the official documentation that I attach here: ESLint configuring.

We will also need to install the following library with npm or yarn:

Npm:

npm install eslint-plugin-import --save-dev

Yarn:

yarn add -D eslint-plugin-import

Imports without rule 🤨

As can be seen, the ordering and grouping that is followed does not follow any criteria and what is even worse is that in other files they will follow different or even opposite criteria.

import React from 'react'
import AnotherComponent from './AnotherComponent'
import dayjs from 'dayjs';
import styles from './styles.module.scss'
import _ from 'lodash';

ESLint to rescue 🛟

Within our ESLint configuration file we will add the following rule, in this example I will use a configuration of my preference, if you need more information I will leave you here a link to the official documentation.

{
  "import/order": [
    "error",
    {
      "newlines-between": "always",
      "groups": [
        ["builtin"],
        ["external"],
        ["parent", "internal", "sibling", "index", "unknown"]
      ],
      "alphabetize": {
        "order": "asc",
        "caseInsensitive": true
      }
    }
  ]
}

It is important to note that to fix all the "errors" in existing imports that this rule will cause, it is recommended to use the --fix flag to automate the resolution of said "errors".

Imports with rule 🥰

We can see that everything is much more readable since with a simple glance we will be able to identify the imports of external and internal packages that are used in said file and the best thing is that in this way we unify criteria in all the imports of our application.

import dayjs from "dayjs";
import _ from "lodash";
import React from 'react'

import AnotherComponent from './AnotherComponent'
import styles from './styles.module.scss'

You can see more complex examples here.

Conclusions

As we have seen, adding this rule gives us a very good cost vs benefit since with a very basic configuration we obtain the great benefit of being able to have a standard in all the imports of our project, something that is really useful if you work with several people.

Thanks for reading me 😊

Code Smell | Data Clumps

Jesús Mejías Leiva — Tue, 24 May 2022 12:04:10 +0000

Hello, today we are back with the code smells refactoring series and in this case we are going to talk about code smell called Data Clumps, this code smell can be detected when we observe that certain groups of data are being used in different parts of our code.

Cause

Set of data elements, whether simple primitives, value types, or even complex types, are constantly passed together through different sections of your code base.

Example

We can see that the MarsRover class receives the value of the X and Y coordinates as a parameter, which at first is not necessarily a bad thing, right?

class MarsRover {
  constructor(private x: number, private y: number, private direction: string){
    //...
  }

  move() {
    //...
  }

  //...
}


// Use of the class
new MarsRover(100, 200, 'Example direction');

Solution

The use of X and Y as a separate set does not have to be harmful, but it can cause us different problems such as lack of cohesion, complexity when validating said data and, above all, duplication of associated logic in different parts of our code, let's see how we can fix this little smell:

class Coordinates {
  constructor(private x: number, private y: number) {
    //...
  }

  getX() {
    return this.x;
  }

  getY() {
    return this.y;
  }
}

class MarsRover {
  constructor(private coordinates: Coordinates, private direction: string){
    //...
  }

  move() {
    //...
  }
}

// Use of the class
new MarsRover(
  new Coordinates(100, 200), 
  'Example direction'
);

At first glance, in this simple example, it does not seem that we gain much from this change, but we are giving a data set its own entity, which provides semantics and long-term maintainability to our code.

Benefits

Improves readability: you can shrink a lot of parameter lists and simplify method calling, in addition to providing semantics.
Improves maintainability: we avoid falling into the code smell of shotgun surgery and in this way we facilitate the management of possible changes.

If we are asked for any change regarding new logic or coordinate validation, we will be very clear about where to add it, within our Coordinates class, in addition to being able to reuse it in different parts of our code that requires coordinate treatment.

Thanks for reading me 😊

Code Smell | Shotgun surgery

Jesús Mejías Leiva — Wed, 16 Mar 2022 13:10:40 +0000

Hello, today we are back with the code smells refactoring series and in this case we are going to talk about code smell called Shotgun Surgery, this smell can be detected if making a change have to replicate this change in different parts of our code

Cause

A single responsibility has been split up among a large number of sites. This can happen after the overzealous application of Divergent Change

Example

We can see that the minimum balance check is being duplicated in both methods

class Account {
  private amount: number;

  constructor(amount: number) {
    this.amount = amount;

    //...
  }

 debit(debitAmount: number): void {
    if (this.amount <= 1000) {
      throw new Error('Minimum balance should be over 1000');
    }

    //...
  }

  transfer(from: Account, to: Account, transferAmount: number): void {
    if (from.amount <= 1000) {
      throw new Error('Minimum balance should be over 1000');
    }

    //...
  }
}

Solution

Extract minimum balance checks to method to be able to reuse it in the different methods of the class

class Account {
  private amount: number;

  constructor(amount: number) {
    this.amount = amount;

    //...
  }

  assertMinimumBalance(amount: number): void {
    const MINIMUM_AMOUNT = 1000;

    if (amount <= MINIMUM_AMOUNT) {
      throw new Error(`Minimum balance should be over ${MINIMUM_AMOUNT}`);
    }
  }

  debit(debitAmount: number): void {
    this.assertMinimumBalance(this.amount);

    //...
  }

  transfer(from: Account, to: Account, transferAmount: number): void {
    this.assertMinimumBalance(from.amount);

    //...
  }
}

Bonus track

Shotgun surgery in CSS? 🤔

Yes, see the next example:

.button-primary {
  background-color: #ec407a;
}

.button-secondary {
  background-color: #b4004e;
}

.navbar-primary {
  background-color: #ec407a;
}

.navbar-secondary {
  background-color: #b4004e;
}

If now they ask us to modify the primary color for another, what is the solution? Search globally in all our CSS and replace it? NOOO!! ⛔️

The solution is use CSS variables:

We can declare variables in CSS globally with the pseudo-class :root and thus use them in any part of our CSS, in this way we centralize the possible changes in only the variables, thus avoiding having to replace each color value


:root {
  --primary-background: #ec407a;
  --secondary-background: #b4004e;
}

.button-primary {
  background-color: var(--primary-background);
}

.button-secondary {
  background-color: var(--secondary-background);
}

.navbar-primary {
  background-color: var(--primary-background);
}

.navbar-secondary {
  background-color: var(--secondary-background);
}

Thanks for reading me 😊

Code Smell | Divergent change

Jesús Mejías Leiva — Mon, 21 Feb 2022 13:21:30 +0000

Hello, today we are back with the code smells refactoring series and in this case we are going to talk about code smell called Divergent Change, this smell can be detected when we observe that at a specific point in our application we perform too many changes, these points can be a certain class, a .js or .ts file that exports certain functions, etc

A small tip to be able to detect it easily is usually when conflicts occur repeatedly in a certain file, it is usually very likely that this file is complying with the code smell of Divergent change, WARNING: Take with caution not always will comply with this rule, you have to review the code before acting

Cause

The module have many responsibilities
The context of changes is not clear from day one but new changes are still being implemented in the application

class Hero {
  stamina: number;
  health: number;
  armorHealth: number;
  armorStatus: number;
  armorRarity: string;

  defense(): void {
   // ...
  }

  attack(): void {
   // ...
  }
}

Solution

Split the class using Extract Class:

class Hero {
  stamina: number;
  health: number;
  armor: Armor;

  attack(): void {
   // ...
  }

  defense(): void {
   // ...
  }
}

class Armor {
  health: number;
  status: number;
  rarity: string;

  getHealth(): number {
    // ...
  }
}

Benefits

Maintain adherence to the Single Responsibility Principle
More reliable and tolerant of changes
Add semantics to the code

Thanks for reading me 😊

Code Smell | Primitive Obsession

Jesús Mejías Leiva — Mon, 29 Nov 2021 16:57:54 +0000

Hello, today I am writing again and this time I am going to introduce you to how we incur in a very common code smell called Primitive Obsession, this code smell is given by the abusive use of primitive types when modeling our classes, was it not very clear? let's go with a reduced example:

class User {
  #locale: string;
  #age: number;
  #email: string;

  #SPANISH_LANGUAGE: string = "es";
  #UNDERAGE_UNTIL_AGE: number = 18;
  #EMAIL_REGEX: RegExp = /^(([^<>()\[\]\\.,;:\s@"]+(\.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/;

  constructor(locale: string, age: number, email: string) {
    this.#locale = locale;
    this.#age = age;
    this.#email = email;

    if (!this.isValidEmail()) throw new Error("Invalid email format");
  };

  understandSpanish(): boolean {
    const language = this.#locale.substring(0, 2);

    return language === this.#SPANISH_LANGUAGE;
  };

  isOlderAge(): boolean {
    return this.#age >= this.#UNDERAGE_UNTIL_AGE;
  };

  isValidEmail(): boolean {
    return this.#EMAIL_REGEX.test(this.#email);
  };
}

const user = new User("es", 18, "test@email.com");

user.understandSpanish(); // true
user.isOlderAge(); // true
user.isValidEmail(); // true

You might be thinking, Well, it's not so bad, right?

This example, being small, can be a bit misleading, but as the code of our User class begins to grow, we will begin to see more clearly that there is still some logic that we have within the class that we could abstract so that our class looks much better

Our best friends: Value Objects

A value object is simply a modeling of a primitive type, let's see an example:

class Email {
  #email: string;
  #EMAIL_REGEX: RegExp = /^(([^<>()\[\]\\.,;:\s@"]+(\.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/;

  constructor(email: string) {
    this.#email = email;

    if (!this.isValid()) throw new Error("Invalid email format");
  };

  isValid(): boolean {
    return this.#EMAIL_REGEX.test(this.#email);
  };

  value(): string {
    return this.#email;
  };
}

new Email("suso@gmail.com").value(); // "suso@gmail.com"
new Email("susogmail.com").value(); // Error: Invalid email format

As we can see, we are simply creating an abstraction of a primitive string type, within which we are adding logic to validate that the email we receive is valid, in this way we can reuse this VO in different parts of our application

What advantages does a VO offer me?

Immutability
Greater robustness in validations
Greater semantics, better readability in the class signature
Logic magnet
Helps IDE/editor autocomplete
They simplify the API
They can be reused in various parts of our application as they are not coupled to any class

Refactoring time

Initial state:

class User {
  #locale: string;
  #age: number;
  #email: string;

  #SPANISH_LANGUAGE: string = "es";
  #UNDERAGE_UNTIL_AGE: number = 18;
  #EMAIL_REGEX: RegExp = /^(([^<>()\[\]\\.,;:\s@"]+(\.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/;

  constructor(locale: string, age: number, email: string) {
    this.#locale = locale;
    this.#age = age;
    this.#email = email;

    if (!this.isValidEmail()) throw new Error("Invalid email format");
  };

  understandSpanish(): boolean {
    const language = this.#locale.substring(0, 2);

    return language === this.#SPANISH_LANGUAGE;
  };

  isOlderAge(): boolean {
    return this.#age >= this.#UNDERAGE_UNTIL_AGE;
  };

  isValidEmail(): boolean {
    return this.#EMAIL_REGEX.test(this.#email);
  };
}

Split User class code into three value objects: Locale, Age and Email

Locale

class Locale {
  #locale: string;
  #SPANISH_LANGUAGE: string = "es";

  constructor(locale: string) {
    this.#locale = locale;
  };

  understandSpanish(): boolean {
    const language = this.#locale.substring(0, 2);

    return language === this.#SPANISH_LANGUAGE;
  };

  value(): string {
    return this.#locale;
  };
}

Age

class Age {
  #age: number;
  #UNDERAGE_UNTIL_AGE: number = 18;

  constructor(age: number) {
    this.#age = age;
  };

  isOlderAge(): boolean {
    return this.#age >= this.#UNDERAGE_UNTIL_AGE;
  };

  value(): number {
    return this.#age;
  };
}

Email

class Email {
  #email: string;
  #EMAIL_REGEX: RegExp = /^(([^<>()\[\]\\.,;:\s@"]+(\.[^<>()\[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/;

  constructor(email: string) {
    this.#email = email;

    if (!this.isValid()) throw new Error("Invalid email format");
  };

  isValid(): boolean {
    return this.#EMAIL_REGEX.test(this.#email);
  };

  value(): string {
    return this.#email;
  };
}

Finally the User class, it would stay like this:

class User {
  #locale: Locale;
  #age: Age;
  #email: Email;

  constructor(locale: Locale, age: Age, email: Email) {
    this.#locale = locale;
    this.#age = age;
    this.#email = email;
  };

  understandSpanish(): boolean {
    return this.#locale.understandSpanish();
  };

  isOlderAge(): boolean {
    return this.#age.isOlderAge();
  };
}

As you can see in this way, we manage to encapsulate each functionality in its corresponding value object in such a way that the user class is not responsible for carrying out any validation, so that we will achieve a more readable and maintainable code over time

Using new refactored User class:

// with valid email
const user1 = new User(
  new Locale("es"), 
  new Age(18),
  new Email("suso@gmail.com")
);

user1.understandSpanish(); // true


// with invalid email
const user2 = new User(
  new Locale("es"), 
  new Age(18),
  new Email("susogmail.com")
);

user2.understandSpanish(); // Error: Invalid email format

Warning!

Not all are advantages, below we will see some disadvantages that we must consider when applying these abstractions:

In some cases we can incur in a premature optimization, especially in small projects that do not need much maintenance
They can have many classes if the project has considerable dimensions

Thanks for reading me 😊