Actualización: Este artículo es ahora parte de mi libro "Node.js Beyond The Basics".

Lee la versión actualizada de este contenido y más sobre Node en jscomplete.com/node-beyond-basics.

Los flujos de Node.js (streams)tienen la reputación de ser difíciles de trabajar, y aún más difíciles de entender. Bueno, tengo buenas noticias para ti - ese ya no es el caso.

A lo largo de los años, los desarrolladores han creado montones de paquetes con el único propósito de facilitar el trabajo con flujos. Pero en este artículo, voy a centrarme en la API nativa de flujos de Node.js.

“Los flujos son la mejor y más incomprendida idea de Node.”

— Dominic Tarr

¿Qué son exactamente los flujos?

Los flujos son colecciones de datos, como las matrices o las cadenas de texto. La diferencia es que estos pueden no estar disponibles todos a la vez y no tienen por qué caber en la memoria. Esto hace que sean realmente potentes cuando se trabaja con grandes cantidades de datos, o con datos que vienen de una fuente externa de uno en uno.

Sin embargo, los flujos no sólo sirven para trabajar con grandes cantidades de datos. También nos ofrecen la posibilidad de componer nuestro código. Al igual que podemos componer poderosos comandos de Linux mediante la canalización de otros comandos más pequeños, podemos hacer exactamente lo mismo en Node con los flujos.

const grep = ... // Un flujo para la salida de grep
const wc = ... // A stream for the wc input

grep.pipe(wc)

Muchos de los módulos incorporados en Node implementan la interfaz de streaming:

La lista anterior tiene algunos ejemplos de objetos nativos de Node.js que también son flujos legibles y escribibles. Algunos de estos objetos son flujos tanto legibles como escribibles, como los sockets TCP, zlib y flujos crypto.

Observa que los objetos también están estrechamente relacionados. Mientras que una respuesta HTTP es un flujo legible en el cliente, es un flujo escribible en el servidor. Esto se debe a que en el caso HTTP, básicamente leemos de un objeto (http.IncomingMessage) y escribimos en el otro (http.ServerResponse).

Observe también cómo los flujos stdio ( stdin, stdout, stderr) tienen los tipos de flujo inversos cuando se trata de procesos hijo. Esto permite una manera realmente fácil de canalizar hacia y desde estos flujos desde los flujos stdio del proceso principal.

Un ejemplo práctico de flujos

La teoría está muy bien, pero a menudo no convence al 100%. Veamos un ejemplo que demuestra la diferencia que pueden marcar los flujos en el código en lo que respecta al consumo de memoria.

Primero vamos a crear un archivo grande:

const fs = require('fs');
const archivo = fs.createWriteStream('./big.file');

for(let i=0; i<= 1e6; i++) {
  file.write('Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.\n');
}

file.end();

Mira lo que usé para crear ese gran archivo. ¡Un stream escribible!

El módulo fs se puede utilizar para leer y escribir en archivos utilizando una interfaz de flujo. En el ejemplo anterior, estamos escribiendo en ese big.file a través de un flujo escribible de 1 millón de líneas con un bucle.

Ejecutando el script de arriba se genera un archivo de unos ~400 MB.

Aquí hay un simple servidor web Node diseñado para servir exclusivamente el big.file:

const fs = require('fs');
const servidor = require('http').createServer();

servidor.on('request', (peticion, respuesta) => {
  fs.readFile('./big.file', (error, data) => {
    if (error) throw error;
  
    respuesta.end(data);
  });
});

servidor.listen(8000);

Cuando el servidor reciba una petición, servirá el archivo grande usando el método asíncrono, fs.readFile. Pero bueno, no es que estemos bloqueando el bucle de eventos ni nada. Todo va genial, ¿verdad? ¿Verdad?

Bueno, veamos qué pasa cuando ejecutamos el servidor, nos conectamos a él, y monitorizamos la memoria mientras lo hacemos.

Cuando ejecuté el servidor, empezó con una cantidad normal de memoria, 8.7 MB:

Luego me conecté al servidor. Observe lo que ocurrió con la memoria consumida:

Vaya, el consumo de memoria ha subido a 434,8 MB.

Básicamente ponemos todo el big.file en memoria antes de escribirlo en el objeto de respuesta. Esto es muy ineficiente.

El objeto de respuesta HTTP (res  el objeto de respuesta HTTP) es también un flujo escribible. Esto significa que si tenemos un flujo legible que representa el contenido de big.file, podemos superponerlas y obtener prácticamente el mismo resultado sin consumir ~400 MB de memoria.

El módulo fs de Node puede proporcionarnos un flujo legible para cualquier archivo utilizando el método createReadStream. Podemos enviarlo al objeto de respuesta:

