Expresiones y sentencias, ¿luego qué?

Hasta ahora hemos visto cómo el código que escribimos está compuesto de partes más pequeñas, como expresiones y sentencias. Pero, ¿cuántas sentencias y/o expresiones son necesarias para considerarlo un algoritmo? ¿En qué momento un conjunto de algoritmos se convierte en lo que llamamos frameworks? ¿Y cuándo un framework se diferencia de una utilidad o una biblioteca?

📚 Biblioteca: en algunas ocasiones también llamada librería, debido a una mala traducción de la palabra en inglés library.

Si quisiéramos explicarlo de forma práctica, podríamos pensar en el diseño atómico donde las expresiones generan sentencias, las sentencias algoritmos y estos finalmente código.

• Las expresiones son la mínima unidad con significado funcional.
• Las sentencias están compuestas por una o más expresiones.
• Los algoritmos son un conjunto de múltiples sentencias y expresiones.
• El código es uno o varios algoritmos enfocados en resolver una necesidad de producto o negocio.

💧 Algoritmo y código a veces se usan como sinónimos. Sin embargo, de manera coloquial, muchas veces se le llama algoritmo a una parte específica de un producto. Podemos escuchar cosas como “el algoritmo de búsqueda” o “el algoritmo de descuentos”, etc.

Las expresiones son las unidades más pequeñas, que se van componiendo hasta generar código.

El código puede ser muchas cosas

Cuando hablamos de código, podemos estar refiriéndonos a muchas cosas, similar a lo que ocurre con la palabra algoritmo. Sin embargo, ciertas piezas de código pueden categorizarse según su función y tamaño y aun así, todas siguen considerándose “código”.

• Utilidades: piezas de código pequeñas y específicas que resuelven una tarea concreta.
• Bibliotecas: conjuntos de utilidades agrupadas con un propósito común.
• Frameworks: bibliotecas más grandes que incluyen múltiples utilidades y añaden estructura, reglas o convenciones para desarrollar un producto.

Las utilidades, bibliotecas y frameworks pueden verse como distintos tipos dentro del ecosistema del código: desde los más simples hasta los más sofisticados.

Algoritmos en el codigo

Un algoritmo no siempre es algo complejo o misterioso. Muchas veces lo usamos sin darnos cuenta, porque no es más que una secuencia de pasos para resolver un problema específico, como ya hemos discutido antes. En un proyecto, solemos escuchar frases como “el algoritmo de búsqueda” o “el algoritmo que calcula los descuentos”. En esos casos, hablamos de fragmentos concretos dentro de un sistema más grande.

Sin embargo, los algoritmos por sí solos no son un producto terminado. Y, en el contexto de negocio, cuando se habla de “algoritmo” muchas veces no se refieren a una pieza de código puntual, sino a un concepto más amplio que puede abarcar múltiples algoritmos o incluso un codebase completo.

Un ejemplo muy común es el “algoritmo de las redes sociales” que decide qué vemos. En la práctica no es un único algoritmo como lo hemos definido aquí: una secuencia de sentencias y expresiones, sino un conjunto enorme de algoritmos, repositorios y sistemas. Pero se le llama “algoritmo” porque suena atractivo, automatizado, casi mágico. Funciona como marketing, transmite la idea de objetividad y neutralidad, aunque detrás haya decisiones humanas y reglas mucho más complejas.

En definitiva, a nivel técnico, un algoritmo sigue siendo lo que describimos aquí. Solo hay que tener presente que, fuera del ámbito estrictamente técnico, la palabra se usa muchas veces para describir una característica “mágica” de un producto.

Utilidades y Helpers

Cuando comenzamos a organizar un poco nuestras piezas de código, aparece una categoría muy común: las utilidades.

Las utilidades suelen ser funciones pequeñas que no dictan cómo debe funcionar la aplicación, sino que ayudan a resolver tareas muy específicas, generalmente repetitivas.

Un ejemplo clásico son los formatos. Imagina que necesitamos transformar un número en un formato de moneda, por ejemplo de 2333.4 a $2,333.40, o que recibimos una fecha en el estándar ISO 8601, por ejemplo 2025-10-12T22:27:06.416Z y queremos mostrarla como Domingo, Oct 13, 12:27 AM o incluso de una forma más humana como Hace 32 minutos.

Las utilidades para dar formato son solo un tipo. También existen utilidades para manipular objetos, arreglos, cadenas de texto, eventos y mucho más.

Lo interesante de las utilidades es que, al resolver problemas comunes, pueden usarse prácticamente en cualquier proyecto. Sin embargo, hay otras funciones que, aunque cumplen un rol similar, dependen demasiado de la lógica de negocio o del contexto particular de un proyecto. A esas se les suele llamar helpers (ayudantes).

Tener clara la distinción entre utilidades y helpers hace más fácil la tarea de reutilizar código en futuros proyectos. Las utilidades casi siempre pueden moverse de un lado a otro sin problemas, mientras que los helpers tienen más limitaciones porque dependen de un caso de uso concreto. Aun así, si un proyecto comparte metas o características similares, un helper también puede ser reutilizado.

Algunos ejemplos comunes de helpers son:

• Formateo de plantillas de correo electrónico: el contenido suele ser muy particular para cada producto.
• Generación de URLs dinámicas: unir rutas y parámetros para construir enlaces dentro de una aplicación web.

