Do you have a minute or two to talk about Code Smells? - Part 1

#cleancode #codesmells #refactoring #designpatterns

Hello, you probably have already studied a lot about what are good programming practices, in this series of articles I will explain in more detail what NOT to DO in software development, explaining what are some Code Smells that maybe most of the developers people have ever done in your life.

First of all, what are Code Smells?

They are symptoms of superficial errors of a deeper problem in your code, you can see a more complete definition in this article by Martin Fowler: Code Smells

This series of articles will demonstrate some Code Smells that can occur in different programming languages and give some tips on how to solve them.
In this first article I'm going to talk about Code Smell's Bloaters:

Bloaters are codes, methods and classes that over time have taken on gigantic proportions that make the system difficult to maintain and scale. We usually only notice this type of smells when the system grows and makes a change or adds a new feature. These are the codes that are written “in the wrong way”, and become a technical debt that, over time, only increases.

The first example of a Code Smell of the Bloater type is Data Clumps (Grouping of all):

Often different parts of code contain identical groups of variables (configuration parameters, access routes, etc.), ideally these groups should be transformed into classes to be accessed without repeating these same parameters in various parts of the code.

It usually occurs due to the lack of a modularized structure and frequent “copy and paste” throughout development.

How to fix this problem?

Here are some suggestions of what to do in these cases:

Realize Preserve Whole Object (when we have several values of an object and pass it as a parameter to a method, we can pass it as an object containing this data, more details about this technique at: Preserve Whole Object.

Apply Introduce Parameter Object (when your methods contain a group of repeated parameters, we can replace it with an object, somewhat similar to the previous one, more details at:Introduce parameter object .

If the repetition of these fields makes sense to be in a separate class to access this data through ** Extract Class ** (when one class is doing the work of two, it is not following the principle of single responsibility (SRP), we can extract these methods for a new class and insert all the methods and fields related to its functionality, more details at: Extract class.

This was a type of Code Smell, in the next articles I will address others, here are some references I used and study tips on the subject:

Preserve Whole Object

Introduce Parameter Object

Introduce Parameter Object
https://refactoring.guru/extract-class

Extract Class

Solid Principles

SOLID