const fs = require('fs');
const servidor = require('http').createServer();

servidor.on('request', (peticion, respuesta) => {
  const src = fs.createReadStream('./big.file');
  src.pipe(respuesta);
});

servidor.listen(8000);

Ahora, cuando te conectas a este servidor, ocurre algo mágico (fíjate en el consumo de memoria):

¿Qué es lo que ocurre?

Cuando un cliente pide un archivo tan grande, lo transmitimos de uno en uno, lo que significa que no lo almacenamos en memoria. El uso de memoria creció unos 25 MB y eso es todo.

Puedes llevar este ejemplo al límite. Regenera el archivo big.file con cinco millones de líneas en lugar de sólo un millón, lo que llevaría el archivo a más de 2 GB, y eso es realmente más grande que el límite de búfer por defecto en Node.

Si intentas servir ese archivo utilizando fs.readFile, simplemente no puedes, por defecto (puedes cambiar los límites). Pero con fs.createReadStream, no hay ningún problema en transmitir 2 GB de datos al solicitante, y lo mejor de todo es que el uso de memoria del proceso será aproximadamente el mismo.

¿Listo para aprender sobre flujos ahora?

Flujos 101

Hay cuatro tipos fundamentales de flujos en Node.js: Lectura, escritura, dúplex, y transformación de flujos.

• Un flujo legible es una abstracción de una fuente desde la que se pueden consumir datos. Un ejemplo de ello es el método fs.createReadStream.
• Un flujo escribible es una abstracción de un destino en el que se pueden escribir datos. Un ejemplo de ello es el método fs.createWriteStream.
• Un flujo dúplex es tanto legible como escribible. Un ejemplo de ello es un socket TCP.
• Un flujo de transformación es básicamente un flujo dúplex que puede utilizarse para modificar o transformar los datos a medida que se escriben y se leen. Un ejemplo de ello es el flujo zlib.createGzip para comprimir los datos usando "gzip". Puedes pensar en un flujo de transformación como una función en la que la entrada es la parte del flujo que se puede escribir y la salida es la parte del flujo que se puede leer. También puedes oír referirse a los flujos de transformación como "flujos pasantes".

Todos los flujos son instancias de EventEmitter. Emiten eventos que pueden utilizarse para leer y escribir datos. Sin embargo, podemos consumir los datos en los flujos de una forma más sencilla utilizando el método pipe.

El método "pipe"

Esta es la línea mágica que debes recordar:

fuenteLegible.pipe(destinoEscribible)

En esta simple línea, estamos canalizando la salida de un flujo legible - la fuente de datos, como la entrada de un flujo escribible - el destino. La fuente tiene que ser un flujo legible y el destino uno escribible. Por supuesto, ambos pueden ser también flujos dúplex/transformados. De hecho, si estamos canalizando a un flujo dúplex, podemos encadenar llamadas de canalización como hacemos en Linux:

fuenteLegible
  .pipe(transformarFlujo1)
  .pipe(transformarFlujo2)
  .pipe(destinoEscribibleFinal)

El método pipe  retorna el flujo de destino, lo que nos permitió hacer el encadenamiento anterior. Para flujos a (legible), b and c (duplex), and d (escribible), podemos:

a.pipe(b).pipe(c).pipe(d)

# Que es equivalente a:
a.pipe(b)
b.pipe(c)
c.pipe(d)

# Que, en Linux, es equivalente a:
$ a | b | c | d

El método pipe es la forma más sencilla de consumir flujos. Por lo general, se recomienda utilizar el método pipe o consumir flujos con eventos, pero evite mezclar estos dos. Usualmente cuando estás usando el método pipe no es necesario utilizar eventos, pero si necesita consumir los flujos de forma más personalizada, los eventos serían el camino a seguir.

Eventos de flujo

Además de leer de una fuente legible y escribir en un destino escribible, el método pipe gestiona automáticamente algunas cosas por el camino. Por ejemplo, gestiona los errores, el fin de los archivos y los casos en los que un flujo es más lento o más rápido que el otro.

Sin embargo, los flujos también se pueden consumir con eventos directamente. A continuación se muestra el código simplificado equivalente a un evento de lo que el método pipehace principalmente para leer y escribir información:

# legible.pipe(escribible)

legible.on('data', (trozo) => {
  escribible.write(trozo);
});

legible.on('end', () => {
  escribible.end();
});

He aquí una lista de los eventos y funciones importantes que pueden utilizarse con flujos legibles y escribibles:

Los eventos y las funciones están relacionados de algún modo porque suelen utilizarse juntos.

Los eventos más importantes en un flujo legible son:

• El evento data, que se emite cada vez que el flujo pasa un trozo de datos al consumidor.
• El evento end, que se emite cuando no hay más datos que consumir del flujo.

Los eventos más importantes en un flujo escribible son:

• El evento drain, que es una señal de que el flujo escribible puede recibir más datos.
• El evento finish, que se emite cuando todos los datos se han vaciado en el sistema subyacente.

Los eventos y las funciones pueden combinarse para hacer un uso personalizado y optimizado de los flujos. Para consumir un flujo legible, podemos utilizar los métodos pipe/unpipe, o los métodos read/unshift/resume. Para consumir un flujo escribible, podemos convertirlo en el destino de pipe/unpipe, o simplemente escribir en él con la función write y llame al método end cuando hayamos terminado.

Modos de pausa y fluyente en flujos legibles

Los flujos legibles tienen dos modos principales que afectan a la forma en que podemos consumirlos:

• Puede estar en modo pausa.
• O en modo fluido.

Estos modos se denominan a veces "pull" y "push".

Todos los flujos legibles se inician por defecto en el modo pausado, pero pueden cambiarse fácilmente a fluido y de nuevo a pausado cuando sea necesario. A veces, el cambio se produce automáticamente.

Cuando un flujo legible está en modo de pausa, podemos utilizar la función read()para leer del flujo bajo demanda, sin embargo, para un flujo legible en el modo de flujo, los datos fluyen continuamente y tenemos que escuchar los eventos para consumirlos.

En el modo de flujo, los datos pueden perderse si no hay consumidores disponibles para manejarlos. Esta es la razón por la que, cuando tenemos un flujo legible en modo de flujo, necesitamos un manejador de eventos para la data. De hecho, solo añadiendo un manejador de eventos para la data cambia un flujo en pausa al modo de flujo y eliminar el manejador vuelve a poner el flujo en modo pausa. Parte de esto se hace por compatibilidad con la antigua interfaz de flujos de Node.

Para cambiar manualmente entre estos dos modos de flujo, puede utilizar la función resume() y pause().

Al consumir flujos legibles mediante la función pipe, no tenemos que preocuparnos de estos modos ya que pipe los gestiona automáticamente.

Implementando flujos

Cuando hablamos de streams en Node.js, hay dos tareas principales diferentes:

• La tarea de implantar los flujos.
• La tarea de consumirlos.

Hasta ahora sólo hemos hablado de consumir flujos. ¡Pongamos algunos en práctica!

Los ejecutores de los flujos suelen ser los que requiere el módulo stream.

Implementando un flujo escribible

Para implementar un flujo con capacidad de escritura, necesitamos utilizar la función Writable del módulo de flujo.

const { Escribible } = require('flujo');

Podemos implementar un flujo escribible de muchas maneras. Podemos, por ejemplo, extender el constructor Writable si queremos:

class miFlujoEscribible extends Escribible {
}

Sin embargo, prefiero el enfoque más simple del constructor. Simplemente creamos un objeto a partir del constructor Writable y pasarle una serie de opciones. La única opción obligatoria es la función write que expone el trozo de datos que se va a escribir.

const { Escribible } = require('flujo');

const outStream = new Escribible({
  write(trozo, codificacion, callback) {
    console.log(trozo.toString());
    callback();
  }
});

process.stdin.pipe(outStream);

This write method takes three arguments.

• El trozo suele ser un buffer a no ser que configuremos el flujo de otra manera.
• El argumento de codificación es necesario en ese caso, pero normalmente podemos ignorarlo.
• El callback es una función que necesitamos llamar después de que hayamos terminado de procesar el trozo de datos. Es lo que señala si la escritura fue exitosa o no. Para señalar un fallo, llame a la devolución de llamada con un objeto de error.

En outStream, nosotros simplemente imprimimos con la función console.log el trozo como una cadena y llamar a la devolución de llamada después de que sin un error para indicar el éxito. Este es un flujo de eco muy simple y probablemente no tan útil. Se hará eco de todo lo que reciba.

Para consumir este flujo, podemos utilizarlo simplemente con process.stdin, que es un flujo legible, por lo que podemos simplemente canalizar process.stdin hacia nuestro outStream.

Cuando ejecutamos el código anterior, cualquier cosa que escribamos en process.stdin se devolverá utilizando el método outStream console.log.

No es un flujo muy útil de implementar porque en realidad ya está implementado e incorporado. Esto es muy equivalente a process.stdout. Podemos canalizar stdin hacia stdout y obtendremos exactamente la misma función de eco con esta única línea:

process.stdin.pipe(process.stdout);

Implementa un flujo legible