En ambos casos cumplen la misma idea: ayudan, pero solo dentro de su propio contexto.

Bibliotecas

Otra categoría que suele clasificar el tipo de código es cuando se acumula una serie de utilidades orientadas a un propósito común. A esta colección se le llama biblioteca, y su idea principal es que esté lista para ser distribuida y utilizada en cualquier proyecto.

Las bibliotecas suelen nacer cuando un conjunto de soluciones comienza a repetirse una y otra vez: funciones para manejar fechas, hacer solicitudes HTTP o manipular interfaces. En lugar de reescribirlas en cada proyecto, se agrupan, se documentan y se comparten para facilitar su reutilización.

Además de ahorrar tiempo, las bibliotecas aportan consistencia: permiten resolver los mismos problemas de forma uniforme, sin depender de cómo cada persona los implemente. Por lo que, crear una biblioteca implica pensar en algo más que el código: hay que diseñar una interfaz clara, mantener versiones y documentar su uso para que otros puedan entenderla y adoptarla fácilmente.

Lo importante es que una biblioteca está al servicio del desarrollador, no impone reglas ni estructura. Somos nosotros quienes decidimos cómo y cuándo usarla. Sin embargo, cuando una biblioteca crece demasiado y empieza a definir convenciones o patrones de trabajo, deja de ser solo una colección de utilidades para convertirse en algo más grande: un framework.

Frameworks

Aunque quisiera decir que el patrón se repite y que un framework (en español, marco de trabajo) es simplemente un conjunto de bibliotecas, la verdad es que va mucho más allá de eso.

Es inevitable que un framework incluya sus propias utilidades, helpers y, en muchos casos, múltiples bibliotecas. Aunque, lo que realmente lo diferencia de otras piezas de código es su objetivo. Un framework tiene una serie de opiniones y decisiones incorporadas sobre cómo deben hacerse las cosas, con el propósito de que no tengamos que idear una solución desde cero para cada problema común.

Mientras que una biblioteca está a nuestro servicio, en un framework ocurre lo contrario: nosotros trabajamos dentro de su estructura. El framework es quien decide cuándo y cómo se ejecuta nuestro código.

Podríamos clasificar los frameworks en tres grandes grupos:

• Frameworks convencionales: se enfocan en resolver un área específica del desarrollo, como el backend, la interfaz o la comunicación entre componentes. Son flexibles y permiten decidir con qué otras herramientas combinarlos.
• Frameworks full-stack: abarcan todo el proceso de construcción de una aplicación. Definen cómo se organiza el proyecto y suelen incluir desde la estructura de la base de datos hasta el código del servidor y la interfaz de usuario. Requieren menos intervención manual y están casi listos para usarse con el propósito para el que fueron creados, como un e-commerce o un sistema de gestión de contenido.
• Metaframeworks: se construyen sobre otros frameworks ya existentes y ofrecen un nivel adicional de integración y escalabilidad. No dictan exactamente cómo hacer cada cosa, pero sí incluyen herramientas y convenciones para facilitar el desarrollo, optimizar el rendimiento y escalar aplicaciones complejas.

En cualquier caso, todos los frameworks comparten una idea común: buscan acelerar el desarrollo y ofrecer coherencia. Nos liberan de decisiones repetitivas, aunque a cambio nos piden aceptar sus reglas.

Qué no se nos olvide lo más importante: El producto

En el desarrollo de software, además de las clasificaciones que ya vimos, existen muchísimos otros conceptos como patrones, paradigmas, estrategias de diseño y formas de construir soluciones más efectivas. Algunos enfoques son más opinionados, nos dicen cómo debemos hacer las cosas y otros más libres, permitiéndonos decidir cómo usar las herramientas.

Al final, elegir qué framework, utilidad o biblioteca usar suele ser una cuestión de preferencia personal o de adaptación de la comunidad. Los frameworks y bibliotecas que perduran no siempre son los técnicamente mejores, sino los que logran ser adoptados con facilidad, cuentan con buena documentación, o tienen detrás una comunidad o empresa que les da soporte constante. A veces se vuelven populares porque son innovadores; otras, simplemente porque llegaron en el momento justo.

Pero nada de eso garantiza el éxito de un producto. Usar el “mejor” framework o la biblioteca más moderna no asegura que lo que construyas tenga impacto. Lo verdaderamente importante, y lo que no debemos olvidar, es el propósito final: el producto, servicio o idea que estamos creando.

A los usuarios les da igual si usaste la última biblioteca, el lenguaje de moda o una herramienta low-code. Lo único que realmente importa es que el producto funcione y resuelva su necesidad.

Así que, cuando elijas un framework o una biblioteca, no te preocupes tanto por cuál es “el mejor”. Revisa si se alinea con tu propósito, si tiene una comunidad activa y buena documentación. Y si simplemente te gusta, también está bien. Lo importante es que te permita construir algo que te motive y aporte valor.

Finalmente, recuerda que también es válido no usar frameworks ni bibliotecas y crear los tuyos propios cuando lo necesites. Solo asegúrate de que no se vuelva paradójico: pasar más tiempo construyendo herramientas que desarrollando el producto para el que realmente las necesitabas.