¿Hey, como estas? Espero que estuvieras esperando para ver cómo hacemos esta refactorización. Si no has leido el artículo anterior, definitivamente deberías hacerlo en [este link](https://www.patferraggi.dev/blog/2020/mar/noble-refactoring-0/), ya que hoy haremos la refactorización y agregaremos esa `feature` pendiente en nuestro backlog.

***

## La refactorización

Entonces, sin más preámbulos, comencemos.
Primero, no se vos, pero a mi no me gusta ese `for loop` y acceder a los elementos mediante *i*, así que eliminemos eso usando un `forEach` para hacer que el código sea mas claro.

```javascript
this.items.forEach(item => {
  if (item.name != "Sulfuras, Hand of Ragnaros") {
    item.sellIn = item.sellIn - 1
  }
  if (
    item.name != "Aged Brie" &&
    item.name != "Backstage passes to a TAFKAL80ETC concert"
  ) {
    if (item.quality > 0) {
      if (item.name != "Sulfuras, Hand of Ragnaros") {
        item.quality = item.quality - 1
      }
    }
  } else {
    if (item.quality < 50) {
      item.quality = item.quality + 1
      if (item.name == "Backstage passes to a TAFKAL80ETC concert") {
        if (item.sellIn < 11) {
          if (item.quality < 50) {
            item.quality = item.quality + 1
          }
        }
        if (item.sellIn < 6) {
          if (item.quality < 50) {
            item.quality = item.quality + 1
          }
        }
      }
    }
  }
  if (item.sellIn < 0) {
    if (item.name != "Aged Brie") {
      if (item.name != "Backstage passes to a TAFKAL80ETC concert") {
        if (item.quality > 0) {
          if (item.name != "Sulfuras, Hand of Ragnaros") {
            item.quality = item.quality - 1
          }
        }
      } else {
        item.quality = item.quality - item.quality
      }
    } else {
      if (item.quality < 50) {
        item.quality = item.quality + 1
      }
    }
  }
})
```

Ahora, me gustaría extraer cada expresión booleana en su propia variable para que quede de manera explícita, esto se llama [Extraer Variable](https://refactoring.guru/extract-variable) y de esta manera podemos evitar tener que llevar toda esa complejidad dentro de la cabeza.
Al dar nombres significativos a las expresiones, el código se vuelve mas limpio automáticamente, si te interesa el código limpio o `clean code`, te recomiendo que leas mi artículo anterior, puedes encontrarlo [aquí](https://dev.to/patferraggi/5-clean-code-technologies-you-can-start-doing-today-2ifh).
También me gustaría cambiar los aumentos y disminuciones por algo como ++ y -.

```javascript
this.items.forEach(item => {
  const isSulfuras = item.name == "Sulfuras, Hand of Ragnaros"

  if (!isSulfuras) {
    item.sellIn--
  }

  const isAgedBrie = item.name == "Aged Brie"
  const isBackstagePasses =
    item.name == "Backstage passes to a TAFKAL80ETC concert"
  const isQualityBiggerThan0 = item.quality > 0
  const isQualityLessThan50 = item.quality < 50
  // notice how I changed this 2 properties so
  // they look more to what we are expecting from them
  const tenDaysOrLessToSell = item.sellIn <= 10
  const fiveDaysOrLessToSell = item.sellIn <= 5
  const areNoMoreDaysToSell = item.sellIn < 0

  if (!isAgedBrie && !isBackstagePasses) {
    if (isQualityBiggerThan0) {
      if (!isSulfuras) {
        item.quality--
      }
    }
  } else {
    if (isQualityLessThan50) {
      item.quality++
      if (isBackstagePasses) {
        if (tenDaysOrLessToSell) {
          if (isQualityLessThan50) {
            item.quality++
          }
        }
        if (fiveDaysOrLessToSell) {
          if (isQualityLessThan50) {
            item.quality++
          }
        }
      }
    }
  }

  if (areNoMoreDaysToSell) {
    if (!isAgedBrie) {
      if (!isBackstagePasses) {
        if (isQualityBiggerThan0) {
          if (!isSulfuras) {
            item.quality--
          }
        }
      } else {
        item.quality = 0
      }
    } else {
      if (isQualityBiggerThan0) {
        item.quality++
      }
    }
  }
})
```

Mucho mejor, aunque la lógica sigue siendo muy fea, ya comenzamos a ver algo de expresividad en el código. Todas las pruebas estan en `verde` así que sigamos adelante.
Ahora, me gustaría comenzar a unificar `ifs`, esto es parte de [Simplificar Expresiones Condicionales](https://refactoring.guru/refactoring/techniques/simplifying-conditional-expressions), como ya puedes ver tenemos algunas líneas de código como la siguiente:

```javascript
if (tenDaysOrLessToSell) {
  if (isQualityLessThan50) {
    item.quality++
  }
}
```

Como solo hay una ruta para que el código siga al ingresar a este bloque, podemos unificar esos `ifs` en algo como esto:

```javascript
if (tenDaysOrLessToSell && isQualityLessThan50) {
  item.quality++
}
```

así que unifiquemos todos los `ifs` que podamos:

```javascript
this.items.forEach(item => {
  const isSulfuras = item.name == "Sulfuras, Hand of Ragnaros"

  if (!isSulfuras) {
    item.sellIn--
  }

  const isAgedBrie = item.name == "Aged Brie"
  const isBackstagePasses =
    item.name == "Backstage passes to a TAFKAL80ETC concert"
  const isQualityBiggerThan0 = item.quality > 0
  const isQualityLessThan50 = item.quality < 50
  // notice how I changed this 2 properties so
  // they look more to what we are expecting from them
  const tenDaysOrLessToSell = item.sellIn <= 10
  const fiveDaysOrLessToSell = item.sellIn <= 5
  const areNoMoreDaysToSell = item.sellIn < 0
  const isNormalItem = !isAgedBrie && !isBackstagePasses && !isSulfuras

  if (isNormalItem) {
    if (isQualityBiggerThan0) {
      item.quality--
    }
  } else if (isQualityLessThan50) {
    item.quality++
    if (isBackstagePasses) {
      if (tenDaysOrLessToSell) {
        item.quality++
      }

      if (fiveDaysOrLessToSell) {
        item.quality++
      }
    }
  }

  if (areNoMoreDaysToSell) {
    if (!isAgedBrie) {
      if (!isBackstagePasses) {
        if (isQualityBiggerThan0 && !isSulfuras) {
          item.quality--
        }
      } else {
        item.quality = 0
      }
    } else if (isQualityBiggerThan0) {
      item.quality++
    }
  }
})
```

Como puedes ver, después de unificar todos los `ifs`, algunos patrones comunes comenzaron a aparecer y hacen notar que cierta lógica para las expresiones booleanas se encuentra duplicada en muchas partes de este método, por lo que las extraeremos.

```javascript
const isNormalItem = !isAgedBrie && !isBackstagePasses && !isSulfuras
```

Una vez que llegamos a este punto, nos damos cuenta de que hay algunos problemas con este código, básicamente lo que está sucediendo es que tenemos lógica para múltiples casos dispersos por todo el método, estamos verificando `Brie` y `Backstage passes` en muchos lugares diferentes, debemos organizar esa lógica con una refactorización similar a [Consolidar Expresiónes Condicionales](https://refactoring.guru/consolidate-conditional-expression). Este será un gran movimiento, pero hará que nuestro código sea increíblemente más fácil de leer.

```javascript
    this.items.forEach(item => {
      const isSulfuras = item.name == "Sulfuras, Hand of Ragnaros";

      if (!isSulfuras) {
        item.sellIn--;
      }

      const isAgedBrie = item.name == "Aged Brie";
      const isBackstagePasses =
        item.name == "Backstage passes to a TAFKAL80ETC concert";
      const isQualityBiggerThan0 = item.quality > 0;
      const isQualityLessThan50 = item.quality < 50;
      const tenDaysOrLessToSell = item.sellIn <= 10;
      const fiveDaysOrLessToSell = item.sellIn <= 5;
      const areNoMoreDaysToSell = item.sellIn < 0;
      const isNormalItem = !isAgedBrie && !isBackstagePasses && !isSulfuras;

      if (isNormalItem) {
        if (isQualityBiggerThan0) {
          item.quality--;

          if (areNoMoreDaysToSell) {
            item.quality--;
          }
        }
      } else if (isBackstagePasses) {
        item.quality++;
        if (tenDaysOrLessToSell) {
          item.quality++;
        }

        if (fiveDaysOrLessToSell) {
          item.quality++;
        }

        if (areNoMoreDaysToSell) {
          item.quality = 0;
        }
      } else if (isAgedBrie && isQualityLessThan50) {
        item.quality++;
      }
```

Como puedes ver ahora, está bastante claro lo que está sucediendo, un artículo puede ser `Sulfuras` que no se preocupa por la `Quality` o `SellIn`, puede ser un `Normal Item`, puede ser `Backstage Passes` pasa o puede ser `Aged Brie`, cada uno de esos casos tiene su lógica contenida en su propio `if`. Aún queda trabajo por hacer.

¿Por qué no continuamos extrayendo los diferentes comportamientos en funciones separadas?, para ser claros, también podría hacer una orientación clásica de objetos y separar los comportamientos en una jerarquía de clases con un `factory design pattern` para hacer una refactorización como [Reemplazar Condicional con Polimorfismo](https://refactoring.guru/replace-conditional-with-polymorphism) pero pensé que ya que estamos usando *JavaScript* sigamos usando funciones.

```javascript
const calculateQualityDifferenceNormalItem = ({ sellIn, quality }) => {
  const isQualityBiggerThan0 = quality > 0
  const areNoMoreDaysToSell = sellIn < 0

  if (isQualityBiggerThan0 && areNoMoreDaysToSell) return -2
  if (isQualityBiggerThan0) return -1

  return 0
}

const calculateQualityDifferenceBackstagePasses = ({ sellIn, quality }) => {
  const tenDaysOrLessToSell = sellIn <= 10
  const fiveDaysOrLessToSell = sellIn <= 5
  const areNoMoreDaysToSell = sellIn < 0

  if (areNoMoreDaysToSell) return -quality
  if (fiveDaysOrLessToSell) return +3
  if (tenDaysOrLessToSell) return +2

  return +1
}

const calculateSellinDifference = ({ sellIn, name }) => {
  const isSulfuras = name == "Sulfuras, Hand of Ragnaros"
  return !isSulfuras ? -1 : 0
}
```

Observa cómo también intenté eliminar un poco la mutación de estado haciendo que estas funciones fueran puras simplemente procesando el `Quality` o `SellIn` y devolviendo un resultado sin modificar el item en sí. Ahora nuestro método `updateQuality` se ve así:

```javascript
  updateQuality() {
    this.items.forEach(item => {
      item.sellIn += getUpdatedSellin(item);

      const isSulfuras = item.name == "Sulfuras, Hand of Ragnaros";
      const isAgedBrie = item.name == "Aged Brie";
      const isBackstagePasses =
        item.name == "Backstage passes to a TAFKAL80ETC concert";
      const isQualityLessThan50 = item.quality < 50;
      const isNormalItem = !isAgedBrie && !isBackstagePasses && !isSulfuras;

      if (isNormalItem) {
        item.quality += getUpdatedQualityNormalItem(item);
      } else if (isBackstagePasses) {
        item.quality += getUpdatedQualityBackstagePasses(item);
      } else if (isAgedBrie && isQualityLessThan50) {
        item.quality++;
      }
    });

    return this.items;
  }
```

Ahora, hagamos lo mismo y extraigamos la lógica con respecto al `Quality`, cambiemos ese `foreach` por un `map`, y veamos la version final del método `updateQuality`:

```javascript
class Item {
  constructor(name, sellIn, quality) {
    this.name = name
    this.sellIn = sellIn
    this.quality = quality
  }
}

const calculateQualityDifferenceNormalItem = ({ sellIn, quality }) => {
  const isQualityBiggerThan0 = quality > 0
  const areNoMoreDaysToSell = sellIn < 0

  if (isQualityBiggerThan0 && areNoMoreDaysToSell) return -2
  if (isQualityBiggerThan0) return -1

  return 0
}

const calculateQualityDifferenceBackstagePasses = ({ sellIn, quality }) => {
  const tenDaysOrLessToSell = sellIn <= 10
  const fiveDaysOrLessToSell = sellIn <= 5
  const areNoMoreDaysToSell = sellIn < 0

  if (areNoMoreDaysToSell) return -quality
  if (fiveDaysOrLessToSell) return +3
  if (tenDaysOrLessToSell) return +2

  return +1
}

const calculateSellinDifference = ({ sellIn, name }) => {
  const isSulfuras = name == "Sulfuras, Hand of Ragnaros"
  return !isSulfuras ? -1 : 0
}

const calculateQualityDifference = item => {
  const isSulfuras = item.name == "Sulfuras, Hand of Ragnaros"
  const isAgedBrie = item.name == "Aged Brie"
  const isBackstagePasses =
    item.name == "Backstage passes to a TAFKAL80ETC concert"
  const isQualityLessThan50 = item.quality < 50
  const isNormalItem =
    !isAgedBrie && !isBackstagePasses && !isSulfuras && !isConjuredItem

  if (isNormalItem) return calculateQualityDifferenceNormalItem(item)
  if (isBackstagePasses) return calculateQualityDifferenceBackstagePasses(item)
  if (isAgedBrie && isQualityLessThan50) return +1

  return 0
}

class Shop {
  constructor(items = []) {
    this.items = items
  }

  updateQuality() {
    return this.items.map(item => {
      item.sellIn += calculateSellinDifference(item)
      item.quality += calculateQualityDifference(item)

      return item
    })
  }
}
```

Eso es todo, ahora que estamos aqui ya podemos comenzar a trabajar en la parte de agregar la nueva funcionalidad.

## Agregar la función

¿De qué se trataba esta funcionalidad?

> Recientemente hemos firmado un proveedor de artículos conjurados. Esto requiere una actualización de nuestro sistema:
> Los elementos `Conjured` se degradan en calidad dos veces más rápido que los elementos normales

¿Qué cambiamos primero?

\*\* INCORRECTO \*\*

Primero, escribimos una prueba.

```javascript
it("the quality of conjured items should decrease twice as fast", () => {
  const storeItems = [new Item("Conjured Mana Cake", 10, 20)]
  const expectedResult = [new Item("Conjured Mana Cake", 9, 18)]
  const gildedRose = new Shop(storeItems)
  const items = gildedRose.updateQuality()

  expect(items).toStrictEqual(expectedResult)
})
```

Obviamente, esto fallará, un poco de Test Driven Development para darnos seguridad. Ahora podemos comenzar a agregar la nueva funcionalidad de manera segura.

* Agregamos una forma de buscar elementos conjurados, esos elementos tendrán la palabra `Conjured` en su nombre, así que:

```javascript
const isConjuredItem = item.name.includes("Conjured")
```

* Declaramos explícitamente en nuestro código que los elementos conjurados no son elementos normales al hacer lo siguiente:

```javascript
const isNormalItem =
  !isAgedBrie && !isBackstagePasses && !isSulfuras && !isConjuredItem
```

* Agregamos la condición para calcular la diferencia en `Quality`, aquí solo reutilizamos código para hacernos la vida mucho más fácil:

```javascript
if (isConjuredItem) return calculateQualityDifferenceNormalItem(item) * 2
```

* Montamos todo junto en el método que calcula la diferencia de `Quality`:

```javascript
const calculateQualityDifference = item => {
  const isSulfuras = item.name == "Sulfuras, Hand of Ragnaros"
  const isAgedBrie = item.name == "Aged Brie"
  const isConjuredItem = item.name.includes("Conjured")
  const isBackstagePasses =
    item.name == "Backstage passes to a TAFKAL80ETC concert"
  const isQualityLessThan50 = item.quality < 50
  const isNormalItem =
    !isAgedBrie && !isBackstagePasses && !isSulfuras && !isConjuredItem

  if (isNormalItem) return calculateQualityDifferenceNormalItem(item)
  if (isBackstagePasses) return calculateQualityDifferenceBackstagePasses(item)
  if (isAgedBrie && isQualityLessThan50) return +1
  if (isConjuredItem) return calculateQualityDifferenceNormalItem(item) * 2

  return 0
}
```

* Corremos las pruebas

![prueba verde](https://dev-to-uploads.s3.amazonaws.com/i/quibo81aolj60j9yu2zt.png)

## ¡HEMOS TERMINADO!

Felicitaciones, después de largas horas refactorizando este código, agregamos la función especificada, no solo eso, sino que aumentamos mucho la calidad general del software.

Si estás interesado en refactorizar, te recomiendo [Refactorización: Mejora del diseño del código existente](https://www.amazon.com/-/es/Martin-Fowler/dp/0134757599/ref=pd_sbs_14_t_0/133-9591133-9013653?_encoding=UTF8\&pd_rd_i=0134757599\&pd_rd_r=6d5cfc6d-3bc8-44ef-a4df-4926f04f8adf\&pd_rd_w=iZeJC\&pd_rd_wg=582cX\&pf_rd_p=5cfcfe89-300f-47d2-b1ad-a4e27203a02a\&pf_rd_r=3VA8TRMT2V5QYYG5JJ3N\&psc=1\&refRID=3VA8TRMT2V5QYYG5JJ3N) por Martin Fowler o si prefieres algo más interactivo puedes ver [Refactoring Guru](https://refactoring.guru/). Ambos lugares contienen muchas técnicas excelentes para mejorar el código existente.

Espero que hayas disfrutado este artículo, fue un trabajo duro refactorizar ese desastre, pero creo que hicimos un gran trabajo, y sé lo que estás pensando, ¿por qué usaste funciones libres en lugar de usar métodos de clase? ¿No deberías evitar modificar las instancias y simplemente devolver un nuevo conjunto de objetos? todas estas son preocupaciones válidas, y no estoy afirmando de ninguna manera que esta sea la solución perfecta, pero hemos recorrido un largo camino desde nuestro código original, y también tenemos algunas pruebas que verifican nuestro comportamiento, desde aquí podemos ir a cualquier parte y seguir mejorando este código hasta que sea perfecto.

Por favor, avísame en los comentarios si te gustó este ejemplo y también si harías algo de otra manera.
Si realmente te gustó esto, no olvides compartir 😀.


The noble art of refactoring

El noble arte del refactoring

Por lo general, cuando estudiamos programación o desarrollamos nuestros propios proyectos, nunca nos damos cuenta de que este no es el flujo regular que vamos a seguir cuando trabajamos como parte de un equipo en un proyecto que se ha desarrollado a lo largo de los años, el 90% del tiempo vamos a estar trabajando en el código que ya está allí, el desarrollador original podría no estar más en el equipo, tal vez no hay documentación, tal vez no hay pruebas, hay muchas posibilidades diferentes aquí, pero dado que estaremos involucrados en este entorno es crucial saber cómo mejorar código existente, este proceso se llama *Refactoring* o *Refactorización*.

## Introducción

Primero, comencemos con una definición:

> Un cambio realizado en la estructura interna del software para que sea más fácil de entender y más barato de modificar sin cambiar su comportamiento observable. - Martin Fowler

En resumen, refactorizar significa reestructurar el código existente sin cambiar la salida. Es posible que hayas escuchado el término "refactorización" ser utilizado vagamente para referirse a cualquier modificación de código existente. Sin embargo, la refactorización es en realidad una técnica basada en transformaciones que mejoran el código sin afectar el comportamiento.

Una consideración importante es que la refactorización no corrige errores intencionalmente, altera ninguna funcionalidad ni mejora directamente el rendimiento. Se supone que el código está funcionando antes de comenzar.

***

Esta será una serie de artículos puramente prácticos, profundizaremos en un ejemplo de código existente, lo refactorizaremos y luego agregaremos una nueva característica.

## El ejemplo

Para nuestra práctica, utilizaremos la [Gilded Rose Refactoring Kata](https://github.com/NotMyself/GildedRose), este es un ejemplo de código bastante malo hecho con el solo proposito de practicar nuestra habilidad de refactorizar. En nuestro caso, no vamos a usar la implementación original escrita en C#, ya que soy un desarrollador de C# que se está moviendo al mundo del frontend, decidí probar algo diferente y usar la versión *JavaScript* de [este repositorio](https://github.com/emilybache/GildedRose-Refactoring-Kata/tree/master/js-jest) y como framework de testing vamos a utilizar [Jest](https://jestjs.io/), arranquemos.

## Requisitos

Afortunadamente, esta vez hay documentación de lo que debe hacer nuestro código.

> #### Gilded Rose Refactoring Kata
>
> Hola y bienvenidos al equipo de Gilded Rose. Como sabes, somos una pequeña posada con una
> ubicación privilegiada en una ciudad prominente dirigida por un amable posadero llamado
> Allison. También compramos y vendemos solo los mejores productos. Lamentablemente, nuestros
> bienes se degradan constantemente en calidad a medida que se acercan a su
> fecha de venta. Tenemos un sistema que actualiza nuestro inventario para nosotros. Era
> desarrollado por un tipo sin sentido del humor llamado Leeroy, que se mudó a un nuevo lugar para seguir nuevas
> aventuras. Tu tarea es agregar una nueva característica a nuestro sistema para que podamos
> comenzar a vender una nueva categoría de artículos. Primero una introducción a nuestro
> sistema:
>
> * Todos los artículos tienen un valor SellIn que indica la cantidad de días que tenemos
>   para vender el artículo
> * Todos los artículos tienen un valor de Quality que indica lo valioso que es el artículo
> * Al final de cada día, nuestro sistema reduce ambos valores para cada artículo
>
> Bastante simple, ¿verdad? Bueno, aquí es donde se pone interesante:
>
> * Una vez que la fecha de caducidad ha pasado, la Quality se degrada el doble de rápido
> * La Quality de un artículo nunca es negativa
> * "Agied Brie" en realidad aumenta en calidad cuanto más viejo se hace
> * La calidad de un artículo nunca supera los 50
> * "Sulfuras", siendo un artículo legendario, nunca tiene que ser vendido o disminuye
>   en calidad
> * "Los Backstages passes", como el queso "Agied Brie", aumentan la calidad a medida que se acerca la fecha de venga,
>   aumenta en 2 cuando hay 10 días o menos
>   y en 3 cuando hay 5 días o menos, pero la calidad cae a 0 después del
>   concierto
>
> Recientemente hemos firmado un acuerdo con un mago que actua como proveedor de artículos conjurados. Esto requiere un
> actualizar a nuestro sistema:
>
> * Los elementos "Conjured" se degradan en Calidad dos veces más rápido que los elementos normales
>
> Siéntase libre de hacer cualquier cambio en el método UpdateQuality y agregar cualquier
> nuevo código siempre y cuando todo siga funcionando correctamente. Sin embargo, no puede
> alterar la clase Item o la propiedad Items ya que pertenecen al duende
> en la esquina, quien te ira y te disparará ya que no
> cree en la propiedad del código compartido.
>
> Solo para aclarar, un artículo nunca puede tener una calidad
> por encima de 50, sin embargo, "Sulfuras" es un elemento legendario y como tal
> su calidad es 80 y nunca se altera.

## El código

```javascript
class Item {
  constructor(name, sellIn, quality) {
    this.name = name
    this.sellIn = sellIn
    this.quality = quality
  }
}

class Shop {
  constructor(items = []) {
    this.items = items
  }
  updateQuality() {
    for (let i = 0; i < this.items.length; i++) {
      if (
        this.items[i].name != "Aged Brie" &&
        this.items[i].name != "Backstage passes to a TAFKAL80ETC concert"
      ) {
        if (this.items[i].quality > 0) {
          if (this.items[i].name != "Sulfuras, Hand of Ragnaros") {
            this.items[i].quality = this.items[i].quality - 1
          }
        }
      } else {
        if (this.items[i].quality < 50) {
          this.items[i].quality = this.items[i].quality + 1
          if (
            this.items[i].name == "Backstage passes to a TAFKAL80ETC concert"
          ) {
            if (this.items[i].sellIn < 11) {
              if (this.items[i].quality < 50) {
                this.items[i].quality = this.items[i].quality + 1
              }
            }
            if (this.items[i].sellIn < 6) {
              if (this.items[i].quality < 50) {
                this.items[i].quality = this.items[i].quality + 1
              }
            }
          }
        }
      }
      if (this.items[i].name != "Sulfuras, Hand of Ragnaros") {
        this.items[i].sellIn = this.items[i].sellIn - 1
      }
      if (this.items[i].sellIn < 0) {
        if (this.items[i].name != "Aged Brie") {
          if (
            this.items[i].name != "Backstage passes to a TAFKAL80ETC concert"
          ) {
            if (this.items[i].quality > 0) {
              if (this.items[i].name != "Sulfuras, Hand of Ragnaros") {
                this.items[i].quality = this.items[i].quality - 1
              }
            }
          } else {
            this.items[i].quality =
              this.items[i].quality - this.items[i].quality
          }
        } else {
          if (this.items[i].quality < 50) {
            this.items[i].quality = this.items[i].quality + 1
          }
        }
      }
    }

    return this.items
  }
}
```

No soy religioso, pero esto exige un \*\* ¡JESUCRISTO! \*\*. Después del shock inicial, ¿qué modificamos primero?

\*\* MALLLLLL! \*\*

No modificamos nada, cuando estamos en una situación como esta, modificar el código directamente es una de las peores cosas que podemos hacer, ya que será muy difícil para nosotros saber si mantenemos el comportamiento original, se volvera una bolsa gigante de errores en poco tiempo. Entonces, primero escribimos algunas pruebas que capturen el comportamiento del código y luego procedemos con las modificaciones.

## Escribiendo las pruebas

Aquí tenemos dos enfoques, podemos comenzar a escribir una prueba para cada comportamiento esperado, solo posible porque tenemos la documentación, o podemos hacer una prueba basada en texto. Este tipo de prueba no es más que capturar la salida existente del código y usar esto para verificar cada vez que hacemos una modificación, este es un término llamado *Golden Master*.

Entonces comencemos con ese:

```javascript
it("should return correct result", () => {
  // The original items passed to the method
  const storeItems = [
    new Item("+5 Dexterity Vest", 10, 20),
    new Item("Aged Brie", 2, 0),
    new Item("Elixir of the Mongoose", 5, 7),
    new Item("Sulfuras, Hand of Ragnaros", 0, 80),
    new Item("Backstage passes to a TAFKAL80ETC concert", 15, 20),
  ]
  // The result the code returned
  const expectedResult = [
    new Item("+5 Dexterity Vest", 9, 19),
    new Item("Aged Brie", 1, 1),
    new Item("Elixir of the Mongoose", 4, 6),
    new Item("Sulfuras, Hand of Ragnaros", 0, 80),
    new Item("Backstage passes to a TAFKAL80ETC concert", 14, 21),
  ]
  const gildedRose = new Shop(storeItems)
  const items = gildedRose.updateQuality()

  expect(items).toStrictEqual(expectedResult)
})
```

Esta prueba compara los elementos originales que se pasaron al código funcionando, con el resultado que dio el mismo, gracias a esta prueba siempre podemos verificar que se mantiene el comportamiento existente.
Para estar más seguro de que mis cambios no alterarán el comportamiento, escribiré unas pruebas extras para los casos que no están representados correctamente en la entrada actual del método.

```javascript
it("for normal items quality should never be below 0", () => {
  const storeItems = [new Item("+5 Dexterity Vest", 10, 0)]
  const expectedResult = [new Item("+5 Dexterity Vest", 9, 0)]
  const gildedRose = new Shop(storeItems)
  const items = gildedRose.updateQuality()

  expect(items).toStrictEqual(expectedResult)
})

it("when the sellIn date passes, quality should degrade twice as fast", () => {
  const storeItems = [new Item("+5 Dexterity Vest", 0, 4)]
  const expectedResult = [new Item("+5 Dexterity Vest", -1, 2)]
  const gildedRose = new Shop(storeItems)
  const items = gildedRose.updateQuality()

  expect(items).toStrictEqual(expectedResult)
})

it("the quality of an item can never be more than 50", () => {
  const storeItems = [new Item("Aged Brie", 1, 50)]
  const expectedResult = [new Item("Aged Brie", 0, 50)]
  const gildedRose = new Shop(storeItems)
  const items = gildedRose.updateQuality()

  expect(items).toStrictEqual(expectedResult)
})

it("the quality of an aged brie should increase by 1", () => {
  const storeItems = [new Item("Aged Brie", 1, 0)]
  const expectedResult = [new Item("Aged Brie", 0, 1)]
  const gildedRose = new Shop(storeItems)
  const items = gildedRose.updateQuality()

  expect(items).toStrictEqual(expectedResult)
})

describe("Backstage passes", () => {
  it("increases in Quality as it's SellIn value approaches", () => {
    const storeItems = [
      new Item("Backstage passes to a TAFKAL80ETC concert", 14, 0),
    ]
    const expectedResult = [
      new Item("Backstage passes to a TAFKAL80ETC concert", 13, 1),
    ]
    const gildedRose = new Shop(storeItems)
    const items = gildedRose.updateQuality()

    expect(items).toStrictEqual(expectedResult)
  })

  it("Quality increases by 2 when there are 10 days or less", () => {
    const storeItems = [
      new Item("Backstage passes to a TAFKAL80ETC concert", 10, 0),
    ]
    const expectedResult = [
      new Item("Backstage passes to a TAFKAL80ETC concert", 9, 2),
    ]
    const gildedRose = new Shop(storeItems)
    const items = gildedRose.updateQuality()

    expect(items).toStrictEqual(expectedResult)
  })

  it("Quality increases by 3 when there are 5 days or less", () => {
    const storeItems = [
      new Item("Backstage passes to a TAFKAL80ETC concert", 5, 0),
    ]
    const expectedResult = [
      new Item("Backstage passes to a TAFKAL80ETC concert", 4, 3),
    ]
    const gildedRose = new Shop(storeItems)
    const items = gildedRose.updateQuality()

    expect(items).toStrictEqual(expectedResult)
  })

  it("Quality drops to 0 after concert", () => {
    const storeItems = [
      new Item("Backstage passes to a TAFKAL80ETC concert", 0, 30),
    ]
    const expectedResult = [
      new Item("Backstage passes to a TAFKAL80ETC concert", -1, 0),
    ]
    const gildedRose = new Shop(storeItems)
    const items = gildedRose.updateQuality()

    expect(items).toStrictEqual(expectedResult)
  })
})
```

Esto puede parecer una gran preparación para cambiar algún código, pero al tomarnos nuestro tiempo y prepararnos adecuadamente antes de realizar los cambios, podemos tener la certeza de que no vamos a introducir errores con nuestra refactorización.

***

Sé que deseas comenzar a refactorizar de inmediato, pero sería demasiado en un solo artículo, en unos días comenzaremos y refactorizaremos todo el código desde cero, mientras tanto, te sugiero que tomes este código y las pruebas que hicimos hoy y las lleves a dar una vuelta, hace tu propia refactorización y compararemos con mi solución en el próximo artículo 😀.

Después de terminar con la refactorización, agregaremos la característica que solicitaron en la especificación, será pan comido, lo prometo.

Si te gustó esto, hacemelo saber en los comentarios y no te olvides de compartir, si tiene algunos comentarios o sugerencias sobre cómo tomar este ejemplo, no te olvide de comentar abajo.
Hasta la proxima.


Hace dos años comencé a buscar formas de mejorar mis habilidades de programación, hasta ese momento estaba totalmente conforme con aprender el siguiente framework, experimentar constantemente con las nuevas tecnologías y no me malinterpreten, todavía lo hago, soy un gran creyente de que debe mantener sus habilidades actualizadas, pero hace dos años leí [Clean Code: A Handbook of Agile Software Craftsmanship](https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?keywords=clean+code\&qid=1583780721\&sr=8-1) y mi carrera cambió para siempre, incluso me atrevería a decir que mi opinión sobre el software cambió para siempre.

Después de ese libro, comencé a pensar realmente en el código que estaba produciendo, cómo era una expresión de mí mismo y lo importante que era para mí tener en cuenta la calidad del software que estaba creando.

No voy a hablar sobre nuestras responsabilidades como desarrolladores, lo haré en el siguiente artículo, así que comencemos con una pequeña introducción.

***

### ¿Qué es exactamente el Código limpio o Clean Code?

No hay una única definición, probablemente haya tantas definiciones como desarrolladores en el mundo, pero algunas personalidades clave en nuestra industria tienen su propia opinión y voy a enumerar aquí las que más me gustan:

> "El código limpio siempre parece haber sido escrito por alguien a quien le importa. No hay nada obvio que se pueda hacer para mejorarlo".
> \-- Michael Feathers

Michael Feathers está en lo cierto, el código limpio es un código que ha sido escrito por alguien que se preocupa profundamente por su oficio, él / ella ha considerado todas las posibilidades, ha escrito pruebas para el código y ha hecho que sea más fácil para la próxima persona que le toque trabajar en el.

> El código limpio es simple y directo. Código limpio
> se lee como una prosa bien escrita.
> \-- Grady Booch

Grady Booch se enfoca en la legibilidad, leer código limpio es muy fácil, expresivo e incluso se podría llegar a decir que hasta hermoso. Observe cómo no mencionó la escritura del código.

> Sabes que estás trabajando en código limpio cuando cada
> la rutina que lees resulta ser más o menos lo que
> que esperabas. Puedes llamarlo código hermoso cuando
> el código también hace que parezca que el lenguaje de programación fue
> hecho para resolver ese problema
> \-- Ward Cunningham

Esta es una gran definición, ¿cuándo fue la última vez que buscaste dentro de un método o módulo y el código fue "más o menos lo que esperaba"? generalmente es al revés, nombres raros, comentarios antiguos, responsabilidades ocultas.

> El código limpio se puede leer y mejorar fácilmente mediante un
> desarrollador que no sea su autor original. Tiene
> pruebas unitarias y de aceptación. Tiene sentido con
> nombres. Proporciona una forma en lugar de muchas
> formas de hacer una cosa. Tiene dependencias mínimas, que se definen explícitamente, y proporciona una API clara y mínima.
> \-- Dave Thomas

Dave, en comparación con los otros autores, es mucho más pragmático, establece claramente que el código limpio debe ser fácil de leer, debe tener pruebas, una buena estrategia de nombres, entre otras cosas.

***

Este artículo se relaciona más con la última definición, voy a dar 5 cosas que puedes comenzar a hacer hoy para mejorar tu código y comenzar a recorrer el camino del "Código Limpio".

# 1. Escribir nombres significativos

> Solo hay dos cosas difíciles en informática: invalidación de caché y nombrar cosas.
> \-- Phil Karlton

¿Nombrar cosas es difícil? de qué está hablando este tipo, nombrar bien las cosas es bastante difícil si lo piensas bien, recuerda lo que dijo Grady Booch: "El código limpio se lee como una prosa bien escrita" si quieres llegar a ese nivel, tendrás que seguir ciertas restricciones e intentar nombrar variables, métodos y clases de la forma más expresiva posible.

* Las clases y los objetos deben tener nombres o frases nominales como Cliente, WikiPage, Cuenta y AddressParser. Evite palabras como *Manager*, *Processor*, *Data* o *Info* en el nombre de una clase. Un nombre de clase no debe ser un verbo
* Los métodos deben tener nombres de verbos o frases verbales como "postPayment", "deletePage" o "save". Los descriptores de acceso, mutadores y predicados deben nombrarse por su valor y tener el prefijo "get", "set"
* No abrevies los nombres
* No uses números mágicos
* Elige una palabra para un concepto abstracto y manténelo. Por ejemplo, es confuso tener los métodos "buscar", "recuperar" y "obtener" que son equivalentes en diferentes clases. ¿Cómo recuerdas qué nombre de método va con qué clase? Del mismo modo, es confuso tener un controlador y un administrador en la misma base de código. ¿Cuál es la diferencia esencial entre un DeviceManager y un Protocol-Controller?
* Usar variables o métodos para describir expresiones:

```javascript
if (person.age < 18 || person.driverLicense == null) {
  arrest(person)
}

// o podemos escribir
const isUnderAgeOrNoDriverLicense =
  pperson.age < 18 || person.driverLicense == null

if (isUnderAgeOrNoDriverLicense) {
  arrest(person)
}
```

# 2. Escribir funciones, clases y módulos lo más pequeños posible

> LAS FUNCIONES DEBEN HACER UNA COSA. DEBEN HACERLO BIEN.
> DEBEN HACER SOLO ESO.

Sé lo que te preguntas, qué consideras "una cosa", generalmente considero una cosa como lo explica "Uncle Bob", "Una sola razón para cambiar", si el código dentro de esa función, clase o módulo puede cambiar por diferentes razones , entonces está haciendo más de una cosa. La razón por la que escribimos funciones es para descomponer un concepto grande en un conjunto de pasos más pequeños. Si una función está recuperando datos, asignándolos, componiendo un objeto diferente, entonces todas esas responsabilidades diferentes deben separarse en diferentes abstracciones.

Hacer esto también ayudará a separar la lógica y hacer más fácil crear las pruebas unitarias de los componentes.

Este concepto está profundamente relacionado con el "Principio de responsabilidad única" o "Single Responsibility Principle" en Inglés, que probablemente trataré más a fondo en otra publicación.

# 3. Evitar los efectos secundarios

Este es un concepto del que soy muy fanático últimamente ya que he estado estudiando programación funcional, pero básicamente significa que tu código no debe modificarse ni depender de un estado fuera de su control.

Tu función promete hacer una cosa, pero también hace otras cosas ocultas. Algunas veces hará cambios inesperados a las variables de su propia clase.
Otras veces convertirá los parámetros pasados ​​en globales del sistema. En cualquier caso, son falsedades engañosas y dañinas que a menudo resultan en acoplamientos extraños y problemas de dependencias.

Como expliqué en mi artículo sobre programación funcional que puedes leer [aquí](https://www.patferraggi.dev/blog/2020/jan/programacion-funcional-para-oop/) deberías probar de apegarte tanto como sea posible a "Funciones puras", funciones que para los mismos argumentos siempre producen el mismo resultado, al hacer esto se aislará el comportamiento que produce efectos secundarios (porque queremos guardar en la base de datos o llamar a una API eventualmente) del código que es "Puro".

# 4. No te repitas

También conocido como el principio DRY, por sus siglas en Inglés, básicamente explica que debe evitar la duplicación.

La duplicación puede ser la raíz de todo mal en el software. Se han creado muchos principios y prácticas con el propósito de controlarla o eliminarla. Considera cómo la programación orientada a objetos sirve para concentrar el código en clases base que de otro modo serían redundantes. Parece que desde la invención de la subrutina, las innovaciones en el desarrollo de software han sido un intento continuo de eliminar la duplicación de nuestro código fuente.

Sé que es bastante obvio, pero a veces no nos damos cuenta de que la duplicación también viene en el sentido de la información, no solo el código duplicado sino también al proporcionar múltiples formas de hacer lo mismo.

Sin pensar conscientemente en las formas de implementación que brindamos, podemos tener rápidamente una clase con múltiples métodos, todos con fines similares, todos con diferentes implementaciones donde los errores pueden esconderse, errores que tendremos que corregir y código que tendremos que mantener.

# 5. Los comentarios son mentiras

Este es un tema controvertido, generalmente digo que no debes escribir comentarios en absoluto. Cada vez que menciono esto, a la gente le encanta criticar.
Antes de saltar directo a mi cuello, escúchame.

En general, creo que los comentarios son innecesarios, los desarrolladores los usamos como una excusa para no hacer que nuestro código sea comprensible, ya que eso es sumamente difícil. Creamos un gran desastre con abstracciones sucias, malos nombres y responsabilidades ocultas e intentamos compensarlo escribiendo un comentario.

> Una falacia común es suponer que los autores de código incomprensible podrán expresarse de manera lúcida y clara en los comentarios.
> \-- Kevlin Henney

Lo peor, en algunos casos, los comentarios son mentiras, fueron escritos hace mucho tiempo por un desarrollador que ya no trabaja en el equipo, pero nadie se atreve a eliminar el comentario en caso de que aún sea importante, de esta manera el comentario en realidad proporciona información incorrecta sobre la implementación actual del método.

Así que tengo la siguiente recomendación en lugar de usar comentarios:

> Explícate en código

```javascript

// Chequear si el empleado deberá recibir beneficios completos
if ((employee.flags & HOURLY_FLAG) &&
(employee.age > 65))


// O esto?
if (employee.isEligibleForFullBenefits())

```

Una vez más, en la mayoría de los casos, si escribes un comentario, es una señal de que deberías centrarte en extraer esa función, darle un nombre propio o utilizar otras técnicas de refactorización.

Pero como siempre, hay algunas excepciones:

* Si estás escribiendo una API pública, los comentarios pueden expresar intención y documentación para algunas herramientas automatizadas como [Swagger](https://swagger.io/)
* Si estás escribiendo código que necesita ser extremadamente eficiente, generalmente significa manejar cosas de muy bajo nivel y usar pocas abstracciones, en ese caso, un comentario puede ser útil
* A veces hay razones legales para incluir comentarios en nuestro código

# 6. Escribir pruebas

Espera, ¿no dijiste cinco? Demándame. Este es tan importante que te lo voy a dar gratis. Aún así, aunque es clave para nuestra industria, todavía me sorprende cuando la gente me pregunta cuál es el propósito de escribir pruebas o tests.

Me cuentan historias de cómo trabajan en un proyecto nuevo donde el código es excelente y que no ven el beneficio. Si no tienes pruebas, lamento decirte amigo mío que ya no es un proyecto nuevo o como dice Michael Feathers:

> El código *legacy* es todo código sin pruebas

Las pruebas simplemente me retrasarán, dicen.
Incluso he trabajado con personas que decidieron remover todas las pruebas fallidas en el proyecto para que pudieran cumplir una fecha límite.

Déjenme ser claro sobre esto, si no tiene pruebas, no sabes si su código funciona. Si estás fingiendo que conoces tu código, estas asumiendo que estas entregando el producto especificado. En este momento hay mucho miedo en el mundo debido al "Coronavirus", ¿usarías una nueva vacuna si aún no se ha probado? Apuesto a que no lo harías, pero te sientes muy cómodo entregando software que no ha sido probado adecuadamente.

Ese comportamiento y abandono han llevado a la muerte de personas y millones de dólares en pérdidas. Algunos ejemplos son:

* [Knight Capital](https://en.wikipedia.org/wiki/Knight_Capital_Group)
* [Boeing 737 MAX](https://en.wikipedia.org/wiki/Boeing_737_MAX_groundings)

***

Este es un tema muy querido para mi. Desde que leí el libro, un libro que recomiendo que todo desarrollador lea, comencé a ver mi carrera de una manera muy diferente. En caso de que estes interesado puedes leer mi lista completa de libros [aquí](https://www.patferraggi.dev/blog/2019/nov/five-books-every-developer-should-read/),

Es a partir de estas lecturas que llegue a la siguiente conclusión sobre mi.

> Soy un artesano del software y trataré de mostrar el amor por mi oficio con cada línea de código que escribo.


5 Clean Code techniques you can start doing today

5 técnicas de Clean Code que puedes comenzar a aplicar hoy mismo

Con los años, siempre he luchado contra un rival muy fuerte, yo mismo.
Soy mi peor enemigo, esa persona que te recuerda tus fracasos, tus errores pasados ​​y tus respuestas incorrectas.
Ese enemigo que te convence de que eres demasiado pequeño, demasiado débil, demasiado pobre, demasiado estúpido, no digno de alcanzar tus objetivos.
La siguiente frase siempre estuvo presente en mi mente, como una excusa.

> Dios no ha considerado conveniente distribuir equitativamente el don de la inteligencia. - John Wanamaker

No fue hasta hace muy poco, y gracias a múltiples lecturas y conferencias que comencé a notar patrones en mi comportamiento y me di cuenta de que realmente era mi propio saboteador.

* Me estaba rindiendo
* Inventaba historias para sostener mi falsa realidad y justificar mis problemas
* Culpaba a otras personas o incluso al universo por los problemas que encontraba
* Convertía problemas pequeños en inmensas tragedias
* Culpaba a otros por mi pasado

Me alegra decir que en los últimos 2 años mi vida realmente comenzó a cambiar, intentaré describir algunos pensamientos claves que hicieron esto posible, con la ayuda de muchas citas de escritores mucho mejores que yo. También intentaré recomendar algunos libros que pienso que todos deberían leer.

***

Sé lo que estás pensando, ¿leer filosofía?, tengo suficientes problemas para entender el software ¿y ahora tengo que lidiar con esto?. Prometo que esto no es lo que parece. Todos los conceptos que explicaré aquí y los libros que recomiendo provienen de una rama de la filosofía llamada *Estoicismo*, afortunadamente para nosotros, todo el contenido es muy natural y fácil de leer, parece que fue escrito especialmente para nosotros, y te traerá ideas que cambiarán tu vida.

### Tu principal problema es tu actitud

La mayoría de las veces no nos damos cuenta de cuán grande puede nuestra actitud y mentalidad influir en la realidad percibida. Las cosas que suceden en la vida no son intrínsecamente buenas o malas, es nuestra actitud hacia estas acciones lo que crea este prejuicio moral sobre ellas.

> Elija no ser perjudicado, y no se sentirá perjudicado. No te sientas herido, y no lo estarás. - Marco Aurelio

y, por supuesto, entiendo que habrá situaciones en las que el resultado de cierta tarea no sucedió como esperabas, que hubieses preferido que suceda otra cosa, bueno, es que el pasado es pasado, está fuera de tu control, preocuparse, quejarse o culpar a otros no ayudará, en realidad solo empeorará las cosas.

> Controla tus percepciones. Dirige tus acciones correctamente. Acepta voluntariamente lo que está fuera de tu control.

> La única garantía, es que las cosas saldrán mal. Lo único que podemos usar para mitigar esto es la anticipación. Porque la única variable que controlamos completamente somos nosotros mismos. - Ryan Holiday

## Los obstáculos no son algo malo

Una vez que te das cuenta de que su actitud es el problema, puedes comenzar a pensar en cómo está afectando tu vida.

> Cada problema es una oportunidad disfrazada. - John Adams

y también:

> Nuestras acciones pueden verse obstaculizadas ... pero no habrá impedimento para nuestras intenciones o disposiciones. Porque podemos acomodarnos y adaptarnos. La mente se adapta y convierte el obstáculo para nuestra actuación. El impedimento para la acción avanza la acción. Lo que se interpone en el camino, se convierte en el camino. - Marco Aurelio

La primera vez que leí esto, fue un golpe duro, déjame contarte una pequeña historia para explicar por qué:

Mientras buscaba un trabajo remoto, mi proceso era el siguiente:

1. buscaba trabajos remotos
2. investigaba la empresa
3. creaba cartas de presentación
4. aplicaba
5. repetía.

Para serte honesto, me rechazaban mucho, toneladas de compañías ni siquiera se molestaban en llamarme, o si lo hacían, fracasaba miserablemente en el *Coding Challenge*. Mi actitud hacia esto fue quejarme, estaba enojado por el proceso de entrevista, enojado con las compañías por no entender que las tecnologías son solo herramientas y que temas más amplios, como la arquitectura de software, son transferibles. Enojado porque en los *Coding Challenges* me hacían hacer cosas poco realistas que nunca iba a usar en un trabajo.

Pero luego me di cuenta, ¿de qué me sirve hacer esto? ¿podría ser que estoy mirando esto de la manera incorrecta?

Me di cuenta de que las ofertas de trabajo no son para que yo encuentre un trabajo, están creadas para que los empleadores puedan cubrir un puesto, ellos también quieren encontrar a alguien que coincida perfectamente lo más rápido posible, tuve que cambiar mi actitud para resolver su problema, no el mio.

Mi cambio de actitud fue darme cuenta de que detrás de esas entrevistas que odiaba, tenía la oportunidad de crecer, en lugar de quejarme, podría aprovechar esta oportunidad para ser mejor en algoritmos, tener un CV más expresivo o crear un *portfolio* que mostrará mi experiencia y pasión de una mejor manera.

Hasta ahora, este cambio de percepción se ha convertido en la decisión fundamental para el avance de mi carrera.

## El tiempo es limitado

Todos decimos que queremos hacer esto o aquello, pero rara vez tomamos medidas, postergamos sin darnos cuenta de que en la raíz de nuestra existencia hay una plaga, un cáncer, y que nuestro tiempo es limitado. Sé que esto suena trágico, pero no lo es, es la idea reveladora de que lo que hacemos ahora, realmente importa.

Si no nos centramos en lo que queremos hacer ahora, es posible que no tengamos tiempo para hacerlo más tarde.

> Memento Mori: Recuerda que eres mortal

y

> Concéntrese en el momento, no en los monstruos que pueden o no estar adelante. - Ryan Holiday

Deja las preocupaciones para otra vida, establece tus metas, prepara tu plan y toma accion, lo que sea que se presente en el camino, lo moverás, te adaptarás, aprenderás, si no tomas el control de tu vida, se habrá acabado antes de que te des cuenta.

Podría estar citando a Ryan Holiday, Séneca, Epictetus y muchos otros porque existe una cantidad inmensa de conocimiento a nuestra disposición y es extremadamente accesible para todo tipo de lectores, pero no lo haré.
En la escuela, nos enseñan que la filosofía es una asignatura teórica, la aprendemos y luego nos olvidamos de ella, la realidad es que la filosofía estaba ideada para ayudarnos a mejorar nuestras vidas, debía practicarse día a día para que podamos ser las mejores versiones de nosotros mismos, así que no te voy a dar un sermón aquí.

Realmente espero que obtengas algo pequeño de este artículo, una llama, que arda dentro de ti y te empuje a encontrar una mejor manera.

Como prometí, aquí hay una lista de grandes libros que cambiarán tu vida, al menos así fue para mi.

["The Daily Stoic" by Ryan Holiday](https://www.amazon.com/Daily-Stoic-Meditations-Wisdom-Perseverance/dp/0735211736/ref=sr_1_1?keywords=the+daily+stoic\&qid=1583091962\&sr=8-1)

["The Obstacle is the Way" by Ryan Holiday](https://www.amazon.com/Obstacle-Way-Timeless-Turning-Triumph/dp/B00K5JUNSU/ref=sr_1_1?keywords=the+obstacle\&qid=1583091989\&sr=8-1)

["Meditations" by Marcus Aurelius](https://www.amazon.com/Unknown-Meditations-of-Marcus-Aurelius/dp/B008H33IXS/ref=sr_1_1?crid=3172VU7G8LG7D\&keywords=meditations+marcus+aurelius\&qid=1583092021\&s=audible\&sprefix=meditations+%2Caudible%2C225\&sr=1-1)

["Letters from a stoic" by Seneca](https://www.amazon.com/Letters-from-a-Stoic/dp/B07B1JVWLF/ref=sr_1_1?crid=3D7QP12HV4NQ9\&keywords=letters+from+a+stoic+by+seneca\&qid=1583092054\&s=audible\&sprefix=letters+from+a+%2Caudible%2C217\&sr=1-1)

["Discourses and selected writings" by Epictetus](https://www.amazon.com/Discourses-Selected-Writings-Penguin-Classics/dp/0140449469/ref=sr_1_1?keywords=discourses+and+selected+writings\&qid=1583092138\&sr=8-1)

Como siempre, si te gusto el post por favor no dudes en hacérmelo saber en los comentarios. 😀


Ancient Philosophy for the Modern Developer

Filosofía antigua para el programador moderno

Hola amigos!, ¿cuanto tiempo no?. Les pido mil disculpas si estuve ausente un tiempo y se quedaron con ganas de seguir aprendiendo programación funcional. O puede que estes pensando, ¿Otra vez escribiendo sobre programacional funcional?

![NotGoingToHappen](/not_going_to_happen.jpg)

Me encontraba trabajando muy duro en el re-diseño del sitio, espero que les guste.

Pero bueno ahora ya podemos volver a esta travesía, aprender programación funcional. En mí artículo introductorio hablamos un poco sobre conceptos básicos de la FP como que es una función en términos matemáticos,
que es la composición de funciones y porqué es importante, definimos funciones puras, todos conceptos que nos van a ser muy útiles hoy para seguir ahondando en el tema.

Si no leíste mi articulo anterior podes hacerlo [aquí](https://www.patferraggi.dev/blog/2020/jan/programacion-funcional-para-oop/).

Esta nueva parte es sumamente práctica, toneladas de ejemplos en *JavaScript* así que arranquemos.

***

## Funciones como "Ciudadanos de Primer Orden"

¿Como? Vamos despacio, este concepto significa que en *JavaScript* y en los lenguajes funcionales, las funciones son un elemento fundamental del lenguaje, al ser así estas pueden ser utilizadas como cualquier otro tipo de variable.

Podemos pasar funciones como parámetros a otras funciones, podemos devolver funciones como retorno de otras funciones. Un ejemplo clásico de esto son los *callbacks* en *JavaScript* :

```javascript
http.get("alguna/api/cualquiera", params, function(err, data, response) {
  if (!err) {
    // Acá estaría el código que
    // maneja una respuesta positiva de la API
  } else {
    console.log(err)
  }
})
```

En el ejemplo anterior, hacemos una llamada a una API, y le pasamos como parámetro una función, le decimos: "Cuando la llamada a esa API termine, por favor ejecuta esta función". Esto es posible solamente gracias a que las funciones son ciudadanos de primer orden y podemos pasarlas como un parámetro normal. ¿Cómo nos ayuda esto? volvamos a un tema que vimos en el artículo anterior.

## Volviendo a la composición de funciones

Como ya dijimos, la composición de funciones nos permite crear a partir de funciones genéricas y pequeñas, comportamientos mucho más complejos.\
Ahora, tradicionalmente la composición de funciones en javascript se logra ejecutando la función como podemos ver en el siguiente ejemplo:

```javascript
function isBiggerThanThree(value) {
  return value > 3
}

function mapBoolToHumanOutput(value) {
  return value ? "yes" : "no"
}

const result = mapBoolToHumanOutput(isBiggerThanThree(3))
```

Así logramos un resultado complejo en base a 2 pequeñas funciones, pero, ¿existe otra manera? SI ! podemos usar una función de ayuda como la siguiente:

```javascript
const compose = (...fns) => x => fns.reduceRight((v, f) => f(v), x)
```

Esta función es clásica de los lenguajes funcionales, la mayoría ya la incluyen en la librería del lenguaje, *JavaScript* lamentablemente no, afortunadamente librerias como [RamdaJs](https://ramdajs.com/docs/#compose) (o cualquier otra librería que implemente la [FantasyLand Specification](https://github.com/fantasyland/fantasy-land)) incorporan la funcion a *JavaScript*.
Esta función simplemente recibe muchas funciones como parámetros, y siempre y cuando cumpla con las reglas matemáticas de composición que vimos en el artículo anterior, devuelve una nueva función que tiene el comportamiento de todas las anteriores combinadas. Veamos un ejemplo:

```javascript
function isBiggerThanThree(value) {
  return value > 3
}

function mapBoolToHumanOutput(value) {
  return value ? "yes" : "no"
}

const biggerThanThreeAndMapOutput = compose(
  mapBoolToHumanOutput,
  isBiggerThanThree
)

biggerThanThreeAndMapOutput(3)
```

¿Esta buenisimo no? ¿y qué tal si también queremos logear los resultados?

```javascript
const biggerThanThreeAndMapOutputAndLogIt = compose(
  console.log,
  mapBoolToHumanOutput,
  isBiggerThanThree
)

biggerThanThreeAndMapOutputAndLogIt(3)
```

Si, asi como lo ves! composición de funciones y nada más. ¿Quien diría que la matemática nos iba a servir para algo no?.
También se lo que te estás preguntando, ¿qué sentido tiene esto? Bueno, unos cuantos:

1. Nos permite crear código más legible sin tener que estar concatenado 3 funciones una atrás de la otra para obtener un resultado
2. Nos permite crear esta función sin tener que ejecutarla, definimos una nueva función y podemos hacer con ella lo que queramos
3. Al ser las funciones en JavaScript y en los lenguajes funcionales, "Ciudadanos de primer orden"(*First Class Citizens* en ingles) podemos pasar esta función a otras como parámetros,
   podemos componer distintas funciones en tiempo de ejecución y así alterar el funcionamiento de nuestro programa de acuerdo a las necesidades
4. Usando composición de funciones eliminamos la necesidad de definir variables intermedias, sin perder la legibilidad del código. Al momento de ejecutar nuestra función compuesta, el resultado es pasado de una función a otra automáticamente

Sigamos, hay mucho por descubrir 😀

## Currying

Me gusta la comida India pero no se si es el momento, ¿No te parece?. No, no, currying no es tirarle Curry a todo lo que se te ocurra.
Currying es un concepto importantísimo en la programación funcional, es el proceso inverso a la composición de funciones y se define de la siguiente manera:

*"Es la técnica que consiste en transformar una función que utiliza múltiples argumentos en una secuencia de funciones que utilizan un único argumento"*

Veamos un ejemplo para entenderlo:

```javascript
// Sin Currying
function sumTwoValues(x, y) {
  return x + y
}

sumTwoValues(2, 2) // = 4

// Con Currying
function sumTwoValues(x) {
  return y => {
    return x + y
  }
}

sumTwoValues(2)(2) // = 4
```

Uff pero ni ganas de hacer esto para cada función, bueno por suerte no hace falta, al igual que con *compose*, muchas librerías de JavaScript ya incorporan esto por default mediante la función de ayuda *curry* de [RamdaJs](https://ramdajs.com/docs/#curry) podemos hacerlo siguiente:

```javascript
// Sin Currying
function sumTwoValues(x, y) {
  return x + y
}

sumTwoValues(2, 2) // = 4

// Con Currying - Usando R.curry de RamdaJs

const curryiedSum = R.curry(sumTwoValues)

curryiedSum(2)(2) // = 4
```

¿Cual es el beneficio de esto te preguntaras? Un poco mas, ya llegamos.

## Aplicación Parcial de una función

Aplicación parcial es simplemente ejecutar una función con menos argumentos de los que necesita y así crear un nuevo comportamiento. Nose si lo notaste pero cuando hacíamos *Currying* básicamente estábamos agarrando una función que tiene 2 parametros y le pasabamos uno solo, ¿que paso con el otro parámetro?, veámoslo.

```javascript
// Usando R.curry de RamdaJs
function sumTwoValues(x, y) {
  return x + y
}

const curryiedSum = R.curry(sumTwoValues)

// curryiedSum es una función que recibe un solo parámetro,
// y devuelve una función que recibe el segundo parámetro,
// por lo tanto podríamos hacer esto

const addTen = curryiedSum(10)

// addTen es una nueva función, que al ejecutarla le va a sumar 10 al parámetro que nosotros elijamos.
// esto se conoce como aplicación parcial.
addTen(30) // = 40
```

Repasemos, esta función addTen es una nueva función, podemos hacer con ella lo que queramos, pasarla a otras partes del código o componerla con otras funciones.

***

Como dijimos antes la programación funcional es todo acerca de funciones, con cosas pequeñas y sencillas, lograr cosas grandes sin perder expresividad y adaptabilidad en nuestro software.
Hoy abarcamos una serie de conceptos fundamentales y muy interesantes, claves para nuestro viaje.

Nos van a permitir abrir puertas que antes no era posible o que requeriamos de inmensa fuerza fuerza para lograrlo.
En los próximos tutoriales seguiremos agregando nuevas herramientas a nuestro cinturón y utilizando estos elementos claves de nuevas maneras.

Por el momento, puedes estar orgulloso de ti mismo, si utilizas estos conocimientos básicos en tu dia a dia, ya estarás haciendo Programación Funcional.

![whatifFunctional](/what_if_functional.jpg)

Si te gusto este artículo, o si no te gusto, te pido que me lo hagas saber en los comentarios abajo. Si te quedaron dudas por favor tambien asi podemos dejar todo bien claro antes de pasar al siguiente tema.


Functional Programming for the Object-Oriented Developer

Programación funcional para el desarrollador orientado a objetos

Si venís leyendo mis últimos artículos probablemente sepas que estoy estudiando Programación Funcional y tengo que ser honesto, soy un *Newbie*, y me refiero a un *Newbie* estilo: menos de level 12, no haciendo PVP, matando monstruos chicos por horas.
Siendo el *Newbie* que soy, ni bien arranqué me mandé con todo, no dudé en meterme en un Dungeon mucho más alto que mi nivel con monstruos que pueden matarme con pocos golpes, como podés imaginar sigo asustado, pero por suerte lentamente estoy progresando y de a poco mi personaje incrementa su nivel. Espero que con esta serie de tutoriales puedas guiarte por este dungeon evitando las trampas en las que yo ya caí.

![Zelda](https://thepracticaldev.s3.amazonaws.com/i/zsoxoc4tgtla335vzzm6.gif)

***

De acuerdo a los libros de Programación Funcional (desde ahora voy a decir PF para abreviar), la PF encuentra sus raíces en la matemática, si vos sos un programador autodidacta como yo esto puede resultar sumamente intimidante pero luego de que le agarrás la mano se vuelve una sensación reconfortante. Te brinda un trasfondo conceptual muy rico con el que podés “mapear” conceptos para rápidamente saber si estás haciendo las cosas de la manera correcta o no, un beneficio que usualmente no tenemos en la programación orientada a objetos.

Como probablemente ya sepas en la PF todo es acerca de Funciones.

![FP Joke](https://thepracticaldev.s3.amazonaws.com/i/rkt7ybtc1kxa6n8dr9hi.jpg)

En la programación orientada a objetos (o POO) usualmente diseñamos clases para representar el dominio y creamos métodos para darles comportamientos a esas clases, en la PF en cambio definimos el universo de nuestro programa en términos mucho más sencillos. Creamos Tipos y funciones que manipulan Data y a esos mismos Tipos para producir resultados.
Pero bueno, comencemos desde el principio:

## ¿Qué es una función?

Se lo que estás pensando, ¿de verdad te pensás que no se lo que es una función?. Bueno, yo pensé que sabía y ahora no volveré a mirar una función de la misma manera. La PF define a una función de manera diferente a la mayoría de los lenguajes POO, la define en términos matemáticos. Veamos su definición:

*En Matemática, el concepto general de función, se refiere a una regla que asigna a cada elemento de un primer conjunto un único elemento de un segundo conjunto*

![Function](https://thepracticaldev.s3.amazonaws.com/i/p0sa0aezq7f74b1a1407.png)

![Not a function](https://thepracticaldev.s3.amazonaws.com/i/rbjrkshcvb2obav1tn9e.png)

¿Eh?¿Cómo?

Vamos a intentar explicarlo con un ejemplo en JavaScript:

```javascript
function isBiggerThanThree(value) {
  return value > 3
}

isBiggerThanThree(3) // FALSE
isBiggerThanThree(5) // TRUE
```

Esta función es una regla o relación entre los tipos *INT* y *BOOL* (si, ya se que los tipos en JavaScript son particularmente raros) donde para cada posible valor del primer set (*INT*) existe únicamente una respuesta posible en el segundo set (*BOOL*).

Debido a esto, cada vez que pasemos a esta función un número mayor a 3, nos va a devolver TRUE. No hay ninguna manera que esto no se cumpla, si esto no se cumpliese entonces no estaríamos haciendo PF, por suerte para nosotros la mayoría de los lenguajes estrictamente funcionales, como Haskell, imponen este comportamiento sobre el programador.

De este concepto sale una palabra mágica que escucho mucho cuando alguien habla sobre la PF, las “Funciones Puras”, me dirás, ¿qué son las funciones puras? Las funciones puras no son más que las funciones regulares en la PF, son funciones que no dependen o modifican el estado afuera de ellas mismas cuando se ejecutan, igual que la función que escribimos hace unos momentos, recibe un parámetro, computa y devuelve un resultado, eso es todo.
Se lo que estás pensando:

### ¿Y esto para qué me sirve?

1. Si una función siempre devuelve el mismo resultado para un mismo parámetro, entonces hacer *unit testing* se vuelve una tarea extremadamente sencilla
2. Si una función siempre devuelve el mismo resultado para un mismo parámetro, entonces lo resultados pueden ser “cacheados” para mejorar la *performance*, esto se conoce como [Memoization](https://en.wikipedia.org/wiki/Memoization), es un concepto muy común en la PF y muchas librerías incluyen funciones para hacer esto, como por ejemplo [memoizeWith en Ramda.js](https://ramdajs.com/docs/#memoizeWith)
3. Si una función no depende del estado del programa fuera de sí misma entonces nuestro código se vuelve extremadamente efectivo en escenarios donde la concurrencia es moneda corriente.
4. Ya que definimos funciones en términos matemáticos, otros conceptos matemáticos asociados a funciones también se vuelven aplicables a la programación, como es el concepto de [Composición de funciones](https://en.wikipedia.org/wiki/Function_composition)

La PF hace extensivo uso de la composición, se trata fundamentalmente de tomar funciones pequeñas, genéricas y sencillas y combinarlas de distintas maneras para obtener comportamientos complejos.
Devuelta, empecemos con la definición para sacarnos eso del encima:

*Si tenemos dos funciones: f(x) y g(x), de modo que el dominio de la 2ª esté incluido en el recorrido o codominio de la 1ª, se puede definir una nueva función que asocie a cada elemento del dominio de f(x) el valor de g\[f(x)]*

![Composition](https://thepracticaldev.s3.amazonaws.com/i/ylybung2c6yxypxpfoe6.png)

![Woah Slow Down](/despacio.gif)

Esto significa que si tenemos una función que toma un *INT* y devuelve un *BOOL*, y tenemos una segunda función que toma un *BOOL* y devuelve un *STRING*, entonces por definición también tenemos una tercera función que toma un *INT* y devuelve un *STRING*, debido a la regla de composición de funciones. Veamos un ejemplo:

```javascript
function isBiggerThanThree(value) {
  return value > 3
}

function mapBoolToHumanOutput(value) {
  return value ? "yes" : "no"
}

const result = mapBoolToHumanOutput(isBiggerThanThree(3))
```

En los siguientes blog posts, explicaré otros conceptos adyacentes a este que nos permitirán crear nuevas funciones sin la necesidad de aplicarlas, de modo que podremos pasarlas como parámetros o devolverlas como valores de retorno.

***

Si decidís seguirme en mi camino me aseguraré de que juntos completemos este calabozo, llegaremos a un punto en el que conoceremos todos sus rincones, tendremos todas las armas y secretos y seremos capaces de salvar el progreso una vez todo esté completo.

Realmente espero que te haya gustado esta pequeña introducción, continuaré subiendo de nivel y guiándote en el proceso. Si encontraste este post útil te pido por favor que me lo hagas saber en los comentarios, mismo si tienes alguna duda, corrección o recomendación no dudes en hacérmelo saber. 😀

Finalmente voy a dejar una pequeña lista del material que voy a estar usando en esta travesía. Actualmente, estoy aprendiendo Haskell pero esto es solo una herramienta más para aprender Programación Funcional.

* Estoy haciendo este curso gratis en vivo dictado por profesores de MIT: [Programming with categories](http://brendanfong.com/programmingcats.html), es sobre *Category Theory* y Programación Funcional en Haskell.
* También me encuentro leyendo un libro de uno de los profesores del curso: [Category theory for programmers](https://github.com/hmemcpy/milewski-ctfp-pdf)
* Una vez completado eso, tengo varios caminos posibles dependiendo de la *Build* que haga para mi personaje

#### HASKELL BUILD

Podría seguir aprendiendo Haskell con [Learn you a Haskell for great good](http://learnyouahaskell.com/chapters) o [Haskell from principles](https://haskellbook.com/) o [A type of programming](https://atypeofprogramming.com/).

#### CLOJURE BUILD

Podría cambiar a algo como Clojure con [Structure and Interpretation of Computer Programs](https://web.mit.edu/alexmv/6.037/sicp.pdf) o el libro que le da nombre a esta serie de artículos [Functional programming for the object-oriented programmer](https://leanpub.com/fp-oo)

#### JAVASCRIPT BUILD

Por ultimo también podría cambiar a JavaScript ya que lo uso en mi dia a dia en el trabajo, para esto leería [Mostly adequate guide to functional programming](https://github.com/MostlyAdequate/mostly-adequate-guide) y podría experimentar con RX.JS o Ramda.JS

Todavía no es claro como se verá mi personaje cuando llegue a nivel máximo, lo que sí es claro es que me asegurare de narrar mi aventura y compartir todo el conocimiento que adquiera en el proceso.


Como probablemente sabrás si leíste mis artículos anteriores, no soy un gran conocedor de la Programación Funcional, estoy muy lejos de serlo. Toda mi experiencia en desarrollo se encuentra en las profundidades de la Programación Orientada a Objetos. Bueno, ya no más. Hace unas semanas decidí que quería ver qué eso de lo que hablan los programadores senior y experimentar por mi mismo si los supuestos beneficios de la programación funcional son ciertos o solo rumores.

## Como pronto descubriría, decirlo fue mucho mas fácil que hacerlo.

Existen tantos lenguajes funcionales que elegir uno para comenzar no fue una tarea fácil. Para sacarme las dudas, primero decidí leer el libro [Structure and Interpretation of Computer programs](https://web.mit.edu/alexmv/6.037/sicp.pdf) lo que me llevo a conocer la sintaxis de LISP y a apreciar la simplicidad de Clojure. Luego leí [Mostly adequate guide to functional programming](https://mostly-adequate.gitbooks.io/mostly-adequate-guide/) y me hizo pensar que quizás JavaScript podría ser suficiente para esta aventura. También resulta que soy un programador de C# en mi día a día, por lo que F# fue mencionado múltiples veces en distintas conversaciones.

Al final decidí tomar el camino difícil, necesitaba tener algo a mi lado que me golpease directo en la cara si siquiera pensase en hacer algo en un estilo orientado a objetos o estructurado, y así fue como el santo grial de la Programación Funcional se presento ante mi.

## Haskell

Un poco de contexto, esta es la primera vez que intento aprender algo remotamente parecido a la Programación Funcional, es la primera vez que intento aprender un lenguaje que no utiliza la conocida sintaxis estilo C y también es la primera vez que intento aprender un lenguaje sin tener un proyecto real para guiarme y ensuciarme las manos.

Está de mas aclarar que no fue un comienzo fácil, pasé horas buscando en foros y blogs, y llegué a la conclusión de que no existía una IDE o herramienta que todo desarrollador de Haskell utilizase. Si iba a recorrer este camino debería ingeniármelas solo. Lo más parecido que encontré fue [Haskell for mac IDE](http://haskellformac.com/), y después de pasar medio día luchando con instalaciones de VSCode que no funcionaban decidí abrir mi billetera y comprarla.

![Haskell](https://thepracticaldev.s3.amazonaws.com/i/72lqto1aiijvmcwbr5z5.jpg)

Como me sugirieron varias personas decidí seguir el libro [Learn you a Haskell for great good](http://learnyouahaskell.com/) y para ser perfectamente honesto, no me había sentido tan perdido y abrumado en años, a pesar de que entiendo los conceptos básicos de la Programación Funcional, las funciones puras, la transparencia referencias y demás, cada vez que quería hacer algo por mi cuenta sin leer el libro, mi mente se ponía en blanco. Yo no me rindo fácilmente, pero quedé sorprendido al darme cuenta lo lento que estaba progresando, tan lento que incluso llegue a expresar mi frustración en twitter preguntándole a otras personas si esto era normal o estaba haciendo algo mal.

![Meltdown](https://thepracticaldev.s3.amazonaws.com/i/z81liau0yfay0rhjtlz6.png)

Luego de luchar medio día más con la IDE de Haskell -en realidad 2 IDEs: IntelliJ con el plugin de Haskell para el desarrollo “Real” y Haskell For Mac para pruebas y usar el *REPL*- comencé a leer los comentarios que la gente me escribía y gracias a ellos conocí una gran cantidad de recursos extra:

* [Zero Bullshit Haskell](https://github.com/alpacaaa/zero-bullshit-haskell)
* [Haskell programming from first principles](https://haskellbook.com/)
* [Exercism.io Haskell Track](https://exercism.io/tracks/haskell)
* [Dive Into Haskell](https://github.com/politrons/Dive_into_Haskell)
* [Category theory book](https://bartoszmilewski.com/)
* [A Type of programming](https://atypeofprogramming.com/)

También recibí palabras de aliento que me hicieron dar cuenta de que mis sentimientos eran perfectamente normales. Fue en ese momento cuando me di cuenta: No me había sentido así desde que aprendí a programar, aprender Haskell es básicamente como aprender a hacer todo de nuevo.

No se pueden asignar variables, no hay loops, no se puede cambiar el estado de las variables, no hay clases ni objetos, ¿recursión? Ni siquiera sé cómo hacer un simple *hello world*.

Muy despacio, comencé a escribir mis propias funciones y a hacer un pequeño progreso:

![MyFunctions](https://thepracticaldev.s3.amazonaws.com/i/u2uzndrny114btn7baj6.png)

Y a pesar de que todavía no puedo escribir nada en la consola, simplemente porque no se cómo ya que no llegue a ello en los libros, eso no me detuvo para comenzar a modelar mi propio [SnakeGame](https://elgoog.im/snake/)

![SnakeGame Implementation](https://thepracticaldev.s3.amazonaws.com/i/nsbpocena561oan3zbj1.png)

***

Se lo que están pensando, ¿tenés algo positivo para contarme de ésta experiencia? No me estás vendiendo demasiado bien la aventura. Sólo te puedo comentar lo que note hasta ahora:

1. En vez de modelar objetos de dominio con complicadas clases y comportamientos con métodos en esos objetos, mi código fluye naturalmente hacia la implementación de funciones muy muy muy chicas, y es por estas pequeñas y combinables funciones que creo que sería sumamente difícil romper el [Single Responsibility Principle](https://en.wikipedia.org/wiki/Single_responsibility_principle)

2. En vez de escribir código que dicta los pasos para llevar acabo una acción, mi código simplemente define que es cada parte del dominio y como se comporta, se siente muy extraño.

3. La mayoría de los patrones de diseño que utilizo todo el tiempo parecen ser completamente inútiles, ¿porqué crearía una *Factory* si simplemente puedo devolver una función? ¿porqué crearía varias *Strategy* si simplemente puedo pasar funciones para reemplazar implementaciones?

4. El sistema de Tipos de Haskell es extremadamente inteligente, bastante más inteligente que los de otros lenguajes que conozco. Encontré en varias situaciones que Haskell mismo entiende qué quiero hacer y simplemente se mantiene fuera de mi camino, siempre y cuando las funciones tengan sentido.

Tengo que aceptar que esta es una de las tareas más difíciles que tuve en mucho tiempo, pero honestamente creo que esta aventura puede llevarme a conocer un lugar del que probablemente nunca me quiera ir. Siempre y cuando no me coma un dragón, estaré aquí escribiendo y compartiendo mis aventuras con cualquiera que esté interesado.


Vámonos a una aventura, una aventura funcional

Bueno, otro año se termina. Si bien no creo en que las resoluciones de año nuevo sirvan para lograr cosas, si creo en ponerme compromisos.

Durante 2019 cometí errores pero fui perfeccionado una manera en la que puedo enfocarme, aprender y mejorar, físicamente, como persona y en mi carrera. Arrancar un nuevo año es un buen punto para evaluar qué hice mal, que hice bien y que quiero lograr para el siguiente año,
pero la planificación sola no va a llevarme a ningún lado, es el trabajo duro dia a dia el que me va a permitir alcanzar mis metas.

Este año particularmente fue un año muy importante para mi en lo que es desarrollo personal y la practica deliberada, tengo un articulo, aunque esta en Ingles, que explica como planeo mis metas en el corto y largo plazo y que acciones tomo en el dia a dia para estas metas, puedes leerlo [aquí](https://www.patferraggi.dev/blog/2019/dic/deliberate-learning/).

***

Estos son mis goals relacionadas a desarrollo para 2020 y las acciones que voy a tomar para intentar alcanzar dichas metas.

### 1. Volverme relativamente cómodo con la programación funcional.

* Terminar el libro [Learn you a Haskell for great good](http://learnyouahaskell.com/).
* Hacer un Snake Game como [este](https://www.youtube.com/watch?v=bRlvGoWz6Ig) pero en Haskell.
* Volver a leer el libro [Mostly adequate guide to functional programming](https://mostly-adequate.gitbooks.io/mostly-adequate-guide/).
* Volver a hacer el Snake Game pero con JavaScript.
* Leer el libro [Functional programming for the object oriented programmer](https://leanpub.com/fp-oo).
* Volver a leer el libro [Structure and interpretation of computer programs](https://web.mit.edu/alexmv/6.037/sicp.pdf).
* Aplicar programación funcional dia a dia en mis proyectos de JavaScript/TypeScript.
* Tener un proyecto personal con un lenguaje funcional para desarrollar cierta expertise en el(Elixir, Elm, Clojure o F# son los que tengo en mente por ahora).

### 2. Profundizar en arquitectura de software y ciencias de la computación.

* Leer [The imposter's handbook series](https://bigmachine.io/products/the-imposters-handbook/) por completo.
* Leer y estudiar [Clean Architecture](https://www.amazon.com/-/es/Robert-C-Martin-ebook/dp/B075LRM681).
* Leer [Domain Driven Design: Tackling complexity in the heart of software](https://www.amazon.com/-/es/Eric-Evans/dp/0321125215).
* Leer [Implementing Domain Driven Design](https://www.amazon.com/-/es/Vaughn-Vernon/dp/0321834577).
* Diagramar y analizar diseños de proyectos en los que actualmente trabajo y buscar posibles maneras de mejorarlos.

### 3. Volverme un frontend decente, no solo un backend dev que hace frontend.

* Pagar una suscripción a [Frontend Masters](https://frontendmasters.com/).
* Aprender sobre reactive functional programming (Rxjs).
* Terminar los estilos de mi sitio personal y blog para ganar experiencia con CSS y animaciones.
* Meterme a fondo en el framework que utilice en mi trabajo, por el momento Angular.

### 4. Conseguir un trabajo remoto.

* Aplicar a trabajos en sitios como [WeWorkRemotely](https://weworkremotely.com/) y muchos otros.
* Aplicar a trabajos en compañías en las que me gustaría trabajar que ofrezcan trabajo 100% remoto.
* Practicar Code Katas para pasar las coding interviews en sitios como [HackerRank](https://www.hackerrank.com/) (soy particularmente malo haciendo este tipo de entrevistas lamentablemente).
* Leer [Cracking the coding interview](https://www.amazon.com/-/es/Gayle-Laakmann-McDowell/dp/0984782850).

### 5. Escribir mínimo 1 blog post en Español a la semana.

* Planear el tiempo dentro la semana para volverme metódico a la hora de escribir.
* Escribir una lista de ideas para posibles artículos, a medida que surjan.
* Documentar mi progreso con respecto a la programación funcional y la arquitectura de software.
* Escribir tutoriales para solidificar conocimientos.

### 6. Dar al menos 1 charla en alguna meetup.

* Crear una lista de temas posibles para dar una charla y elegir uno en el cual me encuentre interesado.
* Preparar la charla y darla quizás online a modo de práctica.
* Dar la charla primero en mi compañía actual enfrente de gente que conozco.
* Asistir a meetups con regularidad para ponerme en contacto con los organizadores.
* Asistir a meetups con regularidad e interactuar con otros miembros para superar el miedo y la ansiedad.

Uff ahora que lo escribo en papel parece ser muchísimo verdad? de cualquier manera creo que si me enfoco y utilizó el proceso que fui desarrollando durante 2019, que puedes leerlo en el artículo mencionado al principio, entonces es posible alcanzar estas y otras metas (tengo otras no específicas de mi carrera como desarrollador).

Si te parece que mis metas son interesantes y te gustaría seguirlas te invito a hacerlo y ayudarnos en el proceso.
Si tienes metas distintas te invito a detallar acciones concretas de cómo pensás lograrlas y a compartirlas conmigo.
Si pensás que hay cosas que podría hacer diferente para tener un mejor resultado, no dudes en decírmelo 😀

Finalmente gracias por tomarte tu tiempo para leer este post, te deseo un muy feliz año nuevo.