Para implementar un flujo legible, necesitamos la interfaz Readable, y construir un objeto a partir de él, e implementar un método read() en el parámetro de configuración del flujo:

const { Legible } = require('flujo');

const enFlujo = new Legible({
  read() {}
});

Hay una forma sencilla de implementar flujos legibles. Podemos utilizar directamente push para insertar los datos que queremos que consuman los consumidores.

const { Legible } = require('flujo'); 

const enFlujo = new Legible({
  read() {}
});

enFlujo.push('ABCDEFGHIJKLM');
enFlujo.push('NOPQRSTUVWXYZ');

enFlujo.push(null); // No más datos

enFlujo.pipe(process.stdout);

Cuando usamos push en un objeto null, que significa que queremos señalar que el flujo no tiene más datos.

Para consumir este simple flujo de lectura, podemos simplemente canalizarlo en el flujo de escritura process.stdout.

Cuando ejecutemos el código anterior, estaremos leyendo todos los datos de enFlujo y enviarlo a la salida estándar. Muy sencillo, pero también poco eficiente.

Básicamente estamos empujando todos los datos en el flujo antes de canalizarlos a process.stdout. La mejor manera de hacerlo es enviar los datos a petición del consumidor. Podemos hacerlo implementando la función read()en el objeto de configuración:

const enFlujo = new Legible({
  read(tamaño) {
    // hay una demanda de datos... alguien desea leerlos.
  }
});

Cuando se llama al método de lectura en un flujo legible, la implementación puede enviar datos parciales a la cola. Por ejemplo, podemos empujar una letra a la vez, comenzando con el código de carácter 65 (que representa A), y el aumento que en cada empuje:

const enFlujo = new Legible({
  read(tamaño) {
    this.push(String.fromCharCode(this.currentCharCode++));
    if (this.currentCharCode > 90) {
      this.push(null);
    }
  }
});

enFlujo.currentCharCode = 65;

enFlujo.pipe(process.stdout);

Mientras el consumidor está leyendo un flujo legible, el método read continuará disparándose, y empujaremos más letras. Tenemos que detener este ciclo en algún lugar, y es por eso que una sentencia if para empujar null cuando el currentCharCode (código de carácter actual) es mayor que 90 (que representa Z).

Este código es equivalente al más simple con el que empezamos, pero ahora estamos empujando los datos bajo demanda cuando el consumidor lo pide. Usted siempre debe hacer eso.

Implementando flujos Dúplex/Transformación

Con los flujos dúplex, podemos implementar tanto flujos de lectura como de escritura con el mismo objeto. Es como si heredáramos de ambas interfaces.

A continuación se muestra un ejemplo de flujo dúplex que combina los dos ejemplos de escritura y lectura implementados anteriormente:

const { Duplex } = require('flujo');

const inoutStream = new Duplex({
  write(trozo, codificacion, callback) {
    console.log(trozo.toString());
    callback();
  },

  read(tamaño) {
    this.push(String.fromCharCode(this.currentCharCode++));
    if (this.currentCharCode > 90) {
      this.push(null);
    }
  }
});

inoutStream.currentCharCode = 65;

process.stdin.pipe(inoutStream).pipe(process.stdout);

Combinando los métodos, podemos utilizar este flujo dúplex para leer las letras de la A a la Z y también podemos utilizarlo por su función de eco. Canalizamos el flujo legible stdin en este flujo dúplex para utilizar la función de eco y canalizamos el propio flujo dúplex en el archivo escribible stdout para ver las letras de la A a la Z.

Es importante entender que los lados legible y grabable de un flujo dúplex funcionan de forma completamente independiente el uno del otro. Se trata simplemente de una agrupación de dos características en un objeto.

Un flujo de transformación es el flujo dúplex más interesante porque su salida se calcula a partir de su entrada.

Para un flujo de transformación, no tenemos que implementar la función read o write, sólo necesitamos implementar un método transform, que combina ambos. Tiene la firma del método write y podemos utilizarlo para insertar con push los datos también.

Aquí tienes un simple flujo de transformación que devuelve cualquier cosa que escribas en él después de transformarla a formato de mayúsculas:

const { Transform } = require('flujo');

const aMayuscula = new Transform({
  transform(trozo, codificacion, callback) {
    this.push(trozo.toString().toUpperCase());
    callback();
  }
});

process.stdin.pipe(aMayuscula).pipe(process.stdout);

En este flujo de transformación, que estamos consumiendo exactamente igual que en el ejemplo anterior de flujo dúplex, sólo implementamos el método transform(). En ese método, convertimos el trozo en su versión en mayúsculas y, a continuación, se usa el método push en esa versión como la parte legible.

Modo de flujos como objeto

