# Desacoplando la entrega de software de los sistemas de control de versiones

Como una extensión más de la
[ley de Conway](https://es.wikipedia.org/wiki/Ley_de_Conway), es muy habitual
encontrarse con proyectos donde la estrategia de _branching_ del sistema de
control de versiones está fuertemente relacionada con la estrategia de entrega
de software. Esta relación entre ambos mundos puede parecer conveniente (por
ejemplo: utilizar una rama para representar el código _vivo_ en producción o
_staging_, congelar los cambios que van a desplegarse en una rama `release/*`,
etc.) pero, con el paso del tiempo, puede traer consigo efectos
contraproducentes:

- **Viola el principio de responsabilidad única**. Si algo nos queda claro sobre
  el _Single Reponsability Principle_ es que cada abstracción sólo debe tener
  _una única razón para cambiar_ (en palabras de Robert C. Martin). Si cambios
  en los procesos de entrega de software (flujos de resolución de _hotfixes_,
  nuevos entornos) implican cambios en la estructura de nuestro repositorio (o
  cambios en la manera de interactuar con él), los límites entre ambos contextos
  no están bien establecidos.
- **Todo se vuelve innecesariamente complejo**. Aún con flujos muy populares
  como `git-flow` (y herramientas muy sofisticadas a su alrededor, construidas
  como una capa de abstracción sobre `git`), se _hackea_ el sistema de control
  de versiones para dejar de ser una herramienta de _tracking_ y colaboración
  por un sistema de despliegue y configuración.
- **Resta flexibilidad**. Si es el sistema de control de versiones el encargado
  de determinar qué funcionalidades se van a liberar al final de una iteración,
  se pueden dar situaciones en las que una rama se quede _congelada_ por
  contener funcionalidad defectuosa que inevitablemente contamina al resto de
  cambios de esa misma rama, bloqueando la entrega de nueva funcionalidad.

![Imagen de un repositorio que utiliza git-flow](/static/articles/decoupling-vcs-from-software-delivery/git-flow.jpg "Este repositorio utiliza el sistema de control de versiones como una herramienta de entrega de software para la próxima iteración (aplicando un flujo similar a git-flow)")

Para aliviar los problemas anteriores, una solución pasa por mover la
responsabilidad de decidir qué funcionalidades están disponibles en cada entorno
desde el sistema de control de versiones a la propia base de código. Es decir,
decidir programáticamente si una funcionalidad está habilitada o no en función
de en qué entorno se está ejecutando la aplicación.

Una representación habitual de este principio es a través del uso de
[Feature Flags](https://featureflags.io), que no dejan de ser, conceptualmente,
bloques condicionales que se sitúan en algún punto de nuestra base de código y
deciden si un camino de ejecución debe evaluarse o no.

Con esta estrategia, únicamente necesitaríamos una rama `master` donde fusionar
las _feature branches_ de funcionalidades terminadas y una configuración de
_feature flags_ que defina los entornos en los que estarían disponibles. Por
ejemplo: habilitar la funcionalidad únicamente en entornos de _staging_ para
realizar pruebas de rendimiento, labores de _quality assurance_, etc. La
resolución de hotfixes, se podría realizar igualmente sobre la rama `master`,
pues es esta la que siempre se despliega y define qué funcionalidades estarían
disponibles en cada momento y para cada entorno.

![Imagen de un repositorio con una única rama master y múltiples feature branches](/static/articles/decoupling-vcs-from-software-delivery/with-feature-flags.jpg "En este ejemplo, el repositorio es agnóstico de la capa de entrega de software, que estará gestionada por la propia base de código mediante el uso de feature toggles.")

Siguiendo esta dirección, también se obtendrían beneficios adicionales como, por
ejemplo, poder realizar _merges_ de manera mucho más recurrente (al estar el
entorno de producción siempre protegido a través de _feature flags_). Esto
podría derivar, a su vez, en procesos de _code review_ con un número menor de
cambios y ciclos de _feedback_ más cortos, siempre que lo combinemos con
técnicas como _continuous integration_ y _continuous delivery_.

## Otras lecturas relacionadas

- [Decoupling Deployment from Release - ThoughtWorks' Technology Radar](https://www.thoughtworks.com/radar/techniques/decoupling-deployment-from-release)


# React: MultipleRender

El síntoma más claro de este _code smell_ es la aparición de varios métodos de
instancia tipo `render` especializados en construir una parte de la UI de un
componente React. Suele aparecer especialmente en componentes complejos (o de
gran tamaño, como una página) cuando diferentes partes de la interfaz precisan
de alguna comprobación o cálculo extra que afecte a su representación.

```tsx
export class Blog extends React.Component<{ articles: Article[] }> {
  public render() {
    return (
      <React.Fragment>
        {this.renderHeader()}

        {this.renderArticles()}
      </React.Fragment>
    );
  }

  private renderHeader() {
    const {
      articles: { length: numberOfArticles },
    } = this.props;

    if (numberOfArticles === 0) {
      return (
        <header>
          <p>No articles 😯</p>
        </header>
      );
    }

    return (
      <header>
        <p>Yay! {numberOfArticles} articles 🎉</p>
      </header>
    );
  }

  private renderArticles() {
    return this.props.articles.map(article => {
      return (
        <section>
          <h1>
            <a href={article.url}>{article.title}</a>
          </h1>
        </section>
      );
    });
  }
}
```

En el caso anterior, vemos que la representación de la cabecera de la página
varía en función del número de artículos que se vayan a mostrar. Del mismo modo
que la lógica para pintar la colección de artículos está encapsulada en su
propio método de instancia.

Con echar un simple vistazo al método `render`, ya vemos con claridad cuáles son
las verdaderas responsabilidades de nuestra página: definir un _layout_ que
muestre una cabecera y una colección de artículos.

¿Es, por tanto, responsabilidad de la página conocer los _internals_ de la
cabecera y la lógica necesaria para pintar la colección de artículos? No. Este
componente contiene más de una responsabilidad y no cumple con el
[Principio de Responsabilidad Única](https://en.wikipedia.org/wiki/Single_responsibility_principle).

Para mejorar nuestro diseño, bastaría con definir dos nuevos componentes que
encapsulen la lógica necesaria para pintar ambas partes. Con este enfoque,
ganaríamos cierta capacidad para reutilizar esos componentes en otros lugares de
nuestra interfaz (aunque no es condición necesaria para crear un nuevo
componente) a la vez que reducimos la complejidad del componente padre, que no
necesita ya llevar consigo toda la lógica de las diferentes partes que la
conforman.

Además, si seguís un enfoque de integración y entrega continua, veréis que es
mucho más sencillo [aplicar _feature flags_](/blog/branch-by-abstraction-react)
sobre estos pequeños componentes de vuestra interfaz en lugar de en mitad de
componentes grandes y complejos, donde se estarían mezclando responsabilidades y
requisitos de distintas partes de la aplicación.

```tsx
import { Articles } from "./components/Articles";
import { Header } from "./components/Header";

export function Blog(props: { articles: Article[] }) {
  return (
    <React.Fragment>
      <Header {...props} />

      <Articles {...props} />
    </React.Fragment>
  );
}
```

Este _code smell_ está relacionado con otros de propósito general (no
relacionados directamente con React) como
[_Large Class_](https://sourcemaking.com/refactoring/smells/large-class) y
técnicas de _refactoring_ como
[Extract Class](https://refactoring.guru/extract-class).


# JavaScript: NakedCode

> Código que se escribe y, por tanto se ejecuta, sin estar encapsulado en ningún
> bloque o procedimiento (como por ejemplo una función o una clase).

En JavaScript, sufrimos de una relación de amor-odio con el contexto de
ejecución goblal. Hasta la aparición de los módulos en la especificación de ES6+
la manera más habitual de gestionar dependencias en nuestra aplicación era a
través de la variable global `window`, accesible desde cualquier punto de
nuestro programa.

Con los módulos, llegó una manera de gestionar esas dependencias de manera
explícita y favorecer técnicas como
[tree shaking](https://github.com/rollup/rollup#tree-shaking) para mejorar el
rendimiento de nuestras aplicaciones. Mientras que, a su vez, ganamos también
cierta capacidad para encapsular nuestro código y evitar que se ejecutase en el
contexto global de la aplicación, junto al resto de código de otros ficheros.

Sin embargo, sigue siendo habitual encontrar este tipo de
[code smell](https://martinfowler.com/bliki/CodeSmell.html) gracias a lo
sencillo de codificar directamente en el cuerpo de módulos ECMAScript:

```js
const repository = {};

export function addTodo(todo) {
  if (repository[todo.id]) {
    return;
  }

  repository[todo.id] = todo;
}
```

Aunque escribir código directamente en el cuerpo de un módulo tiene sus casos de
uso, tiene efectos laterales que pueden ser **no** evidentes:

- El código del módulo (sin encapsular) es ejecutado por el intérprete la
  primera vez que se importa, por lo que perdemos la habilidad de controlar
  cuándo evaluar un fragmento de código para, por ejemplo, establecer un
  escenario de ejecución determinado en nuestras pruebas.
- En el ejemplo anterior, la variable `repository` es un objeto _global_ (aunque
  únicamente accesible desde el propio cuerpo del módulo) que dificulta
  enormemente la capacidad de probar el código de manera unitaria, ya que hay
  que gestionar el estado de un variable sobre la que no tenemos acceso.
- Podemos incurrir en problemas de rendimiento (_memory leaks_), al disponer de
  una serie de variables globales sobre las que el recolector de basura no puede
  actuar en caso de no ser necesarias (siempre mantendrán -al menos- una
  referencia).

¿Cómo podríamos mejorar el caso anterior? Envolviendo el cuerpo del módulo en
una función `createRepository` que nos devuelva el control sobre el contexto de
ejecución del repositorio.

```js
export function createRepository(todos = {}) {
  const repository = { ...todos };

  return {
    addTodo(todo) {
      if (repository[todo.id]) {
        return;
      }

      repository[todo.id] = todo;
    },
  };
}
```

A pesar de los problemas anteriores, existen escenarios donde realmente sí
queramos ejecutar código en el cuerpo del módulo para poder beneficiarnos del
hecho de ser una suerte de
[_Singleton_](https://en.wikipedia.org/wiki/Singleton_pattern):

- Fichero `index` donde inicializar dependencias globales de la aplicación.

Cabe recordar que un _code smell_ no significa que algo esté _mal_. Simplemente
se refiere a un patrón que _puede_ (esto es importante) conllevar consigo males
de diseño. En este caso, a no ser que sea plenamente consciente de los efectos
laterales que conlleva, evito utilizar _naked code_ en el cuerpo de mis módulos
JavaScript.


# Branch by Abstraction en Componentes React

En ocasiones, nos vemos en la situación de tener que actualizar varios
componentes de nuestra interfaz de usuario para ajustarlos a nuevas directrices
de diseño. Otras veces, necesitamos reemplazar su implementación para hacer
frente a nuevos requisitos de negocio. Si el número de cambios es lo
suficientemente alto, es posible que no se puedan realizar de manera atómica (o
tengan que ser sincronizados con eventos fuera del control del equipo de
desarrollo como, por ejemplo, la publicación de una nueva imagen de marca) a la
vez que necesitamos continuar entregando valor en forma de nuevas
funcionalidades, corrigiendo defectos o aplicando alguna que otra mejora.

En este artículo vamos a hablar sobre una estrategia que nos permita obtener un
flujo de integración continua evitando, por tanto, mantener los cambios en
nuestros componentes en una rama independiente en el sistema de control de
versiones durante el transcurso de su desarrollo.

¿Cómo lo conseguiremos? Haciendo uso de dos técnicas muy habituales en equipos
que trabajan con prácticas como _continuous integration_ o _continuous
delivery_: [Feature Flags](http://featureflags.io/) (o Feature Toggles si
[leéis a Martin Fowler](https://martinfowler.com/bliki/FeatureToggle.html)) y
[Branch By Abstraction](https://martinfowler.com/bliki/BranchByAbstraction.html).

Ambas estrategias nos permitirán fusionar código de manera regular sobre la rama
principal, aún con funcionalidades parcialmente terminadas, evitando así
mantener ramas en paralelo que podrían estar días (o semanas) sin integrarse con
el trabajo realizado por el resto del equipo.

> Las feature flags son, conceptualmente, bloques condicionales que permiten
> habilitar o deshabilitar una funcionalidad (o un camino de ejecución) en base
> a un conjunto de condiciones (como pueden ser: el entorno de ejecución, el
> perfil del usuario o un porcentaje de tráfico)

Pongamos como ejemplo que, en nuestra aplicación, llevamos ya un tiempo
utilizando `<AwesomeCalendar />` (un componente de terceros) como _widget_ de
calendario. En los puntos donde es necesario mostrar un calendario, importamos
el componente y lo insertamos en el _layout_ de la página.

```tsx
import React from "react";

import { AwesomeCalendar } from "awesome-calendar";

function Page() {
  return (
    <Page>
      <Header />

      <Body>
        <AwesomeCalendar date={new Date(2018, 6, 21)} />
      </Body>
    </Page>
  );
}
```

Debido a una serie de requisitos, tenemos que crear un nuevo componente para
mostrar un calendario que sustituya a `AwesomeCalendar` y le añada un _extra_ de
funcionalidad para dar cabida a nuevas historias de usuario. El desarrollo del
componente se extenderá durante varias semanas.

El primer paso para poder integrar nuestro componente de manera continua es
asegurar que somos capaces de controlar cuándo y cómo se utiliza para poder
aislar a los consumidores de `AwesomeCalendar` de los cambios en el mismo. Para
ello, vamos a empezar creando una nueva _abstracción_ `Calendar` que pasará a
ser utilizada por el resto de componentes y mantendrá la misma interfaz que
ofrecía `AwesomeCalendar`:

```tsx
import React from "react";

import { AwesomeCalendar } from "awesome-calendar";

export function Calendar({ date }: { date: Date }) {
  return <AwesomeCalendar date={date} />;
}
```

Como vemos, la manera de consumir este nuevo componente sería muy parecida a la
versión anterior:

```tsx
import React from "react";

import { Calendar } from "../components";

function Page() {
  return (
    <Page>
      <Header />

      <Body>
        <Calendar date={new Date(2018, 6, 21)} />
      </Body>
    </Page>
  );
}
```

> En este punto, ya podríamos fusionar nuestros cambios con la rama de código
> principal para que el resto de trabajo en curso pueda ir haciendo uso de
> nuestro (no tan) _nuevo_ componente.

A continuación, vamos a crear una implementación muy sencilla de nuestro propio
calendario, que empezará apoyándose en una implementación nativa de `datetime`
pero respetando la interfaz original del componente `AwesomeCalendar`:

```tsx
import React from "react";

export function NewCalendar({ date }: { date: Date }) {
  const value = /* implementation details */;

  return <input type="datetime-local" value={value} />;
}
```

Una vez hemos eliminado la responsabilidad de elegir qué calendario utilizar de
los consumidores del componente, podemos utilizar _feature flags_ para
determinar qué calendario mostrar en cada momento.

En este caso, vamos a permitir que cualquier entorno que **no sea producción**
utilice siempre nuestro propio calendario, con el objetivo de obtener _feedback_
sobre su experiencia de uso a medida que avanzamos en su desarrollo:

```ts
export function isNewCalendarEnabled() {
  return process.env.NODE_ENV !== "production";
}
```

> Este caso, representamos la feature flag con una simple función que comprueba
> el entorno de ejecución actual, pero existen
> [sistemas más sofisticados](https://github.com/Unleash/unleash) para gestionar
> el estado de los _toggles_ en nuestra aplicación.

Ahora, nuestra nueva abstracción `Calendar` (que hace las veces de factoría)
puede hacer uso de esta función para determinar qué componente de calendario
utilizar, manteniendo al resto de consumidores aislados de toda complejidad:

```tsx
import React from "react";

import { AwesomeCalendar } from "awesome-calendar";

import { NewCalendar } from "./components";

import { isNewCalendarEnabled } from "../features";

export function Calendar(props: { date: Date }) {
  return isNewCalendarEnabled() ? (
    <NewCalendar {...props} />
  ) : (
    <AwesomeCalendar {...props} />
  );
}
```

A partir de este momento, todas las pantallas de nuestra interfaz de usuario que
necesiten de un calendario, utilizarán la abstracción `Calendar` y será esta
misma abstracción la que se encargará de utilizar la implementación concreta del
calendario que corresponda en función del entorno de ejecución.

Como vemos, aplicar técnicas como _branch by abstraction_ y _feature flags_ nos
permite alcanzar un flujo de integración (y entrega) continua en nuestros
componentes aportándonos beneficios cómo:

- Minimizar la superficie de cambios a fusionar cuando integramos trabajo en
  curso
- Tomar el control sobre cuándo se ejercita un camino de ejecución y poder
  habilitarlo y deshabilitarlo en base a una serie de condiciones
- Dotar a los equipos de negocio de visibilidad sobre el trabajo en curso en
  tareas de larga duración (sin sacrificar ninguna de las premisas anteriores)


Codecoolture

Artículos

Desacoplando la entrega de software de los sistemas de control de versiones

Code Smell: React.MultipleRender

Code Smell: JavaScript.NakedCode

Branch By Abstraction en Componentes React