Por defecto, los flujos esperan valores Buffer/String. Hay un marcador objectMode que podemos configurar para que el flujo acepte cualquier objeto JavaScript.

He aquí un ejemplo sencillo para demostrarlo. La siguiente combinación de flujos de transformación permite mapear una cadena de valores separados por comas en un objeto JavaScript. Así “a,b,c,d” se cionvierte a {a: b, c: d}.

const { Transform } = require('flujo');

const separadorDeComa = new Transform({
  modoDeLecturaObjeto: true,
  
  transform(trozo, codificacion, callback) {
    this.push(trozo.toString().trim().split(','));
    callback();
  }
});

const arrayAObjeto = new Transform({
  modoDeLecturaObjeto: true,
  modoDeEscrituraObjeto: true,
  
  transform(trozo, codificacion, callback) {
    const objeto = {};
    for(let i=0; i < trozo.length; i+=2) {
      objeto[trozo[i]] = trozo[i+1];
    }
    this.push(objeto);
    callback();
  }
});

const objetoAString = new Transform({
  modoDeEscrituraObjeto: true,
  
  transform(trozo, codificacion, callback) {
    this.push(JSON.stringify(trozo) + '\n');
    callback();
  }
});

process.stdin
  .pipe(separadorDeComa)
  .pipe(arrayAObjeto)
  .pipe(objetoAString)
  .pipe(process.stdout)

Pasamos la cadena de entrada (por ejemplo, “a,b,c,d”) a través de separadorDeComa que empuja un array como sus datos legibles ([“a”, “b”, “c”, “d”]). Añadir el marcador modoDeEscrituraObjeto en ese flujo es necesario porque estamos empujando un objeto allí, no una cadena.

A continuación, tomamos la matriz y la introducimos en el archivo arrayAObjeto. Necesitamos un marcador modoDeEscrituraObjetopara hacer que ese flujo acepte un objeto. También empujará un objeto (el array de entrada mapeado en un objeto) y por eso también necesitábamos el marcador modoDeLecturaObjeto ahí también. El último flujo objetoAString acepta un objeto pero expulsa una cadena, y por eso sólo necesitábamos un botón modoDeEscrituraObjeto ahí. La parte legible es una cadena normal (el objeto que se convirtió a string).

Los flujos de transformación incorporados en Node.js

Node tiene algunos flujos de transformación incorporados muy útiles. A saber, los flujos "zlib" y "crypto".

He aquí un ejemplo que utiliza la función zlib.createGzip() combinados con los flujos fs que se pueden leer y escribir para crear un código para comprimir archivos:

const fs = require('fs');
const zlib = require('zlib');
const archivo = process.argv[2];

fs.crearFlujoDeLectura(archivo)
  .pipe(zlib.crearGzip())
  .pipe(fs.crearFlujoDeEscritura(archivo + '.gz'));

Puedes usar este script para comprimir cualquier archivo que pases como argumento. Estamos canalizando un flujo legible para ese archivo en el flujo de transformación incorporado en "zlib" y luego en un flujo de escritura para el nuevo archivo comprimido. Simple.

Lo bueno de usar tuberías es que podemos combinarlas con eventos si lo necesitamos. Digamos, por ejemplo, que quiero que el usuario vea un indicador de progreso mientras el script está trabajando y un mensaje de "Hecho" cuando el script haya terminado. Ya que el método pipe devuelve el flujo de destino, podemos encadenar también el registro de manejadores de eventos:

const fs = require('fs');
const zlib = require('zlib');
const archivo = process.argv[2];

fs.crearFlujoDeLectura(archivo)
  .pipe(zlib.crearGzip())
  .on('data', () => process.stdout.write('.'))
  .pipe(fs.crearFlujoDeEscritura(archivo + '.zz'))
  .on('finish', () => console.log('Hecho'));

Así que con el método pipe, conseguimos consumir flujos fácilmente, pero aún podemos personalizar más nuestra interacción con esos flujos utilizando eventos cuando sea necesario.

Lo que es genial del método pipe es que podemos utilizarlo para componer nuestro programa pieza a pieza, de una forma mucho más legible. Por ejemplo, en lugar de escuchar el evento data más arriba, podemos simplemente crear un flujo de transformación para informar del progreso, y reemplazar el método .on()  con otra invocación del método .pipe():

const fs = require('fs');
const zlib = require('zlib');
const archivo = process.argv[2];

const { Transform } = require('flujo');

const reportarProgreso = new Transform({
  transform(trozo, encoding, callback) {
    process.stdout.write('.');
    callback(null, trozo);
  }
});

fs.crearFlujoDeLectura(archivo)
  .pipe(zlib.crearGzip())
  .pipe(reportarProgreso)
  .pipe(fs.crearFlujoDeLectura(archivo + '.zz'))
  .on('finish', () => console.log('Hecho'));

El flujo reportProgress es un simple flujo de paso, pero también informa del progreso a la salida estándar. Fíjate en cómo he utilizado el segundo argumento en el método callback() para empujar los datos dentro del método transform(). Esto equivale a empujar primero los datos.

Las aplicaciones de combinar flujos son infinitas. Por ejemplo, si necesitamos encriptar el archivo antes o después de gziparlo, todo lo que tenemos que hacer es canalizar otro flujo de transformación en ese orden exacto que necesitábamos. Podemos utilizar el módulo crypto de Node para eso:

const crypto = require('crypto');
// ...

fs.crearFluejoDeLectura(archivo)
  .pipe(zlib.crearGzip())
  .pipe(crypto.crearCipher('aes192', 'a_secret'))
  .pipe(reportarProgreso)
  .pipe(fs.crearFlujoDeEscritura(archivo + '.zz'))
  .on('finish', () => console.log('Hecho'));

El script anterior comprime y luego encripta el archivo pasado y sólo aquellos que tienen el secreto pueden utilizar el archivo de salida. No podemos descomprimir este archivo con las utilidades normales de descompresión porque está cifrado.

Para poder descomprimir cualquier cosa comprimida con el script anterior, necesitamos utilizar los flujos opuestos para "crypto" y "zlib" en orden inverso, lo cual es sencillo:

fs.crearFlujoDeLectura(archivo)
  .pipe(crypto.crearDecifrador('aes192', 'a_secret'))
  .pipe(zlib.crearGunzip())
  .pipe(reportarProgreso)
  .pipe(fs.crearFlujoDeLectura(archivo.slice(0, -3)))
  .on('finish', () => console.log('Hecho'));

Asumiendo que el archivo pasado es la versión comprimida, el código anterior creará un flujo de lectura a partir de él, lo canalizará en el flujo de "crypto" createDecipher() (utilizando el mismo secreto), canalice la salida de éste archivo en el flujo "fzlib" createGunzip(), y luego escribir las cosas de nuevo a un archivo sin la parte de la extensión.

Eso es todo lo que tengo para este tema. Gracias por leernos. Hasta la próxima.

Cuando decidí aprender a programar por mí mismo hace casi cuatro años, nunca había oído hablar del ciclo de vida del desarrollo de software, y mucho menos pensado en él.

Como un recién desarrollador, estaba enfocado en aprender las tecnologías que me ayudaran a obtener ese codiciado primer trabajo como desarrollador, no los matices de cómo esos equipos operaban.

Cuando en efecto aprendí sobre ellos, pensé que serían inservibles para mí porque me consideraba a mí mismo como un desarrollador web, no un desarrollador de software.

Desde entonces he aprendido que esto no podría estar más alejado de la realidad, y estos principios/prácticas juegan un rol muy importante en las actividades de mi día a día (ya sea que me dé cuenta o no).

Soy lo bastante afortunado de ver cómo el código que escribo, las características que construyo, y los "bugs" que inadvertidamente creo (más de los que me importa admitir) afectan al usuario final y su experiencia. Esa experiencia me ha ayudado a dar forma a lo que pienso acerca del proceso de construir productos y resolver problemas para mis usuarios.

He tenido algo de tiempo para pensar acerca de las diferencias (y similitudes) que cada uno de estos acercamientos ofrece. En su núcleo, cada uno está concentrado en entregar software de alta calidad, tan eficiente como lo eficientemente costoso como sea posible.

Profesionalmente, solo he usado una o dos de estas metodologías. Pero aún encuentro valor valor, en al menos un entendimiento básico de todas ellas.

Todas estas metodologías siguen una serie de fases similares a este diagrama:

Entonces, aquí están los métodos para el ciclo de vida del software (sin ningún orden en particular):

• Lean
• Agile
• Waterfall
• Iterative
• Spiral
• Dev Ops

Ahondemos en las diferencias y similitudes de cada método.

Lean

La metodología Lean se apoya fuertemente y se compone de siete principios.

Sin especificar el orden estos son:

1. Eliminar el desperdicio
2. Amplificar el aprendizaje
3. Decidir tan tarde como sea posible
4. Entregar tan rápido como sea posible
5. Empoderar al equipo
6. Construir integridad
7. Ver/Optimizar el panorama general

Cada principio tiene un propósito específico con beneficios que se complementan uno al otro.

Eliminar el desperdicio (características extra, trabajo incompleto, compromiso gerencial, etc) crea más valor para el cliente que, a cambio, aumenta su satisfacción.

Amplificar el aprendizaje permite a los equipos reinvertir en su habilidad productos a los clientes.

Decidir tan tarde como sea posible se refiere a todas las grandes decisiones, dando a los equipos un acercamiento basado en opciones o en conjuntos.  Estos permite a los equipos reunir hechos en lugar de opiniones que ayude a influir las decisiones cuando sean tomadas.

Entregar lo más rápido posible se explica por sí mismo: construya el producto lo más rápido posible para entregarlo a los clientes para su evaluación/iteración.

En un escenario típico, los gerentes reparten tareas/trabajos a los desarrolladores. Con la metodología Lean los desarrolladores "enseñan" a los gerentes cómo escuchar a los que "están en las trincheras" por lo tanto, influenciando en las decisiones/elecciones de la gerencia.

Esto ayuda a que los equipos se sientan más empoderados a que se expresen sobre las ideas y soluciones.

Haciendo de la integridad una regla en vez de una excepción significa que el cliente puede confiar en que el sistema está siendo construido. El cliente sabe que el sistema se construye para resistir la cantidad apropiada de crecimiento y "estiramiento" si lo necesita.

Me gusta pensar de la integridad como algo con los mismos lineamientos al sentarse en una silla. Cuando te sientas en la silla crees que está hecha con el mejor material que te aguantará cada vez que te sientes en ella por el resto de su vida útil. El cliente necesita de esa misma confianza en el producto construido.

Por último, ver y optimizar el panorama general se refiere al total del sistema construido. Al optimizar "el todo" miramos al software no como a la suma de varios componentes, sino como a una entidad grande que se optimiza para eficiencia.

Esto significa que durante el desarrollo,  el producto es dividido en piezas manejables y que los "bugs" inadvertidos no solo son descubiertos, sino además resueltos rápidamente.

Agile

Este es el acercamiento "falla rápido" para el desarrollo de software.

Hace énfasis en pequeños e incrementales lanzamientos con ciclos de lanzamiento andando. Con cada iteración los equipos apuntan a identificar y localizar pequeños problemas antes de que se hagan grandes.

Estos también significa que los equipos deben involucrar a las partes interesadas (gente/organizaciones que el código puede afectar en última instancia tales como gerentes, líderes técnicos, CTO's, y clientes) para obtener su retroalimentación.

Si eres freelance, las partes interesadas serían tus clientes - ultimadamente necesitas asegurar su satisfacción con el trabajo antes de continuar.

La metodología Agile es técnicamente una ramificación de la metodología Lean, con algunas diferencias notables - principalmente prioriza a la satisfacción del cliente desde el comienzo y permite a los equipos responder rápidamente a la retroalimentación del cliente.

Aunque está más allá de la pertinencia de este artículo, hay un marco de trabajo más complejo dentro de Agile llamado SCRUM. Esta metodología es usada por grandes, extremadamente complejos proyectos y ha sido usado incluso fuera del desarrollo de software.

Waterfall

La metodología Waterfall es, por mucho, la más antigua de todas. Nunca se supuso que fuera un modelo para el desarrollo de software y tuvo sus inicios en los mundos de la construcción y la manufactura.

Este acercamiento es simple en su estructura - concluye todas las partes de una fase antes de continuar con la siguiente fase con más impulso hacia el final del proyecto conforme las etapas son completadas. El inicio y la conclusión de cada etapa (excepto en la primera) depende de la finalización/transferencia de información de la etapa anterior.

Bajo el enfoque Waterfall, cada etapa tiene su propio plan de proyecto rígido que termina con pruebas para el trabajo completado previamente. Cabe señalar que este enfoque no se recomienda para proyectos más grandes o de mayor duración debido a la rigidez antes mencionada.

Piensa en la génesis de esta metodología y la entenderás más. Proviene del mundo de la construcción/fabricación donde es común completar una fase a la vez. Durante la construcción de una casa, no comenzaría a instalar la plomería antes de que se haya colocado el marco.

Esa no es la forma en que funciona el desarrollo de software en general. Como todos sabemos, a veces se hace necesario volver a visitar una fase que antes se creía terminada.

Iterative

Esto se conoce como el "enfoque repetitivo" o el enfoque de "hacerlo mejor la próxima vez" debido a las diferentes oportunidades que brinda para mejorar el producto con cada iteración del ciclo.

No lo sé todo (como todos :D), pero este es mi ciclo de vida favorito para el desarrollo. Creo que funciona mejor para mi situación actual tanto en mi carrera como freelance porque me permite "avanzar constantemente mientras mejoro las cosas".

Con el enfoque iterativo, los equipos implementan una solución, la prueban, evalúan su eficacia/rendimiento y luego identifican otras áreas de mejora. Esto sucede para cada ciclo (iteración) del proceso de desarrollo.

Con cada versión lanzada viene otra iteración hasta que el producto final se completa y está listo para su implementación a los usuarios.

Una de las grandes características del enfoque iterativo es que tú y su equipo obtienen una versión funcional del software desde el principio del proceso de desarrollo. Esto puede ser especialmente útil para mostrar a las partes interesadas para medir su respuesta/retroalimentación.

Uno de los grandes inconvenientes de este enfoque es que puede consumir una gran cantidad de recursos muy rápidamente. Imagine todas las personas, las horas, las correcciones de errores y los salarios que se incluyen en cada iteración del ciclo de desarrollo y obtendrá una buena imagen del uso de los recursos.

Dentro de este enfoque hay un subconjunto de principios desarrollado por Rational Software Corporation (comprado por IBM) llamado Rational Unified Process (RUP) que consta de 4 fases:

• Comienzo
• Elaboración
• Construcción
• Transición (lanzamiento del producto)

Este conjunto de principios pretende ser flexible y adaptarse a las necesidades de cada equipo que lo utilice.

Spiral

La metodología espiral es probablemente la más flexible de las seis. Es una metodología basada en riesgos: identificarlos y negarlos. El riesgo (identificación y aversión) impulsa cada decisión en este modelo. Se divide en cuatro sub-fases:

• Planeación (objetivos)
• Análisis de riesgos (identificar posibles obstáculos)
• Desarrollo y Testeo (la versión actual y la siguiente)
• Evaluación (inspección de la fase actual y planificar la siguiente)

Cada iteración de cada fase comienza con la planificación de la siguiente fase. De esta manera, los riesgos potenciales se identifican antes de que se encuentren. Esto también permite tener un plan de acción cuando surgen dichos riesgos.

Durante las fases, los equipos también trabajan para mitigar estos riesgos y su impacto en futuras iteraciones del desarrollo en espiral.

A medida que continúa el proceso de desarrollo, cada una de estas cuatro sub-fases se repite en forma de espiral. Esto permite múltiples rondas de refinamiento para cada sub-fase hasta su finalización.

Dev Ops

Si realiza una búsqueda rápida, no encontrará escasez de información sobre este método de ciclo de vida de desarrollo. Es el chico nuevo en el vecindario que une a los equipos de desarrollo de software y operaciones de tecnología de la información.

Estos equipos trabajan en conjunto para proporcionar actualizaciones pequeñas, pero impactantes a los productos que se presentan con frecuencia. A su vez, esto crea un ciclo continuo de retroalimentación y mejora que impulsa el desarrollo.

Esta metodología particular también es conocida por automatizar las partes manuales del desarrollo (piense en la implementación).

El objetivo general de esta metodología es, como la mayoría de las otras, acortar el ciclo de vida de desarrollo y proporcionar productos de calidad.

Uno de los inconvenientes de esta metodología es la mentalidad significativa y los cambios culturales dentro de una organización. Los equipos que pueden haber estado acostumbrados a trabajar en muchas cosas encuentran que sus tareas se reducen a solo una o dos.

Por ejemplo, un desarrollador de propósito general puede descubrir que ahora solo se le asigna la parte de testeo o la parte de experiencia del usuario final.

Trayendo todo a casa

Espero que ahora puedas ver la importancia y los beneficios de cada una de estas metodologías. Cada uno de estos posee sus propias fortalezas y debilidades.

Son, en su nivel más básico, un conjunto de pautas y principios que buscan entregar un trabajo eficiente y de alta calidad a las partes interesadas.

Cuando empecé a aprender a programar no tenía un mentor. Al compartir lo que he aprendido, espero ayudar a aquellos que están aprendiendo a programar cuando y donde puedan.

Quiero compartir tanta información y experiencia como me sea posible con otros desarrolladores. Si estás aprendiendo a programar por tu cuenta o si eres un desarrollador experimentado, espero que este artículo te ayude, aunque sea un poco.

Echa un vistazo a mi blog donde con frecuencia publico artículos sobre desarrollo web.

Mientras estás allí, ¿por qué no te suscribes a mi newsletter de noticias? Puede hacerlo en la parte superior derecha de la página principal del blog. Me gusta enviar artículos interesantes (los míos y de otros), recursos y herramientas para desarrolladores de vez en cuando.

Si tienes preguntas sobre este artículo o, en general, mis DM están abiertos -- ven a saludarme en Twitter o en cualquiera de mis otras cuentas de redes sociales que puedes encontrar debajo del newsletter, regístrate en la página principal o en mi perfil aquí :)

!Que tengas un día increíble y feliz coding, amig@!