Forem: Jean Karlo Obando Ramos

La IA no reemplazará a los desarrolladores de software

Jean Karlo Obando Ramos — Tue, 23 Sep 2025 03:49:00 +0000

Originalmente publicado en: https://blog.jeankaobando.com/blog/2025/go-hire-humans/

Tabla de Contenidos

Introducción
Siempre existió un deseo de reemplazar a los desarrolladores
¿Qué significa ser un desarrollador de Software?
El paradigma de Jevons
Conclusión
Recursos

Introducción

Los últimos avances en el desarrollo de la Inteligencia Artificial, especialmente en el campo de la IA generativa, han puesto al alcance de todos herramientas como ChatGPT, Claude, DeepSeek, entre otras, que han revolucionado completamente la manera en la que vemos al mundo y el rol del ser humano en él.

En esa nueva visión existe una tendencia por construir productos y resolver problemas usando solamente Inteligencia Artificial. Lo que se ve reflejado, por ejemplo, en el mensaje provocador de la startup Artisan “Stop Hiring Humans”.

La verdad es que gran cantidad de actividades, muchas de ellas creativas, parece que pueden ser ejecutadas a través de esta tecnología. Cada día es más común encontrarnos con posts, imágenes, videos, música e incluso series realizadas en su mayoría con estas herramientas y con poca intervención humana. Esto ha puesto sobre la mesa un debate interesante a la vez que alarmante para muchos. ¿Qué profesiones van a desaparecer con la “llegada” de la IA?

Dentro del grupo de profesiones que se dice van a quedar obsoletas es la del “desarrollador de software”. Esto se evidencia en la cantidad de productos que prometen que personas no técnicas puedan escribir código y crear sistemas complejos sin tener conocimientos sobre lenguajes de programación o algún otro elemento relacionado con el software, un ejemplo de ello es el Vibe Coding.

Andrej Karpathy resumió esta tendencia en X con el siguiente mensaje: “El Inglés es el nuevo lenguaje de programación popular”.

Sin embargo, esta idea no es nueva y la intención de reemplazar a los desarrolladores siempre ha estado ahí. En este blog buscaré argumentar por qué creo que la IA no va a reemplazar a los desarrolladores de software, por el contrario, creará más demanda de profesionales en esta área.

Siempre existió un deseo de reemplazar a los desarrolladores

En el año de 1959, cuando el uso de las computadoras estaba reservado a los complejos militares y centros de investigación, los lenguajes de programación predominantes eran Assembly o Fortran, lenguajes tan complejos que su uso estaba reservado a unos pocos.

En ese contexto nace COBOL (COmmon Business-Oriented Language), un lenguaje de programación basado en el Inglés cuyo propósito era ofrecer un medio para que personas sin conocimiento en computadoras pudieran programarlas para resolver sus problemas, como los contadores o asesores financieros.

COBOL significó para la época pasar de este código escrito en Assembly para sumar dos números

section .data
    num1    db 5
    num2    db 7
    result  db 0
    msg     db "Resultado: ", 0
    msglen  equ $ - msg
    newline db 10

section .bss
    buf     resb 20          ; buffer amplio para número en ASCII

section .text
    global _start

_start:
    ; --- suma ---
    mov     al, [num1]
    add     al, [num2]
    mov     [result], al

    ; --- escribir "Resultado: " ---
    mov     rax, 1           ; sys_write
    mov     rdi, 1           ; stdout
    mov     rsi, msg
    mov     rdx, msglen
    syscall

    ; --- convertir result (byte) a decimal en buf ---
    movzx   eax, byte [result]   ; número en EAX
    lea     rdi, [buf + 20]      ; puntero al final
    mov     ebx, 10
    cmp     eax, 0
    jne     .conv
    dec     rdi
    mov     byte [rdi], '0'
    jmp     .done

.conv:
    .loop:
        xor     edx, edx
        div     ebx              ; eax = eax/10, edx = resto
        add     dl, '0'
        dec     rdi
        mov     [rdi], dl
        test    eax, eax
        jnz     .loop

.done:
    ; longitud = (buf+20) - rdi
    mov     rax, buf
    add     rax, 20
    sub     rax, rdi
    mov     rdx, rax            ; rdx = longitud
    mov     rsi, rdi            ; rsi = inicio del número

    ; --- escribir número ---
    mov     rax, 1              ; sys_write
    mov     rdi, 1              ; stdout
    syscall

    ; --- salto de línea ---
    mov     rax, 1
    mov     rdi, 1
    mov     rsi, newline
    mov     rdx, 1
    syscall

    ; --- salir ---
    mov     rax, 60             ; sys_exit
    xor     rdi, rdi
    syscall

a este conjunto de sentencias más legibles

 IDENTIFICATION DIVISION.
       PROGRAM-ID. SUMA.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 NUM1 PIC 9(2) VALUE 5.
       01 NUM2 PIC 9(2) VALUE 7.
       01 RESULT PIC 9(3).
       PROCEDURE DIVISION.
           ADD NUM1 TO NUM2 GIVING RESULT
           DISPLAY "El resultado es: " RESULT
           STOP RUN.

Y esta fue la promesa que hizo COBOL al mundo. No necesitarías personas dedicadas solamente a escribir código, todos podrían hacerlo.

❝En la reunión convocada en el Pentágono, a la que asistieron 41 personas, los participantes imaginaron un lenguaje de programación que hiciera uso de un tipo básico de inglés y que permitiera a gerentes, programadores y analistas de sistemas comunicarse con cualquier computadora disponible.❞

— FedTech Magazine, “How COBOL Became the Early Backbone of Federal Computing” (2017)

Pero este propósito no se cumplió. La complejidad que representaba crear sistemas financieros, de pago de nómina o seguros generó una demanda de expertos no solamente en COBOL sino en traducir reglas de negocio en sistemas informáticos eficientes, que puedan operar a través del tiempo.

De hecho, esta demanda generó que la programación dejara de ser una habilidad más dentro de otras profesiones como las matemáticas o la ingeniería electrónica y se convirtiera en una nueva área como tal: la Ingeniería de Software, en 1968.

De ahí en adelante siempre ha existido la necesidad de que la construcción del software no esté delegada a un grupo de profesionales sino que este al alcance de todos. Esto ha ido desde los 4GL, pasando por CASE Tools o la programación visual, y en los últimos años herramientas de low code, vibe coding e IA generativa.

Que el “Inglés” sea el lenguaje de programación más popular no es una idea nueva de Andrej Karpathy, ha sido la misión de la industria desde su creación: construir sistemas simplemente usando lenguaje natural.

Pero así logremos construir un sistema 100% en lenguaje natural, eso no va a eliminar la necesidad de ingenieros o desarrolladores de software, porque su función no está en escribir código, su función va más allá.

¿Qué significa ser un desarrollador de Software?

Siempre me llamó la atención ver cómo algunos de mis compañeros de la universidad pasaban horas antes de una prueba de programación estudiando el código, memorizándolo. Eso para mí, nunca tuvo ningún sentido, era poco probable que el ejercicio visto en clase fuera el mismo de la prueba. Los exámenes requerían comprender cómo utilizar un conjunto de sentencias (if, else, for, do while) junto con estructuras de datos (arrays, maps, objects) para resolver un problema, sea el que sea.

❝Programas = Algoritmos + Estructuras de Datos.❞

— Niklaus Wirth, Algorithms + Data Structures = Programs (1976)

Con el paso del tiempo he ido comprendiendo también que no soy un desarrollador de Frontend o Backend, o que mi carrera no se define por si desarrollo en JavaScript o Python. He tenido la oportunidad de trabajar con diferentes herramientas y en diversos escenarios, que al final he comprendido lo que soy: un desarrollador de Software. Pero, ¿qué significa eso para mí?

Ser desarrollador de Software significa contar con un conjunto de habilidades y herramientas (principalmente mentales) que permiten resolver problemas de la vida real a través de sistemas informáticos. Mi trabajo no es escribir código, no es hacer una página web o una API. Mi trabajo es tomar una necesidad como la creación de una cuenta bancaria, con sus reglas y asociaciones e implementarla a través de un sistema.

Pero para llegar a esa implementación es importante comprender el contexto sobre el cual se presenta esa necesidad, entender a las personas que van a utilizar el producto y aquellos que están interesados en crearlo. Además, conocer el conjunto de herramientas que ofrece el mercado para implementar este tipo de soluciones, profundizar en patrones y buenas prácticas, explorar frameworks, de tal manera que los sistemas no funcionen solamente en su lanzamiento, sino que vivan y evolucionen a través del tiempo de manera sustentable.

Creo que esta idea la podría resumir en la siguiente cita:

❝Cualquiera puede escribir código que una computadora pueda entender. Los buenos programadores escriben código que los humanos puedan entender.❞

— Martin Fowler, Refactoring: Improving the Design of Existing Code (1999)

Como dice Martin Fowler, cualquiera puede escribir código que las máquinas entiendan, incluida la IA. Yo le puedo pedir a mi ChatGPT que genere código en Assembly para sumar dos números, cómo el que puse en la sección anterior (y funciona, pueden probarlo). Pero como se declaró en 1968, la ingeniería de software presenta otros retos como: el diseño de sistemas, la abstracción de reglas de negocio, la mantenibilidad, performance, la toma de decisiones en base a presupuestos, equipos y contextos. Ese es un trabajo creativo, ese es un trabajo humano.

El paradigma de Jevons

En un capítulo del podcast “Software Architecture Hour with Neal Ford” que tuvo como invitado a Kent Beck, co creador de Extreme Programming, se planteó esta pregunta: ¿la IA reemplazará a los desarrolladores?

En ese espacio, que me inspiró para escribir este blog, Kent Beck explica el paradigma de Jevons que describo a continuación:

📖 Paradigma de Jevons

Cuando una innovación tecnológica aumenta la eficiencia con la que se utiliza un recurso, en lugar de reducir su consumo total, a menudo provoca un incremento en la demanda de ese recurso.

Si volvemos al año 1959, cuando nació COBOL, el principal reto era sumar dos números sin matar la memoria. Con COBOL logramos construir sistemas empresariales, el desarrollo de lenguajes de alto nivel como C++ o Java permitieron expandir el uso de las computadoras a la música o el cine, la creación de JavaScript permitió la evolución de la Web, y Python logró que el análisis de datos y el Machine Learning fuera una realidad. Sin cada uno de estos pasos que optimizaron la construcción de software, plataformas como Netflix o Twitch no serían ni siquiera imaginables.

Kent Beck señala que la inclusión de la Inteligencia Artificial es un paso más en esa optimización. Problemas que antes nos tomaban 4 o 5 horas resolver ahora lo podemos hacer en cuestión de minutos con el apoyo de ChatGPT, Claude o Copilot.

¿Eso significa que vamos a requerir de menos programadores? La respuesta es no, eso significa que van a existir nuevos casos de uso para la programación, nuevos problemas a resolver que todavía no imaginamos y por ende la necesidad de desarrolladores e ingenieros de software no solo se mantendrá, sino que aumentará.

Conclusión

La promesa de que la IA va a reemplazar a los desarrolladores de software no es verdadera, ni tampoco nueva. El desarrollo de software va más allá de la creación de código, requiere usar un conjunto de herramientas para resolver problemas y atender necesidades de los usuarios. El llegar a definir esa solución y llevarla a cabo es un tarea humana.

Eso no significa que como desarrolladores o ingenieros nos debemos relajar. Esta nueva era exige de nosotros mayor preparación y estudio. Si la IA me permite resolver un problema de días en horas ¿qué haremos con el tiempo restante? Esa pregunta es clave y quienes aprovechen mejor su tiempo son los que menos riesgo tendrán de dejar de ser relevantes, pero eso es tema para otro post.

Por ahora me gustaría cerrar modificando el mensaje de Artisan: Ve y contrata humanos, su era no ha terminado.

Recursos

Karpathy, A. [@karpathy]. (2023, enero 25). The hottest new programming language is English [Tweet]. X. https://x.com/karpathy/status/1617979122625712128
The Guardian. (2025, marzo 16). AI coding threatens programmers’ jobs but experts say human expertise still crucial. The Guardian. https://www.theguardian.com/technology/2025/mar/16/ai-software-coding-programmer-expertise-jobs-threat
FedTech Magazine. (2017, septiembre 18). How COBOL became the early backbone of federal computing. FedTech. https://fedtechmagazine.com/article/2017/09/how-cobol-became-early-backbone-federal-computing
IsThisIt.nz. (2022, diciembre 20). 1968 NATO Software Engineering Conference [Blog post]. https://isthisit.nz/posts/2022/1968-nato-software-engineering-conference/
Richards, M., & Ford, N. (2021). Software architecture hour: Evolutionary architecture with Neal Ford and Mark Richards [Video]. O’Reilly Media. https://learning.oreilly.com/videos/software-architecture-hour/0636920902454/0636920902454-video345197/

Implementando software centrado en el negocio

Jean Karlo Obando Ramos — Sat, 13 Sep 2025 02:03:00 +0000

Originalmente publicado en: https://blog.jeankaobando.com/blog/2025/ddd-serie-part-4-implementing-bc/

Tabla de Contenidos

Introducción
¿Qué tenemos que implementar?
DDD en acción
Screaming Architecture
Conclusiones
Recursos

Introducción

A lo largo de esta serie hemos comentado la importancia de construir software con el negocio en el centro. Para ello, nos hemos apoyado del acercamiento propuesto por Eric Evans en el 2003, Domain-Driven Design.

Hemos hecho énfasis en la importancia del lenguaje y cómo delimitarlo dentro de un contexto es muy útil al momento de construir software. Por lo general, una organización (dominio) divide sus problemas en partes (subdominios) sobre los cuales se establecen un conjunto de términos, acciones y reglas que solo tienen sentido (y es bueno que así sea) en ese contexto. Finalmente, comentamos que estos elementos se delimitan según DDD en “Bounded Contexts”.

En este blog, el último de esta serie, es momento de que el software escuche. Es por ello que nos vamos a adentrar en la implementación de la acción de negocio “Generar órdenes de envío”.

Comencemos.

¿Qué tenemos que implementar?

A partir del Bounded Context descrito en el capítulo anterior (imagen 1), tenemos la siguiente información sobre la acción ‘Generar órdenes de envío’.

Imagen 1. Bounded Context de Envíos (Shipments)

Intervienen dos Bounded Context en la acción, Shipments (para envíos) y Orders (órdenes de pago). Este último desencadena el proceso.
Tenemos a la mano una regla de negocio clara: “una orden debe estar confirmada o pagada para poder generar una orden de envío”
Nuestra Entidad “Shipment” (Envío) debe tener un trackingID, una dirección válida, el estado inicial debe ser “creado” y se debe registrar la fecha de creación.
La dirección es un Value Object porque no tiene un ID, pero sí reglas claras, como que solo se permiten envíos a Quito y Guayaquil en Ecuador.
Finalmente, el resultado de la generación debe ser emitir un evento que será receptado por el mismo Bounded Context.

Con estos elementos ya tenemos todo lo necesario para empezar a programar.

DDD en acción

Para el propósito de este blog no nos vamos a detener en la configuración del proyecto. Ustedes pueden descargarlo en el siguiente repositorio de Github (no olvides dejar una estrella) e instalarlo siguiendo la descripción del README.

Comencemos con la estructura, como se observa en la imagen 2, a nivel del repositorio se deja claro que por ahora vamos a trabajar con dos Bounded Context: Orders y Shipments. Siendo estos los únicos módulos que está importando el proyecto central.

Imagen 2. Estructura del Proyecto

Ahora centrémonos en la estructura de Shipping. Para ello hemos decidido organizar el código aplicando “Clean Architecture” que es una metodología propuesta por Robert C. Martin y que aplica perfecto para DDD.

Como se ve en la imagen 3, siguiendo esta metodología hemos dividido nuestra implementación de Shippings en 3 partes:

Application: dónde van a vivir todas las acciones de negocio definidas
Domain: dónde se definen las entidades y value objects.
Presentation: dónde se implementan los mecanismos para que el exterior pueda interactuar con estas acciones de negocio. Estas pueden ser interfaces, controladores o eventos.

Clean Architecture plantea una capa más que es Infrastructure dónde están todos los elementos externos cómo apis, bases de datos, cache; sin embargo al no utilizarlos todavía no los hemos definido.

Imagen 3. Bounded Context Envíos con Clean Architecture

Veamos cómo definimos nuestra acción “generar órdenes de envío” en nuestro caso de uso. Cómo se ve en la imagen 4, el caso de uso debe describir la acción tal cual la planteo el negocio. En nuestro caso evaluamos la regla sobre el estado de la orden asociada, validamos que la dirección sea válida, generamos la orden y notificamos. Si nos fijamos bien, aquí no debe haber referencias a frameworks o bases de datos, estamos ejecutando la lógica de negocio.

Imagen 4. Caso de uso Generar orden de envío

Ahora bien, por que tenemos que crear una dirección y no simplemente pasamos los valores recibidos al constructor de la orden. La respuesta es que la dirección es un elemento que puede tener sus propias reglas. Ejemplo: las ciudades de envío solo pueden ser Quito o Guayaquil. Al encapsular esto en el Value Object como se ve en la imagen 5 no solamente agrupamos estas reglas en dirección, sino que si tenemos que implementar otra acción como por ejemplo “reubicar orden” no necesitamos volver a poner las reglas, estás viven en el value object. Ahí el valor.

Imagen 5. Value Object Address

Nuestras entidades son el corazón de nuestro Bounded Context, dado que sobre ellas ejecutamos acciones de negocio. En la imagen 6 vemos como la Entidad garantiza que la creación correcta del objeto cumpla lo especificado por el negocio. Un detalle importante es que solo acepta un value object dirección como parámetro, ahí garantiza que la dirección sea válida. Sobre esta entidad se pueden extender otras acciones cómo “Asignar Transportista” o “Confirmar Entrega”

Imagen 6. Entidad Shipment

Finalmente, la capa de presentación es lugar dónde definimos cómo los sistemas externos pueden interactuar con nuestras acciones de negocio. Para nuestro caso habíamos definido que el evento “Orden Pagada”, desencadena la generación del envío y esto está en el código como se ven en la imagen 7.

Imagen 7. Capa de Presentación

Con todos estos elementos juntos podemos ya generar una primera versión de la acción “Generar ordenes de envío” que cumple con todos los requisitos de negocio. Cómo pueden ver en este proyecto no hemos topado nada de base de datos o implementación de librerías complejas. Nuestro foco ha estado 100% en implementar una funcionalidad de nuestro sub dominio.

Veamos el resultado en la imagen 8.

Imagen 8. Generación de orden de envío exitosa

También podemos ver el ejemplo de cuando una regla falla, por ejemplo el contar con un estado de orden asociada diferente a los permitidos o una dirección no válida como en la imagen 9 y 10

Imagen 9. Error por estado de orden asociada no válida

Imagen 10. Error por dirección no válida

Lo importante a recalcar de este ejercicio es que el código representa claramente lo expuesto por el negocio. Robert C. Martin a esto lo llamó Screaming Architecture. Veamos de qué trata.

Screaming Architecture

En su libro Clean Architecture, Robert C. Martin, plantea el siguiente ejemplo para describir cómo debe organizarse el software:

¿Qué pasa cuando vemos el plano de una casa? Este va a mostrar que va a existir un cuarto, una cocina, un área de estudio y un jardín; cada lugar con las dimensiones y elementos necesarios para que cada espacio cumpla su función. Lo mismo pasa si tomamos el plano de una oficina, este tendrá una sala de reuniones, cubículos de trabajo, baños, etc. De tal manera que cualquier persona que vea estos diseños entiende que se trata de un plano de una casa o una oficina.

Imagen 11. Ejemplo de plano de una casa

Robert C. Martin señala que lo mismo debe pasar con nuestros sistemas. Cualquier persona que los vea, aún así no entienda nada de código, debería saber solamente con la estructura del proyecto a qué se refiere el sistema. Este concepto lo denomina Screaming Architecture.

Esto es importante, porque, cómo lo hemos comentado durante esta serie, existen muchas veces una desconexión entre el código y las necesidades del negocio, dando como resultado proyectos que a simple vista nos dicen mucho sobre el framework que utiliza pero muy poco sobre lo que hace el sistema.

❝ Las arquitecturas de software son estructuras que soportan los casos de uso del sistema. ❞

— Robert C. Martin, Clean Architecture

Aplicar DDD nos ayuda a cumplir este objetivo dado que el código está guiado por acciones de negocio y no por las herramientas tecnológicas vamos a usar.

Como hemos visto en la construcción de nuestra acción “Generar órdenes de envío”, la distribución del código no está realizada por capas tecnológicas como el patrón Modelo-Vista-Controlador, no se ha definido que Base de Datos se va a usar, ni siquiera he comentado que framework de NodeJs estoy usando; nuestra conversación se ha centrado en implementar el caso de uso, lo otro puede venir después.

❝ Una buena arquitectura de software permite aplazar y retrasar las decisiones sobre frameworks, bases de datos, servidores web y otras cuestiones y herramientas relacionadas con el entorno. ❞

— Robert C. Martin, Clean Architecture

En resumen, una buena arquitectura y su implementación deben hacer explícito el propósito del software y los conceptos que giran alrededor de él. Es ahí donde DDD nos da bases sólidas para construir soluciones centradas en el dominio.

Conclusiones

El software debe buscar siempre dar valor, es decir, debe tratar de que cada uno de los elementos implementados permita ejecutar acciones del negocio de la manera más eficiente y segura. Esto es fácil de tener en cuenta en proyectos pequeños, pero ya en sistemas complejos se vuelve un problema.

Muchas veces ese problema es que los elementos del negocio se pierden dentro del código, entonces es muy fácil que el desarrollador comente qué base de datos usa pero no dónde se aplica una validación importante. Ese es un gran problema, la construcción del software se guía a través de la tecnología a usar y no del problema a resolver.

A lo largo de esta serie hemos comentado cómo DDD nos permite afrontar esta situación a través de centrar nuestro diseño e implementación de software en el dominio, buscando para ello alinear el lenguaje y delimitarlos dentro de contextos.

Este trabajo da como resultado la implementación de sistemas que representan las necesidades de la organización. En pocas palabras “El negocio habla, y el código escucha”

Ahora la pregunta es para ustedes: ¿Cómo se ven sus sistemas? ¿Su código grita qué problema resuelve o representa más las tecnologías que usa?

Gracias por acompañarme en esta serie sobre DDD, espero que haya servido como puerta de entrada a este tema y despertado en ustedes curiosidad. Los invito a seguir aprendiendo y puliendo este arte que es el software.

Hasta la próxima.

Recursos

Martin, R. C. (2017). Clean architecture: A craftsman’s guide to software structure and design. Addison-Wesley Professional. https://learning.oreilly.com/library/view/clean-architecture-a/9780134494272/

Evans, E. (2003). Domain-driven design: Tackling complexity in the heart of software. Addison-Wesley Professional. https://learning.oreilly.com/library/view/domain-driven-design-tackling/0321125215/

Pluralsight. (s.f.). Clean architecture: Patterns, practices, and principles. Pluralsight. https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents

Pluralsight. (s.f.). Fundamentals of domain-driven design. Pluralsight. https://app.pluralsight.com/library/courses/fundamentals-domain-driven-design/table-of-contents

Del negocio al software: Construyendo un Bounded Context en DDD

Jean Karlo Obando Ramos — Tue, 02 Sep 2025 02:03:00 +0000

Originalmente publicado en: https://blog.jeankaobando.com/blog/2025/ddd-serie-part-3-modeling-bc/

Tabla de Contenidos

Introducción
Guíate en las acciones
Entidades, Value Objects e Invariants
Modelando nuestro Bounded Context
Conclusiones
Recursos

Introducción

El software se construye alrededor de un conjunto de términos, acciones y reglas definidos por el subdominio del negocio sobre el que opera. Es la correcta implementación de estos elementos los que da su valor. Sin embargo, muchas veces estos detalles se pierden en nuestra arquitectura debido a que se organizan con base a los elementos técnicos o simplemente no se organiza.

Este es el principal objetivo de Domain-Driven Design, que el modelo de nuestro sistema y su implementación esté guiada siempre por el negocio. De esta manera podemos poner nuestro esfuerzo y enfoque en los elementos que dan valor.

En los capítulos anteriores de esta serie comentamos acerca de la importancia del lenguaje y cómo es este el que nos permite poner límites claros a nuestros sistemas. Estos límites Eric Evans los define como Bounded Contexts.

Las preguntas que me hago para este capítulo son: ¿Cómo se modelan estos elementos del negocio en un Bounded Context? ¿Cómo guían la implementación de nuestros sistemas?

Guíate en las acciones

Retomemos el ejemplo visto en el capítulo anterior (link aquí) y trabajemos con el Bounded Context “Envíos” donde se definieron ciertas acciones:

Generar órdenes de envío
Asignar transportista
Despachar envío
Reprogramar entrega

Ahora nuestro trabajo es implementar una de estas acciones y en ese proceso conocer más acerca de nuestro subdominio.

Vamos a tomar “Generar órdenes de envío” como la primera acción de negocio a implementar. Simulemos una conversación con un PM con la ayuda de ChatGPT

## Ejemplo: Conversación con un PM para entender el proceso de "Generar una Orden de Envío"

**Dev:** ¿Qué significa exactamente “generar una orden de envío”?  
**PM:** Es crear la **instrucción formal** de que un pedido debe moverse del almacén al cliente.  
En nuestro lenguaje de negocio lo llamamos **Orden de envío**. Es el registro oficial que inicia el proceso logístico.

---

**Dev:** ¿La instrucción formal es lo mismo que una orden de envío?  
**PM:** Sí. “Instrucción formal” lo dije como explicación, pero el término correcto en nuestro *Lenguaje Ubicuo* es **Orden de envío**.

---

**Dev:** ¿Qué elementos tiene una Orden de envío?  
**PM:**  
- Tracking ID (identificador único)  
- Pedido asociado  
- Dirección de destino  
- Estado actual  
- Fecha de creación  
- (Opcional más adelante: transportista, condiciones especiales)

---

**Dev:** ¿Cuál sería la versión mínima para un MVP?  
**PM:**  
- Tracking ID único  
- Pedido asociado confirmado/pagado  
- Dirección de destino válida  
- Estado inicial = “Creada”  
- Fecha de creación

---

**Dev:** ¿Qué reglas se aplican al crear una Orden de envío?  
**PM:**  
1. El pedido debe estar confirmado/pagado.  
2. La dirección debe ser válida.  
3. El Tracking ID debe ser único.  
4. El estado inicial siempre es “Creada”.  
5. Se debe registrar la fecha de creación.

---

**Dev:** Entonces, para generar un envío necesito:  
- Confirmación de pago  
- Generar un ID único  
- Añadir dirección válida  
- Estado inicial “Creada”  
- Fecha de creación  

¿Me falta algo más?  

**PM:** Está perfecto. Lo único adicional que podrías incluir (si el negocio lo requiere) son **los datos de origen** del envío, pero con lo que tienes ya puedes empezar el proceso.

---

👀 TIP: Este tipo de conversaciones deben ser el día a día de nuestro trabajo, especialmente si somos líderes técnicos o arquitectos. Si no las tenemos es muy probable que construyamos software a ciegas.

La conversación con el PM nos da luces sobre cómo debemos implementar la acción “Generar orden de envío”. De ella podemos obtener la siguiente información:

El concepto sobre el cual gira la conversación parece ser la “Orden de Envío”
Una orden de envío maneja un proceso, por ello tiene estados
La dirección es otro elemento importante para generar órdenes de envío.
Estas acciones parecen ser desencadenadas por otro Bounded Context, dado que hay un elemento no ligado directamente a “Envíos” llamado “Pedido” y su valor influye en sí se ejecuta o no nuestra acción.

Estos hallazgos son la materia prima del modelo que construiremos.

Con estos elementos definidos es momento que el software comience a ser protagonista y ubiquemos estos elementos en un modelo que guíe la construcción de nuestro sistema.

Entidades, Value Objects e Invariants

Hasta este momento he hecho mucho énfasis acerca de entender los conceptos, definiciones y reglas que están alrededor de nuestro subdominio. En este momento vamos a entender el motivo.

Partiendo de nuestro ejemplo, “Envío” es uno de los elementos centrales del BC. Este elemento tiene algunas características:

Es un elemento identificable (tiene un ID)
Tiene un conjunto de propiedades que lo definen: estado del envío, dirección, fecha de creación.
Sobre este elemento se ejecutan acciones de negocio:
- Crear orden de envío
- Actualizar estado

Cuando un objeto tiene este conjunto de características DDD lo define como una Entidad.

💡 Entidad: Es un objeto que está definido principalmente por su identificador

Pero en nuestra conversación también salieron otros elementos como Dirección que presenta las siguientes características:

No tiene un identificador
Es inmutable (“Ejemplo: una Dirección siempre describe la misma calle y número aunque la consultemos varias veces”).
Describe “algo” dentro del sistema

Para DDD, cuando un elemento reúne este conjunto de cualidades lo denomina Value Object.

💡 Value Object: Describe las características de un objeto pero no posee un identificador.

Finalmente, en el proceso para crear una orden de envío se definen algunas reglas que se deben cumplir para ejecutar la acción, por ejemplo “el pedido debe estar confirmado o pagado para crear la orden”.

Cuando nos encontramos con condiciones y reglas cuya evaluación siempre debe ser verdadera DDD las denomina Invariants

💡 Invariant: Reglas que siempre deben ser verdaderas para que el sistema mantenga un estado consistente.

Eric Evans propone más elementos que iremos explorando con el tiempo, pero con estos tres ya tenemos suficiente para empezar.

Con todos estos conceptos claros ¿qué tal si modelamos nuestro BC Envíos?

Modelando nuestro Bounded Context

La comunidad de DDD es muy activa y existe en especial una, como el DDD-Crew, que provee un conjunto de recursos que nos ayudan a aterrizar estos conceptos en modelos gráficos. Te comparto el link para que los puedas explorar: https://github.com/ddd-crew/ddd-starter-modelling-process.

De este conjunto de elementos, en esta ocasión vamos a utilizar el relacionado con Bounded Context. DDD-Crew nos provee de una plantilla en donde podemos ubicar cada una de las ideas que discutimos en la sección anterior. La plantilla es la siguiente:

Como pueden ver en la imagen, en esta plantilla podemos formalizar el nombre de nuestro BC y su propósito. Categorizarlo como parte de un subdominio central, de soporte o genérico (ya veremos estas categorías a profundidad en un futuro post). Describir explícitamente las acciones de nuestro sistema, sus entidades y reglas. Finalmente, contamos con una sección para describir algún supuesto, métricas de cómo evaluar las acciones del BC y preguntas.

Para nuestro ejemplo el resultado sería el siguiente:

🗒️ Nota: Algunos términos se encuentran en inglés en el modelo debido a que estos se transformaran en el nombre de las clases, funciones y eventos que se implementarán en el código, que por estándar se escribe en este idioma.*

Cómo podemos ver, con este modelo tenemos una guía clara de qué hace nuestro BC Shipments por ahora, por ejemplo:

Su propósito es la administración del envío de artículos, entonces es evidente para nosotros que cualquier acción o concepto que no encaje en ese propósito debe ubicarse en otro lado (Ejemplo: el pago de las órdenes)
Se enfatiza en que “Envíos” es un subdominio de soporte para el dominio de E-commerce. Es decir, no es un factor diferenciador para nuestro negocio pero es necesario para que este opere.
Está explícita la relación con el Bounded Context “Orders” y que el desencadenante para iniciar nuestra acción será el evento “OrderPaid”.
Se definen las métricas de negocio sobre las cuales se van a evaluar las acciones ejecutadas en este sistema.

Un Bounded Context puede ser modelado de diferentes formas, pero esta herramienta de DDD-Crew en mi opinión permite servir como puente entre el negocio y desarrolladores dado que plantea un lenguaje común sobre el cual se van a dar las conversaciones sobre este subdominio.

Conclusiones

DDD nos invita a centrar nuestros esfuerzos en construir software guiado por el dominio. En un Bounded Context nosotros podemos describir formalmente ese conjunto de términos, reglas y acciones que guían al negocio en un modelo, convirtiéndose en una herramienta poderosa en pro de la construcción de soluciones que den valor a nuestra organización.

En el siguiente capítulo, el final de nuestra serie, vamos a implementar este BC en código y comprender cómo este proceso nos ha permitido que el negocio hable y que el código escuche.

Recursos

Pluralsight. (s. f.). Fundamentals of Domain-Driven Design. Pluralsight. https://app.pluralsight.com/library/courses/fundamentals-domain-driven-design/table-of-contents

DDD-Crew. (s. f.). Bounded context canvas. GitHub. https://github.com/ddd-crew/bounded-context-canvas

Bounded Contexts: Delimitando el lenguaje

Jean Karlo Obando Ramos — Sat, 30 Aug 2025 16:27:00 +0000

Originalmente publicado en: https://blog.jeankaobando.com/blog/2025/ddd-serie-part-2-bounded-context/

Tabla de Contenidos

Introducción
Reconocer nuestro subdominio
Bounded Context: delimitando el terreno
Mismos nombres, diferentes significados
Conclusión
Recursos

Introducción

En el día a día, los sistemas son complejos. Es muy difícil, por no decir imposible, que una persona o grupo de personas pueda conocer todos los detalles de cómo funciona el software de una empresa. La pregunta es: ¿eso importa?

Comenzamos esta serie haciendo énfasis en el lenguaje. Recalcamos que para construir soluciones centradas en el negocio y no en la tecnología era importante entender la razón de ser de nuestros sistemas. Pero me gustaría hacer un matiz: no es necesario que conozcamos el panorama completo a profundidad. Lo importante es identificar la parte del negocio en la que trabajamos, sus objetivos, términos, reglas y cómo se relaciona con otras partes del sistema.

Es por esa razón que terminamos el capítulo anterior hablando acerca de delimitar el lenguaje.

En esta ocasión vamos a centrarnos en eso. En identificar en qué parte del sistema estamos y cómo construir soluciones que funcionen en ese contexto.

Comencemos.

Reconocer nuestro subdominio

Pongamos atención a la siguiente imagen:

Vamos a imaginarnos que trabajamos en una empresa donde uno de sus anuncios es similar al de la imagen anterior. ¿Qué servicios estamos ofertando?

Compra por catálogo
Pagos con tarjeta de crédito y PayPal
Promociones y Descuentos
Entrega a domicilio
Seguimiento de envíos

En este ejemplo es muy fácil identificar el dominio de nuestro sistema, E-commerce. Pero si lo analizamos a detalle, estos servicios abarcan áreas diferentes de la empresa y cada uno de ellos maneja un lenguaje diferente. Por ejemplo, en “Catálogos” pueden hablar de búsquedas, filtros, productos destacados; en “Entregas” necesitan hablar de direcciones, puntos de entrega, estados del envío; mientras que “Pagos” define términos como transferencias, moneda, impuestos, método de pago. Cada uno de ellos corresponde a un subdominio dentro del dominio de E-commerce.

📖 Un subdominio es un área específica del dominio

Un subdominio se identifica por las conversaciones que existen alrededor de él y las expectativas que tiene la empresa sobre el grupo que trabaja en esta área. Por lo general, en esas conversaciones se definen acciones, reglas y términos que describen los problemas del día a día. Y es precisamente cuando agrupamos este conjunto de elementos del negocio que tenemos las herramientas para establecer esos límites en nuestros sistemas. Esto permite que nuestras soluciones estén enmarcadas dentro de contextos delimitados o Bounded Contexts.

Bounded Context: delimitando el terreno

Tomemos del ejemplo anterior los servicios seguimiento de envíos y entrega a domicilio, los vamos a encapsular dentro del subdominio “Envíos”.

Si nos centramos solo en este subdominio podemos identificar, de las conversaciones con los expertos del dominio (Product Owners, Gerentes, Consultores), ciertas acciones que se realizan en esta área:

Generar órdenes de envío
Asignar transportista
Despachar envío
Confirmar entrega
Reprogramar entrega

Además, si te fijas con atención también percibes que se definen algunas reglas sobre estas acciones, por ejemplo:

Un transportista no puede tener más de 10 órdenes de envío al día
Se requiere la firma del ordenante para confirmar la entrega
Solo se puede reprogramar una entrega 3 días antes de la fecha de entrega

Con estos elementos tú puedes comenzar a definir un conjunto de términos comunes que pueden alinear la comunicación y la aplicación de estas acciones con sus reglas en el sistema, por ejemplo:

Orden de envío: Instrucción formal para trasladar un pedido desde el almacén hasta la dirección del cliente.
Transportista: Persona o empresa responsable de trasladar el paquete (puede ser interno o un proveedor externo).
Guía / Tracking: Código único que identifica y permite rastrear un envío en todo su recorrido.

Estos elementos de negocio, que definen un área específica, son lo que en DDD se conocen como “Bounded Contexts”. Eric Evans lo define así:

📖 Un Bounded Context es una parte definida del software donde ciertos términos, definiciones y reglas se aplican de manera consistente

Sin embargo, es posible que los mismos términos se utilicen en diferentes Bounded Contexts con significados diferentes. Este es precisamente el desafío que Evans ilustra con la famosa parábola del elefante y los hombres ciegos, que veremos a continuación.

Mismos nombres, diferentes significados

En su libro Domain-Driven Design: Tackling Complexity in the Heart of Software, Eric Evans se apoya en la parábola del “Elefante y los hombres ciegos” para explicar que el dominio puede representar diferentes cosas dependiendo del subdominio en que el equipo esté interactuando.

Así como para el hombre que toca el colmillo el elefante es como una lanza, para quien está en las piernas es como un árbol; en nuestros sistemas también el entendimiento del negocio de quien trabaja en pagos va a ser completamente diferente a quien trabaja envíos.

En este proceso, es muy común, que se utilicen los mismos nombres para definir conceptos totalmente diferentes. Por ejemplo un “artículo” para Pagos tiene las propiedades de precio, marca, aplica descuento, pero para Envíos tiene las propiedades de peso, dimensiones, condición de embalaje.

Esto no es un problema como tal, de hecho es lo recomendable según Eric Evans, que cada término describa específicamente el problema que está resolviendo en su contexto.

Sin embargo, es importante tener clara esta situación. Especialmente, cuando tenemos que definir relaciones entre diferentes Bounded Contexts, para así evitar que la integridad de nuestro contexto se comprometa. Esto será tema de un próximo capítulo, pero por ahora es importante reconocer que van a existir este tipo de situaciones.

Conclusión

Toda solución de software se construye dentro de un contexto, definido por los elementos del negocio propios del subdominio en el que trabajamos.

Los Bounded Contexts nos permiten que ese conjunto de términos, reglas y acciones del negocio se encuentren bien definidas y sirvan como guía para el desarrollo de nuestras soluciones; permitiendo que los equipos se centren en resolver problemas que agregan valor a la empresa en lugar de distraerse con detalles tecnológicos secundarios.

En el siguiente capítulo veremos cómo se definen estos elementos de negocio en un Bounded Context y cómo esto se traduce a software. Nos vemos.

Recursos

Evans, E. (2004). Domain-driven design: Tackling complexity in the heart of software. Addison-Wesley Professional. https://learning.oreilly.com/library/view/domain-driven-design-tackling/0321125215/
Lerman, J., & Smith, S. (2014). Fundamentals of Domain-Driven Design. Pluralsight. https://app.pluralsight.com/library/courses/fundamentals-domain-driven-design/table-of-contents

El punto de partida de DDD: Hablar el idioma del negocio

Jean Karlo Obando Ramos — Thu, 21 Aug 2025 10:35:00 +0000

Originalmente publicado en: https://blog.jeankaobando.com/blog/2025/ddd-serie-part-1-language/

Tabla de Contenidos

Introducción
Entender qué hacemos
La importancia del lenguaje
Poniendo límites a nuestro lenguaje
Conclusión
Recursos

Introducción

Hace algunos meses me encontraba presentando una iniciativa a las diferentes áreas interesadas en esta: experiencia, negocio, seguridades, riesgos, canales de atención, legal. Para mí, esta funcionalidad no representaba un cambio significativo en la arquitectura del sistema, era una variante sobre un flujo ya existente.

Me sorprendió descubrir que solo para mí no era algo nuevo. Para las otras áreas, esto sí representaba una nueva funcionalidad que tenía sus propias reglas de negocio y restricciones.

Ante esto traté de explicar que: la arquitectura de máquina de estados implementada permitía guardar pasos sin alterar el estado de las bases de datos y que al final los registros tenían esquemas similares.

¿Pueden ustedes identificar mi error? Yo tampoco lo vi en su momento hasta que alguien del área legal me dijo ¿Qué es una máquina de estados?. En ese momento comprendí que la mayoría de términos que usé no los conocía gran parte de mi audiencia. Eso hacía que no estuviéramos alineados en lo que se iba a construir.

Reflexionando sobre este tema regresé a ver a mi arquitectura y me di cuenta que su estructura representaba claramente el patrón técnico que utilizábamos. Pero las reglas de negocio se diluían en el código y era difícil identificarlas. En pocas palabras, nuestro centro no era el negocio, era la tecnología.

Este fue mi punto de partida hacia Domain-Driven Design (DDD). En esta serie de blogs les compartiré mi aprendizaje sobre este tema y cómo puede aportar a construir soluciones centradas en el negocio, no en la tecnología.

Entender que hacemos

Como desarrolladores y líderes técnicos nuestra área de confort es la creación de software, somos buenos en ello. Pero por un momento nos hemos puesto a pensar en qué hacemos. No me refiero si habilitamos un servicio “REST” o estamos implementando un “Dead Letter Queue”. Lo que pregunto es ¿conocemos qué hace nuestro sistema? ¿por qué la empresa considera que es importante lo que estamos construyendo? ¿cuál es el giro de negocio? ¿cómo aportamos valor?

"El corazón del software es su capacidad para resolver problemas relacionados con el dominio de un usuario.”

— Eric Evans, Domain-Driven Design

Tener claro qué hace el negocio y cuál es su razón de ser nos permitirá construir software que aporte a ese objetivo y no piezas costosas de software que nadie las utiliza.

Una forma útil para identificar el “qué” de nuestros sistemas es a través de las conversaciones que se tienen con las diferentes áreas que interactúan con el sistema de forma directa o indirecta.

Te planteo este ejercicio. En tu siguiente conversación con algún área diferente a la de desarrollo busca identificar:

Qué acciones describen tu sistema (Ejemplo: Usuario agrega orden a carrito de compra, Cliente realiza una transferencia)
Dentro de esas acciones señala los términos comunes utilizados (Ejemplo: Carrito, Compra, Transacción, Transferencia)
Qué restricciones o reglas se comentan (límite de compra, máximo valor de transacción)

Esto te dará unas pistas no solo de qué hace tu sistema, sino lo que los otros piensan que hace tu sistema. Y lo más importante, reconocerás el siguiente desafío que necesitas afrontar.

Alinear el lenguaje.

La importancia del lenguaje

Si eres de Hispanoamérica te habrás percatado que una misma palabra puede significar cosas diferentes dependiendo de la región. Por ejemplo “guagua” en Ecuador significa bebé mientras que en países como Chile o Cuba significa autobús, no existe ninguna relación entre los dos significados.

Esto mismo ocurre con nuestros sistemas, por ello antes de lanzarnos a construir soluciones es importante alinearnos en el lenguaje. Y así evitar que terminemos en una torre de Babel donde cada quien entiende o infiere lo que quiere y el resultado final no representa a nadie.

Pongamos un ejemplo de un “lenguaje común” exitoso, HTML. Este lenguaje de marcado creado por Tim Berners Lee generó un esquema para presentar páginas en Internet. Su éxito es tal que no importa el país, las creencias, el nivel técnico, todos quienes interactuamos con la web sabemos que es un <h1> o <p>.

De este último párrafo me gustaría que nos quedemos con la frase “todos quienes interactuamos con”.

Un Lenguaje Universal no existe. Volviendo a mi ejemplo de HTML, tal vez un abogado no sabe qué es una marca <p> pero ¿eso importa?, no. Sin embargo, si el abogado desea implementar su página web y se aventura a hacerlo por sí solo deberá aprender el lenguaje de la web, en donde la marca <p> define un párrafo.

Eric Evans define a este conjunto de conceptos y términos que evolucionan juntos dentro de un contexto delimitado como Ubiquitous Language.

De la definición de Eric Evans me gustaría rescatar la última parte “contexto delimitado”. Que exista ambigüedad en lenguaje no es un problema como tal. De igual manera que podemos usar guagua mientras estemos en Ecuador para referirnos a un bebé. Es importante identificar el contexto sobre el cual se desenvuelve nuestro sistema y definir límites alrededor de él.

De esta manera nuestro lenguaje nos permitirá describir los problemas y acciones que son relevantes para nuestra área del negocio y sus interesados

Poniendo límites a nuestro lenguaje

Regresemos un momento al ejemplo de HTML, en una frase anterior comentaba que “todos quienes interactuamos con la web sabemos”

De esta expresión podemos conocer el contexto general en el cual nos estamos desenvolviendo, la web.

¿Quiénes podrán estar interesados en la web? La respuesta puede ser muy amplia. Eso no nos ayuda a construir un lenguaje común. Pero qué tal si replanteamos la pregunta en ¿Quiénes están interesados en cómo publicar información en internet a través de páginas?

En ese contexto vamos a encontrar acciones comunes:

Escribir un artículo
Dar formato al contenido
Insertar enlaces, multimedia o componentes interactivos
Configuración de SEO

También podemos definir nuestros actores:

Desarrolladores web
Autores
Diseñadores web
Especialistas en Marketing

Finalmente vamos a descubrir términos comunes como:

Página HTML
Hipervínculo
SEO
Estilo

En este contexto se puede explicar la razón de ciertas etiquetas de HTML:

<h1> y <p> nos ayudan a definir títulos y párrafos
<a> hace referencia a hipervínculos
<style> a la capacidad de añadir estilos a nuestras páginas

Dentro de un contexto general muy amplio (la web) hemos puesto límites basados en las acciones que queremos realizar en la web (publicar información), de esta manera ha sido más fácil identificar las capacidades de nuestro sistema y sus involucrados.

Eric Evans define al entorno en el cual se desarrollan nuestros sistemas como dominio , y las capacidades específicas en las que se divide como subdominios.

Este ejercicio lo podemos hacer nosotros con nuestros sistemas, por ejemplo. Si trabajamos para una empresa que vende artículos por internet podemos decir claramente que estamos en el dominio de “E-commerce”. Pero en qué área nos desenvolvemos: pagos, entregas, marketing, catálogo. Cuando tengamos esto identificado comenzaremos a ver que tenemos términos que son propios de nuestro subdominio como “transacción” para pagos o “alcance” para marketing. Incluso términos que se utilizan entre subdominios cómo “orden” que puede significar una cosa para un pago y otra para una entrega.

Conclusión

Construir sistemas es complejo y mucho más cuando existen una desconexión entre los participantes de un proyecto. Para nosotros, como personas de tecnología, esa desconexión es un riesgo. Significa construir sistemas centrados en las herramientas que usamos y no en los problemas del negocio que queremos resolver.

Para ello es importante detenerse un momento e identificar dónde estamos parados, cuál es el dominio de nuestro negocio y en cuál subdominio están mis soluciones. Para así trabajar en construir un lenguaje que permita al sistema representar el negocio y alinear a los interesados.

Aquí lo dejamos por ahora. En la siguiente parte explicaremos cómo estos límites se convierten en contextos claros que guían la arquitectura: los Bounded Contexts.

Recursos

Pluralsight. (s. f.). Clean Architecture: Patterns, Practices, and Principles. Recuperado de https://app.pluralsight.com/library/courses/clean-architecture-patterns-practices-principles/table-of-contents
Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software. Addison-Wesley Professional. Recuperado de https://learning.oreilly.com/library/view/domain-driven-design-tackling/0321125215/

Tres claves para que tu equipo cante fuerte, claro y en armonía

Jean Karlo Obando Ramos — Tue, 12 Aug 2025 01:24:53 +0000

En los últimos meses mi equipo y yo hemos enfrentado retos complejos, desafiantes. Hecho que provocó que las últimas semanas terminé un poco desgastado y sobre todo reflexivo. Una pregunta rondaba en mi cabeza a diario, ¿qué define a un gran equipo?

En esos momentos de reflexión recordé una anécdota de mis tiempos en el coro de la universidad, que días más tarde compartí con mi equipo y después de pensarlo me gustaría compartirla con ustedes.

Hace algunos años, el coro de mi universidad tuvo la oportunidad de participar en un festival de música coral en la ciudad de Tlaxcala, México. Todos estábamos muy ilusionados y para muchos de nosotros significaba la primera vez que una de nuestras pasiones nos permitía viajar a otro país.

La preparación no estuvo exenta de problemas, falta de compromiso y claridad en el objetivo del viaje pero la ilusión estaba ahí. Después de dos meses de ensayo estábamos listos para viajar.

Como todo festival, el nuestro comenzó con un concierto de apertura, al cual llegamos un poco tarde por un retraso en nuestro vuelo. Si bien el evento ya había comenzado, logramos estar presentes para nuestro número. La mezcla de ilusión y nervios estaban a flor de piel pero lo hicimos y salimos contentos. Después de ello nos dispusimos a escuchar al resto de grupos.

Fue una gran sorpresa descubrir que nuestro grupo era uno de los más numerosos, 25 personas aproximadamente. La mayoría de grupos no llegaba a la docena y hubo uno en especial que me sorprendió, eran apenas 8 personas: 2 sopranos, 2 contraltos, 2 tenores y 2 bajos (uno de ellos hacía beatbox).

El grupo era increíble, a pesar de ser un grupo pequeño se los escuchaba fuerte y claro. Cada canción la interpretaban con cierta delicadeza y belleza que no importaba lo que hiciesen todo sonaba bien y sobre todo el grupo se lo veía feliz de estar en tarima, lo que producía que el público disfrutara la presentación. Intrigado los seguí durante todo el festival y una sola pregunta rondaba en mi cabeza, la cual compartí con mi director.

¿Por qué si era un grupo tan pequeño sonaba tan bien y nosotros siendo más nos costaba que se nos escuche?

La respuesta de mi director me asombró y creo que responde a la pregunta inicial que planteé en este blog. ¿Qué define un gran equipo? He aquí la respuesta.

Lo primero, me dijo, es que todos, sin excepción, se saben la letra de sus canciones. El director ha delineado el repertorio que quería presentar en este festival y la primera tarea que han tenido es aprenderse la letra. Si alguien no se sabe la letra de las canciones es difícil avanzar dado a que no se pueden trabajar armonías, cambios de tiempo, matices, juegos de voces. Si el grupo no se sabe la letra de sus canciones se pierde claridad en los ensayos y seguridad en el escenario.

Lo segundo, es que cada quien ejecuta su rol en el equipo como el mejor. La soprano que tienen sabe que es la mejor soprano que puede ser, al igual que su tenor o su bajo. ¿Qué significa ser la mejor en su rol? Significa que trabaja todos los días puliendo su arte, sin criticar el trabajo de otros o menospreciándolo. El bajo sabe que es la base del coro, la contralto está clara que tal vez no se luzca como la soprano pero sin ella no se pueden armar armonías complejas. El tenor sabe que debe no exagerar en su volumen de voz dado que pueden en ello opacar ciertos matices y arreglos que ha puesto el director. Todos saben que son importantes y son los mejores en lo que hacen o al menos buscan serlo.

Finalmente, gracias a lo primero y lo segundo, ellos logran algo importante durante su ejecución. "La respiración intercalada". Ponte a pensar, me dijo, muchas canciones requieren notas largas o frases muy rápidas. En muchos coros, nosotros incluidos, se escucha la respiración y se identifica cuando alguien está sufriendo en esas notas. ¿Por qué en ellos no? La respuesta es simple, si todos se saben la letra y son los mejores en lo que hacen, se pueden permitir que alguien tome pequeñas pausas dado que saben que el grupo los respalda. De esta manera no importa si están en una misma nota 5 minutos, si todos se apoyan para darse tiempo para respirar unos segundos, eso no se notará y el coro siempre sonará sólido.

Si lo piensan bien, eso mismo ocurre con los equipos. Un gran equipo, uno que canta fuerte, seguro y muy hermoso es aquel en donde:

El equipo se sabe la letra de sus canciones.- es decir que conoce y se interesa por el contexto de su trabajo, el "por qué" se hacen las cosas, sus objetivos, sus procesos. En el caso de los desarrolladores eso significa también conocer el código.
Cada miembro del equipo es el mejor en lo que hace.- en un equipo no se requiere de estrellas, se requiere que el equipo brille. Eso significa que cada uno de los integrantes sea el mejor en lo que hace o que busque serlo. Si es un QA, es la persona más apasionada en la búsqueda de la calidad de las funcionalidades y del sistema como tal. Si es UX designer, es el más apasionado en crear experiencias sencillas y de valor en las personas. Todo ello mientras respetan y valoran el trabajo de los demás. De nada sirve un equipo donde solo brille uno, una armonía requiere de muchas voces diversas.
El mejor equipo es el que se permite respirar de manera intercalada.- al final es importante reconocer que somos humanos, que no siempre nos vamos a saber las letras de las canciones o estamos con energía para ser los mejores en lo que hacemos. Pero si estamos como grupo en búsqueda de ese objetivo, eso nos permite darnos espacio para apoyar al que se siente mal, al que está cerca de entrar en burnout, al que una situación familiar lo ha desenfocado. Los proyectos son complejos, como dar notas muy largas, entonces en ese proceso tenemos que darnos respiros los unos a los otros para seguir avanzando.

Son estos tres puntos los que para mí definen a un gran equipo. Uno en el que todos buscan entender lo que hacen y sobre todo el por qué lo hacen, son los mejores en su rol o buscan serlo. Y lo más importante se permiten respirar cuando alguien del equipo no se siente bien o necesita un espacio.

Esto no significa que el equipo será infalible, incluso el coro que les conté tuvo canciones que no estuvieron al 100, pero su ejecución en general era excelente, lo mismo pasa con los equipos, pero eso no nos impide trabajar por que nuestros grupos de trabajo suenen fuerte, claro y sobre todo hermoso.

El progreso - Coro ESPE. Festival Tlaxcala Canta 2016

Educational Frontmap: La clave para un aprendizaje organizado y efectivo

Jean Karlo Obando Ramos — Thu, 30 Jan 2025 02:49:00 +0000

Originalmente publicado en: https://blog.jeankaobando.com/blog/2025/educational-frontmap/

Tabla de Contenidos

Introducción
¿Qué es un Educational Frontmap?
¿Cómo construir un Educational Frontmap?
Beneficios
Conclusión
Recursos

Introducción:

El entorno actual nos desafía a mantenernos en constante aprendizaje. Cada día aparecen nuevas tecnologías, técnicas o herramientas que nos permiten ser mejores en lo que hacemos y en el proceso disfrutarlo más. Para ello podemos apoyarnos de un sin fin de recursos como: videos de YouTube, libros, cursos, charlas, artículos, entre otros.

Sin embargo, en este afán de aprender nuevas cosas podemos perder el rumbo y sentirnos abrumados por la cantidad de información que existe. Lo que puede ocasionar que nos frustre no avanzar o sea complejo reconocer cada paso que damos en la construcción de nuestra carrera.

Para ello me gustaría presentarles la siguiente herramienta:

¿Qué es un Educational Frontmap?

Un "educational frontmap" es un tablero que nos permite organizar y categorizar todos los recursos que hemos utilizado o tenemos interés de explorar. El tablero está dividio por categorìas y en cada una de estas podemos encontrar cursos, blogs, libros, artículos, videos o personalidades que han contribuido a nuestra formación en relación a un tema

De esta manera podemos contar con un lugar donde se encuentran todos los elementos que han contribuido a nuestra formación y son un espacio para consultas posteriores.

Esta herramienta la encontré hace algunos años leyendo un blog, decidí explorarla e incorporarla en mi vida y me ha dado grandes resultados.

Permíteme explicarte cómo construirlo.

¿Cómo construir un Educational Frontmap?

Como mencioné anteriormente, un "educational frontmap" es un tablero para mapear recursos de aprendizaje. Para ello puedes utilizar herramientas que permitan hacer tablas como: Excel, Notion o Trello.

En cada columna ingresa las áreas de interés que estén relacionadas con tu carrera, en mi caso tengo las siguientes:

Programming
Software Engineering and Architecture
AWS
Frontend
Backend
Javascript / Typescript
Cloud / DevOps
Artificial Intelligence
Others

Como pueden ver las secciones pueden ser muy específicas o generales dependiendo del nivel de profundidad que le quieran dar a cada una de las áreas.

Ahora, para mí también es importante incorporar otras categorías que complementan la formación técnica de un profesional:

Soft skills.- recursos relacionados con el desarrollo de habilidades no técnicas.
Pet Projects.- links a proyectos personales
Inspiration.- personalidades de la industria que tienen una opinión importante
Research.- investigaciones formales
Conferences.- ponencias o conferencias en las que se participa como ponente
Formal Education.- educación formal como pregrados o postgrados.
Blog Posts.- artículos o blogs de nuestra autoría

Todos estos elementos complementan la formación de un profesional y permiten desarrollar esos elementos diferenciadores dentro de la industria.

Para cada área, agrega los siguientes datos para cada recurso:

Nombre del recurso (ejemplo: "React Handbook")
Tipo de recurso (curso, blog, libro, etc.)
Enlace o ubicación
Estado (por ejemplo, "en progreso", "pendiente" o "completado")
Notas personales

Puedes ampliar esta estructura según tus necesidades y personalizarla de acuerdo a tus objetivos de aprendizaje.

Beneficios

El organizar tus recursos en un Educational Frontmap puede impactar de gran manera en la construcción de tu carrera dado a que te permite centralizar en un lugar todos los recursos que has utilizado y bien organizado peude permitirte:

Tener un acceso rápido a funtes de consulta por área de interes.
Adjuntar elementos adicionales que complemtan el recurso utilizado. Por ejemplo puedes añadir tus notas de clase a un curso que hayas tomado.
Usando filtros pueden permitirte ver que áreas necesitas trabajar más, comenzar a explorar o simplemente dejar de lado.
Es una buena carta de presentación cómo profesionales.

Conclusión:

Un "Educational Frontmap" puede ayudarte a organizar tus objetivos de aprendizaje, mantenerte motivado y facilitar el acceso a los recursos que necesitas. Dedica tiempo a construirlo y personalizarlo para que se convierta en una herramienta clave en tu desarrollo profesional.

Empieza hoy mismo y déjame saber en los comentarios cómo lo has organizado.

Recursos:

Trello

Throughput vs IOPS: Su impacto clave en la selección de almacenamiento en AWS

Jean Karlo Obando Ramos — Wed, 22 Jan 2025 04:45:08 +0000

Originalmente publicado en: https://blog.jeankaobando.com/blog/2025/throughput-vs-iops/

Tabla de Contenidos

Introducción
Qué es Throughput?
Qué es IOPS?
Cómo se relacionan Throughput y el IOPS?
Cómo escoger mi servicio AWS de storage en base a estas métricas?
Conclusión
Recursos

Introducción

Uno de los principales retos que enfrentamos al momento de diseñar soluciones Cloud es seleccionar las herramientas adecuadas para cumplir con nuestro objetivo de manera óptima y eficiente en base a los requerimientos del negocio.

En este blog me gustaría que nos centremos en comprender los conceptos de Throughput y IOPS. Métricas que nos pueden ayudar a seleccionar qué opción de almacenamiento es la más conveniente para nuestro caso.

Comencemos:

Qué es Throughput?

Imaginemos que somos los encargados de un servicio de streaming de video, como Netflix o YouTube. Cada vez que un usuario reproduce un video, el sistema debe transferir datos constantemente desde el servidor al dispositivo del usuario. Ahora, si millones de usuarios están viendo contenido en alta definición (HD o 4K) al mismo tiempo, la cantidad de datos que debe transferirse es inmensa. Si la capacidad de la red o los servidores no es suficiente para manejar este flujo constante de datos, los usuarios experimentarán interrupciones o tiempos de carga prolongados. Este desafío para transferir grandes volúmenes de datos de manera continua es un problema de Throughput.

Throughput se refiere a la cantidad de datos que pueden transferirse en un sistema por unidad de tiempo. Generalmente se mide en megabytes por segundo (MB/s) o gigabytes por segundo (GB/s). Es una métrica clave para evaluar el rendimiento de sistemas que manejan flujos continuos y grandes volúmenes de información.

Qué es IOPS?

Pensemos en un sistema de mensajería instantánea como WhatsApp o Slack. Cada mensaje que se envía o recibe puede implicar múltiples operaciones pequeñas por segundo. Estas operaciones incluyen almacenar el mensaje en una base de datos, actualizar el estado de lectura y enviar notificaciones a los dispositivos involucrados. Si el sistema no está diseñado para manejar este tipo de carga, podrían ocurrir retrasos en la entrega de mensajes, especialmente cuando millones de usuarios están activos simultáneamente. Esto simboliza un problema de IOPS (Input/Output Per Second).

IOPS se refiere a la cantidad de operaciones de entrada y salida que un sistema puede realizar en un segundo. Estas operaciones pueden incluir lecturas, escrituras o una combinación de ambas. Se mide en operaciones por segundo y es una métrica clave para evaluar el rendimiento de sistemas donde se ejecutan múltiples transacciones rápidas y frecuentes, como bases de datos o sistemas de mensajería.

Cómo se relacionan Throughput y el IOPS?

Estas dos métricas no son opuestas, más bien nos ayudan a evaluar el rendimiento de nuestros sistemas desde diferentes aristas. Throughput nos indica la velocidad general a la que los sistemas pueden mover datos. Mientras que IOPS refleja el rendimiento de un sistema con múltiples operaciones rápidas y frecuentes.

Veamoslo con mayor claridad en la siguiente tabla:

Aspecto	Throughput	IOPS
Qué mide	Cantidad de datos transferidos por unidad de tiempo	Número de operaciones de entrada/salida por segundo
Unidad	Megabytes por segundo (MB/s) o Gigabytes por segundo (GB/s)	Operaciones por segundo (número entero)
Importancia	Crucial para flujos de datos continuos y grandes volúmenes de información	Fundamental en sistemas transaccionales donde se requieren rápidas operaciones de I/O

Cómo escoger mi servicio AWS de storage en base a estas métricas?

AWS provee diferentes servicios de almacenamiento y memoria, el seleccionar uno de ellos va a depender mucho de la necesidad de nuestro caso de uso y los requerimientos que tengamos que cumplir. Es por ello analizar las métricas Throughput y el IOPS puede contribuir a que tomemos una mejor decisión.

La siguiente tabla muestra un resumen de qué servicio está más optimizado para una métrica o la otra.

Servicio de Almacenamiento	Descripción	Casos de Uso	Optimizado para
Amazon S3	Almacenamiento de objetos escalable y duradero.	Respaldo masivo de datos, análisis de Big Data, almacenamiento de contenido multimedia.	Throughput
Amazon EFS	Sistema de archivos compartido para instancias EC2.	Compartición de archivos entre instancias EC2 en aplicaciones distribuidas o sistemas analíticos.	Throughput
Amazon EBS	Almacenamiento en bloque para instancias EC2.	Bases de datos transaccionales, aplicaciones críticas con alta concurrencia.	IOPS
Amazon FSx for Lustre	Diseñado para cargas de trabajo intensivas en datos como análisis y procesamiento de big data.	Análisis de datos científicos, simulaciones, y cargas de trabajo de machine learning.	Throughput
Amazon FSx for Windows	Sistema de archivos optimizado para aplicaciones empresariales y bases de datos en entornos Windows.	Aplicaciones empresariales en Windows, entornos de directorio activo, y bases de datos SQL Server.	IOPS

Conclusión

Comprender los requerimientos de nuestros sistemas es importante al momento de seleccionar nuestras soluciones de almacenamiento. El comprender si nuestro sistema requiere mover grandes cantidades de datos (Throughput) o realizar una gran cantidad de operaciones pequeñas por segundo (IOPS) nos permite identificar la métrica correcta para nuestro estudio y la solución de AWS que más se acople a nuestras necesidades.

Recursos

El verdadero valor del software no siempre está en el presente

Jean Karlo Obando Ramos — Fri, 08 Nov 2024 03:18:00 +0000

Originalmente publicado en: https://blog.jeankaobando.com/blog/2024/software-to-the-future/

Tabla de Contenidos

Introducción
El verdadero valor y costo del software
Estructura vs Comportamiento
¿Cuándo? y ¿Dónde?
Conclusión
Recursos

Introducción

En el post anterior (link si no lo has revisado) discutimos el uso de "Tidyings", pequeñas acciones que mantienen una estructura limpia y, sobre todo, comprensible de nuestro código. Sin embargo, quedó pendiente abordar cuándo y dónde aplicar estos cambios. Si bien el cliente principal de nuestro código es otro programador, el cliente final sigue siendo el usuario, a quien no le importa si nos demoramos tres semanas arreglando nuestro código; lo que quiere es ver que la aplicación funcione y que se desarrollen nuevas funcionalidades.

Por ello, en esta ocasión vamos a entender cómo aplicar "Tidyings" y reforzar su importancia. Pero primero, profundicemos en el valor y el costo del software.

El verdadero valor y costo del software

Imaginemos que vamos a un restaurante especializado en pizza artesanal. Hemos estado allí tres veces y el sabor es excelente, especialmente la pizza de la casa. Esta vez, decidimos llevar a nuestra cita para impresionarla, y nuestras expectativas son altas.

Por otro lado, el restaurante, con solo tres meses de operación, enfrenta dificultades. No han logrado medir su éxito y su cocina es demasiado pequeña para satisfacer la demanda diaria. Además, solo tienen ingredientes para sus tres tipos de pizzas más populares. La organización del espacio de trabajo es caótica; al principio, con solo dos cocineros, era fácil encontrar las cosas, pero ahora, para los dos nuevos ayudantes, es una verdadera pesadilla. En ese ambiente, todos corren y el descontento es evidente.

Al llegar al restaurante y preguntar por nuestra reservación, nos sorprenden diciendo que el lugar está lleno y que han dado nuestra mesa a otra pareja, pidiéndonos esperar 15 minutos. Molestos, reclamamos y nos asignan un lugar incómodo cerca de la cocina, pero nos decimos: "Tranquilo, la comida es buena, saldremos de esta". Llamamos al mesero para ordenar lo de siempre, pero a nuestra acompañante le llama la atención una pizza de frutas y la pide. Intuimos que algo va mal porque el mesero toma la orden con preocupación.

Finalmente, nuestra orden llega en 5 minutos, pero la de nuestra cita tarda una hora; cada vez que preguntamos, nos aseguran que ya va a salir. Durante ese tiempo, escuchamos platos quebrándose en la cocina y discusiones generalizadas. El servicio fue pésimo y ni siquiera la pizza de la casa estuvo buena.

Al salir, decidimos reclamar; quedamos mal con nuestra cita y el restaurante arruinó la noche. Nos explican que han tenido problemas para crecer, que la pizza de frutas no es muy solicitada y tuvieron que buscar los ingredientes. Además, su sistema de reservas se había caído una hora antes. Deciden no cobrarnos, pero eso no cambia el hecho de que no volveremos.

Analizando esta historia, podemos destacar dos puntos clave:

El restaurante comenzó bien, con recetas exitosas. Sin embargo, no se enfocaron en un crecimiento ordenado. Aumentaron las ventas, pero su sistema ya no podía soportarlo.
Aunque entendimos sus problemas y sentimos empatía, eso no era nuestra preocupación; queríamos disfrutar de una noche agradable y la arruinaron. Como resultado, perdieron no solo el ingreso de ese día, sino también un cliente.

Esto es precisamente lo que ocurre al crear software. Las empresas y sus desarrolladores se concentran tanto en lanzar funcionalidades rápidamente que descuidan la deuda técnica y las áreas de mejora. El proyecto funciona bien cuando es pequeño, pero cuando crece el código se vuelve un caos, lo que dificulta y hace riesgosa la implementación de cambios. El ambiente se vuelve hostil: el desarrollador está estresado porque teme dañar algo al hacer cambios, los dueños se frustran porque las tareas que antes eran rápidas ahora toman más tiempo, y los usuarios abandonan la aplicación, no sin antes quejarse de que las primeras versiones eran buenas pero ahora nada funciona.

El software crea valor de dos formas:

Haciendo cosas hoy

En la posibilidad de hacer nuevas cosas mañana.

Kent Beck

Kent Beck enfatiza precisamente esto: el valor del software no radica simplemente en su capacidad actual, sino en su flexibilidad para adaptarse y enfrentar cambios futuros.

Por eso, la legibilidad y mantenibilidad de nuestro código son fundamentales para el crecimiento exitoso de nuestro sistema. Como mencionamos antes: el verdadero costo del software no está en escribirlo, sino en leerlo y entenderlo.

El libro propone la siguiente relación:

\cong cost(cambio)

Sin embargo, los cambios más costosos son aquellos que requieren más tiempo de implementación. Por lo tanto, la relación más precisa es:

\cong cost(grandes cambios)

Los grandes cambios están estrechamente relacionados con el nivel de acoplamiento del código. Cuantos más elementos se interrelacionen entre sí, más complejo será realizar cambios sin afectar otras partes. Esto lleva a la siguiente relación:

\cong cost(coupling)

Si el costo del software es aproximadamente igual al costo de hacer grandes cambios, y este a su vez es aproximadamente igual al nivel de acoplamiento de nuestra aplicación, entonces podemos concluir que el costo del software es aproximadamente igual al nivel de acoplamiento del sistema.

\cong cost(coupling)

Esta relación se conoce en el libro como la Equivalencia de Constantine.

El tema del acoplamiento es extenso y merecería otro post, pero por ahora es crucial entender que nuestro enfoque no debe limitarse a desarrollar funcionalidades, sino también a mantener nuestro espacio de trabajo preparado para los cambios. Veamos cómo hacerlo a continuación.

Estructura vs Comportamiento

Como hemos mencionado, el valor del software se define por su capacidad de hacer cosas hoy y estar listo para hacer cosas mañana. En otras palabras, el tipo de código que escribimos afectará cómo funciona o cómo se ve. Por eso, es común ver pull requests con un historial de commits como este:

a1b2c3d refactor: isolate wishlist query function
i7j8k9l feat: add API routes for wishlist management
e4f5g6h refactor: create helper function to parse wishlist user's names
m0n1o2p feat: add initial wishlist backend structure

En este ejemplo, observamos dos tipos de cambios: de comportamiento y de estructura. Veamos sus definiciones:

Los cambios de comportamiento son aquellos que añaden, modifican o eliminan funcionalidad en nuestro código. Afectan cómo el usuario final interactúa con la aplicación y, por ende, son difíciles de revertir. Por ejemplo, si has dado a un usuario la opción de buscar por tipos, no querrás quitársela solo porque descubriste un error.
Los cambios de estructura buscan mejorar la legibilidad o mantenibilidad del código. Estos cambios deben garantizar que el sistema funcione igual que antes y que sean fácilmente reversibles en caso de error. Por ejemplo, si se extrae una sección de una función como función auxiliar, no debería ser complicado volver a integrar ese código en su lugar original si fuera necesario.

Esta distinción nos muestra que cada tipo de cambio requiere su propio enfoque. En los cambios de comportamiento, nos centramos principalmente en implementar lógica de negocio que debe probarse en diversos escenarios. En los cambios de estructura, el objetivo es mejorar la organización del código, ya sea aplicando "Tidyings" o realizando refactorizaciones más amplias.

Por eso, el libro recomienda abordar estos dos tipos de cambios por separado, siempre que sea posible.

¿Cuándo? y ¿Dónde?

Una vez que entendemos que es preferible manejar los cambios de estructura de manera independiente, surge la pregunta de cuándo y dónde aplicarlos.

El libro "Tidy First?" propone cuatro momentos: Nunca, en otro momento, después de, y antes de.

Nunca: Es probable que en nuestros proyectos existan secciones que varían poco con el tiempo, como configuraciones, conexiones a bases de datos o implementaciones de reglas de negocio fijas. En estos casos, refactorizar no genera valor futuro y ese tiempo puede invertirse en áreas más críticas.
En otro momento: Si al realizar un cambio identificas que mejorar cierta sección no aporta un beneficio inmediato, siendo más un "sería bueno tenerlo", entonces incluye ese arreglo en tu lista de tareas pendientes. Si eres líder técnico, busca siempre espacios en el sprint para ir saldando esa deuda técnica.
Después de: Si durante una tarea o implementación de funcionalidad identificas una función que "debe" ser mejorada, pero no es el momento adecuado porque podría retrasar el desarrollo, anota esa tarea y comprométete a abordarla inmediatamente después de terminar la tarea actual.
Antes de: Si aplicar un "Tidying" facilitará la implementación de una tarea y garantizará una entrega más robusta o por otro lado no nos quita mucho tiempo a nuestra tarea principal, adelante, no lo pospongas.

Identificar el momento adecuado requiere experiencia, pero la idea es siempre tener presente que debemos "mantener nuestra cocina limpia". Ya sea que apliques los cambios en grupo, después de una tarea o antes de ella, recuerda su importancia y no relegues estos cambios al final del backlog.

Otra pista útil al tomar decisiones es considerar que al código también se le aplica la "Ley de Pareto": el 80% de los cambios se concentra en el 20% del código. Es crucial identificar en nuestros proyectos cuáles son los archivos y funciones más frecuentemente modificados, para mantenerlos organizados y preparados para futuros cambios.

Conclusión

El valor del software y de nuestros sistemas no reside solo en las características que ofrecemos a nuestros clientes, sino en su capacidad para incorporar nuevas funcionalidades en el futuro. Esta capacidad de preparación para el futuro depende de la facilidad con que podamos buscar, modificar o añadir código en nuestros proyectos.

Para lograrlo, es fundamental diferenciar entre los cambios de comportamiento y los cambios estructurales, e identificar el momento oportuno para aplicar cada tipo de cambio.

Finalmente, es crucial mantener siempre presente la pregunta: "¿Cómo puedo mejorar mi código?" y no permitir que la deuda técnica se acumule en nuestro backlog.

Un tema que nos ha quedado pendiente discutir es “coupling”, déjame saber si te gustaría tener un post dedicado solo a este tema.

Recursos:

Tidy First, Kent Beck: https://learning.oreilly.com/library/view/tidy-first/9781098151232/

SE Radio 615: Kent Beck on “Tidy First”: https://open.spotify.com/episode/6XHBSDSSuH0xBDz1LeiAUE?si=44cab186651b486d

De lo funcional hasta lo legible con Tidyings

Jean Karlo Obando Ramos — Wed, 23 Oct 2024 02:46:00 +0000

Originalmente publicado en: https://blog.jeankaobando.com/blog/2024/from-functional-to-readable/

Tabla de Contenidos

Introducción
Un poco de Tydings
¿Quién es el principal cliente del código?
Conclusión
Recursos

Introducción

El trabajo del desarrollador se ve muchas veces reducido a la construcción de nuevas funcionalidades o la solución de bugs. De hecho, esto se ve reflejado en la forma que estas tareas se encuentran estructuradas dentro de la planificación. Al final o se va a implementar algo o se va a arreglar algo.

Está simplificación tiende a que muchas veces nos enfoquemos solo en la resolución de problemas a través de un ordenador y nos olvidemos de las estructura de esas órdenes.

En ese contexto fue una grata sorpresa para mi encontrar el libro “Tidy First?” de Kent Beck, el cuál recomiendo 100%. En este se hace énfasis en una de las preguntas que cómo desarrollador nos hacemos todos los días ¿Debo arreglar este código de mie*** primero?.

Un poco de Tydings

Una de las formas más fáciles que tuvo Robert C. Martín para definir que es un buen código fue en términos de cuantos dolores de cabeza y maldiciones produce el revisarlo. Si son muchos WTF definitivamente no es un buen código. Y es que ya lo diría Martin Fowler “Cualquier tonto puede escribir código que una computadora pueda entender. Los buenos programadores escriben código que los humanos puedan entender”.

El tema de “Clean Code” es muy amplio y existe basta literatura relacionada con el tema, pero Kent Beck se enfoca en su libro en un grupo de pequeñas acciones que pueden mejorar la legibilidad y la estructura del código a las que llama “Tydings”. Revisemos mejor con un ejemplo.

Digamos que estamos trabajando en una nueva funcionalidad y nos encontramos con la siguiente linea de código.

const función = () => {
    /// .... código
    const result = (typeof input === 'string' ? input.trim() : (typeof input === 'number' ? (input > 0 ? 'positive' : 'negative') : 'invalid')) || 'default';
    /// ... más código
}

Nuestra primera reacción es obviamente WTF? Es dificil de entender y tenemos poco tiempo para terminar la tarea, así que después de leerla un momento y consultar a otro compañero que hace esta línea, nos enteramos que es el resultado de una libreria para detectar el estatus de una cuenta. Este valor puede ser “positive”, “negative” o “invalid”, pero a veces suele devolver el resultado en números. Cuando el resultado sea “undefined” debemos devolver cómo “default”.

Lo se el código es un asco, pero es la respuesta de un tercero y no tenemos control ahí. Además no es parte de nuestra tarea principal arreglarlo y tenemos poco tiempo. ¿Qué podemos hacer?

Lo mas rápido y uno de los “tidyings” que nos recomienda Kent Beck es dejar un comentario.

const funciónFn = () => {
    /// .... código

    /*
     ** Transformación de resultado de libreria para calcular estado de la ganancia de una cuenta en positivo y negativo.
     ** El resultado puede ser devuelto cómo string, en números o "undefinded"
     */
    const result = (typeof input === 'string' ? input.trim() : (typeof input === 'number' ? (input > 0 ? 'positive' : 'negative') : 'invalid')) || 'default';
    /// ... más código
}

Ok, tal vez no solucione todos los problemas del mundo pero hemos evitado al menos un dolor de cabeza a la siguiente persona que se topen con esta línea de código, quizá a nosotros mismo. Lo interesante de aplicar “tydings” es que un siguiente desarrollador que se tope con esto puede hacer lo siguiente.

const funciónFn = () => {
    /// .... código

    const accountStatus = transformAccountStatus(input);
    /// ... más código
}

/*
** Transformación de resultado de libreria para calcular estado de la ganancia de una cuenta en positivo y negativo.
** El resultado puede ser devuelto cómo string, en números o "undefinded"
*/
const transformAccountStatus = (noParsedAccountStatus: any)  => {
   return (
      typeof noParsedAccountStatus === 'string' 
        ? noParsedAccountStatus.trim() 
        : typeof noParsedAccountStatus === 'number' 
          ? noParsedAccountStatus > 0 ? 'positive' : 'negative'
          : 'invalid'
      ) || 'default';
}

La persona que ha hecho este cambio para mi ya es un héroe. La solución es perfecta, NO. Pero ha aplicado dos “tydings” que vuelven más claro el panorama. El primero extraer la función en un helper, lo que logra que la complejidad de esta línea sea encapsulada en una función y que tenga ya un significado cómo tal para la función padre. La segunda es aplicar simetrías, si bien seguimos teniendo todo en una sentencia, ahora se distribuyen en algunas líneas de código, lo que produce que podamos leerlo mejor.

Digamos que unos días después alguien dice me parece que estamos haciendo muchas cosas en la misma linea de código: validamos tipos, hacemos transformaciones ademas de manejar diferentes tipos de inputs; entonces decide hacer lo siguiente.

const funciónFn = () => {
    /// .... código
    const accountStatus = transformAccountStatus(input);
    /// ... más código
}

/*
** Transformación de resultado de libreria para calcular estado de la ganancia de una cuenta en positivo y negativo.
** El resultado puede ser devuelto cómo string, en números o "undefinded"
*/
const transformAccountStatus = (noParsedAccountStatus: any)  => {
    if (noParsedAccountStatus === undefined) return 'invalid';

    if (typeof noParsedAccountStatus === 'string') {
      return noParsedAccountStatus.trim() || 'default';
    }

    if (typeof noParsedAccountStatus === 'number') {
        return noParsedAccountStatus > 0 ? 'positive' : 'negative';
    }

    return 'invalid'
}

Aquí el desarrollador decide aplicar otro “tyding”, aplicar “guardias”. Eso significa primero validar que los elementos que entran a la función sean válidos antes de ejecutar la lógica de la función.

Después de realizar este primer arreglo se da cuenta de algunas cosas:

Undefined no es el único valor no definido que puede entrar a la función.
El valor ‘default’ solo aplica cuando el valor es un string.

Entonces procede a hacer un cambio más.

const funciónFn = () => {
    /// .... código
    const accountStatus = transformAccountStatus(input);
    /// ... más código
}

/*
** Transformación de resultado de libreria para calcular estado de la ganancia de una cuenta en positivo y negativo.
** El resultado de la libreria puede ser cualquiere valor
*/
const transformAccountStatus = (noParsedAccountStatus: any)  => {
    if (!isNumber(noParsedAccountStatus) || !isString(noParsedAccountStatus))) {
        return 'invalid';
    }

    if (isString(noParsedAccountStatus)) {
      return noParsedAccountStatus.trim() || 'default';
    } else {
        return noParsedAccountStatus > 0 ? 'positive' : 'negative';
    }
}

const isNumber = (input) => typeof input === 'number';
const isString = (input) => typeof input === 'string';

Genial, hemos encontrado a otro héroe. Este desarrollador primero se ha percatado que el comentario inicial estaba incorrecto, el resultado de la librería puede retornar más que números o strings. Hecho que no se había comentado al inicio, por ello corrige el comentario, aplica la creación de helpers y genera variables con mejor nombre y significado.

El código para mi está bien, sin embargo, podemos hacerle un pequeño “tyding” más. Sucede que alguien decide ir a ver la librería y ahora ellos han definido una interfaz para el string, garantizando que solo devuelva valores cómo “positive” o “negative”. Y esto le da la idea de que tal vez el default ya no sea necesario y que tal vez nuestra función necesite una interfaz. Manos a la obra.


//main.ts
import { transformAccountStatus } from './account.ts'

const funciónFn = () => {
    /// .... código
    const accountStatus = transformAccountStatus(input);
    /// ... más código
}

// account.ts
import { isNumber, isString } from './utils.ts'

type AccountStatusType = 'positive' | 'negative' | 'invalid';

export const transformAccountStatus = (noParsedAccountStatus: any): AccountStatusType => {
    if (!isNumber(noParsedAccountStatus) || !isString(noParsedAccountStatus)) {
        return 'invalid';
    }
    return isString(noParsedAccountStatus)
        ? noParsedAccountStatus
        : transformNumberAccountStatus(noParsedAccountStatus);
}

const transformNumberAccountStatus: 'positive' | 'negative' = 
    (input) => noParsedAccountStatus > 0 ? 'positive' : 'negative';

// utils.ts
const isNumber: boolean = (input) => typeof input === 'number';
const isString: boolean = (input) => typeof input === 'string';

Finalmente hemos decidido aplicar un poco de orden de cohesión. Las cosas que se relaciona van juntas y en su propio archivo. Además usando Typescript hemos definido una interfaz, lo que previene errores para futuro y obliga a que el resultado cumpla siempre con esos definición. Finalmente hemos eliminado el comentario, el código se explica ahora por si mismo.

Si volvemos a la sentencia inicial vemos que mantenemos una línea de código:

Antes:

const funciónFn = () => {
    /// .... código
    const result = (typeof input === 'string' ? input.trim() : (typeof input === 'number' ? (input > 0 ? 'positive' : 'negative') : 'invalid')) || 'default';
    /// ... más código
}

Ahora:

const funciónFn = () => {
    /// .... código
    const accountStatus = transformAccountStatus(input);
    /// ... más código
}

Pero el resultado es mucho mejor para el principal cliente del código. ¿Quién es este?

¿Quién es el principal cliente del código?

Quizá muchos de ustedes dirán después de la primera sección, porque tanto trabajo para una función que estaba bien y no hacía daño a nadie. Para ser muy sincero nunca he sido fan del “si funciona no lo toques”, esto es por que el principal cliente de nuestro código, no es el cliente, es otro programador.

El usuario utiliza la funcionalidad y no le importa para nada como esta esté implementada, pero el que va a tener que revisar ese desarrollo, mantenerlo y mejorarlo es otro programador.

Es por ello que algunos “tydings” aplicados en la sección anterior, como otros señalados por Kent Beck en su libro permiten reducir el número de WTF que nuestro código produce si se aplican de manera adecuada.

Expliquemos un poco mejor algunos de ellos

Tyding	Descripción
Escribir comentarios	Explicación de lo que hace cierta sección de código o notas para comprender mejor la sentencia.
Eliminar comentarios redundantes	Identificar y remover comentarios que expresan exactamente una sección de código que se explica por si misma.
Extraer funciones utilitarias	Identificar secciones de código en una función o método que no está directamente relacionada a la función pero que sirve de soporte.
Guardias	Al inicio de una función o método hacer todas las validaciones sobre los parámetros.
Orden de cohesión y de lectura	Agrupar y ordenar el código que comparten una función en espacios comunes.
Normalizar simetrias	Usar patrones y formatos de código similares dentro de todo el proyecto.
Eliminar código muerto	Remover código que ya no se usa.
Variables y Constantes con significado	Promover que las variables y las constantes tengan un buen nombre

Pequeños “tydings” cómo los mencionados en este momento quizá no son la panacea para todos los problemas que tiene nuestro proyecto pero nos permiten lo siguiente:

Mejorar la legibilidad y el entendimiento del código.
Analizar el uso de cierta sentencia o resultado pre existente en el código.
Descubrir areas de mejora.

El software es un ente vivo que cambia constantemente, por lo que es altamente probable que el código que escribimos deba ser modificado o utilizado en otros contextos según lo requiera el proyecto. Es por ello que entre más fácil sea leerlo, más fácil será utilizarlo para resolver nuevos problemas.

El mayor costo del código es el costo de leerlo y entenderlo, no el de escribirlo

Kent Beck

Conclusión

Quizá este blog deje muchas preguntas abiertas: ¿Cuándo debo aplicar estos “tidyings”? ¿Todas mis funciones deben ser así de detalladas? ¿Qué pasa cuando no tengo el tiempo para ordenar el código? ¿Y si en vez de ayudar termino dañando algo?

Estas preguntas son válidas y dan mucho sentido al por qué el libro se llama “Tyding First?” con un signo de interrogación. El autor nos explica en la segunda parte del libro el cuándo y cómo aplicar estos cambios, ideas que me gustaría abordar en un siguiente blog.

Por ahora, lo más importante que deseo que nos llevemos es que los “Tydings” son este conjunto de pequeñas acciones que nos permiten mejorar la calidad de nuestro código en función de la legibilidad y el entendimiento del mismo, para así evitarle en su medida dolores de cabeza a nuestros principales clientes, los otros desarrolladores.

Recursos:

Tidy First, Kent Beck: https://learning.oreilly.com/library/view/tidy-first/9781098151232/

SE Radio 615: Kent Beck on “Tidy First”: https://open.spotify.com/episode/6XHBSDSSuH0xBDz1LeiAUE?si=44cab186651b486d

Mis primeras 3 lecciones como Arquitecto de Soluciones

Jean Karlo Obando Ramos — Mon, 30 Sep 2024 03:56:55 +0000

Originalmente publicado en: https://blog.jeankaobando.com/blog/2024/first-3-lessons-solutions-architect/

Tabla de Contenidos

Introducción
Lección 1: Un nuevo comienzo
Lección 2: Pregunta, pregunta, pregunta
Lección 3: El desarrollo no lo harás tú
Conclusión
Recursos

Introducción

Hace un mes mi carrera profesional dio un salto importante, me convertí en Arquitecto de Soluciones. Luego de pasar por el proceso de ascenso, me encontraba listo para empezar este nuevo reto.

Comencé el primer día con mucha energía, busqué ponerme en contexto lo más pronto posible, revisé la lista de proyectos asignados a mi equipo y me aventuré a tomar un par de ellos.

A los pocos días ya me encontraba activo, daba mi opinión sobre cómo resolver uno u otro problema, mi agenda estaba llena de reuniones y planifiqué mi primer sprint como líder.

El resultado de este primer mes ha sido interesante y un poco caótico también. Por ello me gustaría reflexionar un poco acerca de las lecciones que he aprendido en este corto tiempo.

Lección 1: Un nuevo comienzo

Una de las primeras misiones que me puse fue aprender lo más que pueda sobre mi rol, tengo claro que es ser “desarrollador” pero ¿Que significa ser Arquitecto de Soluciones?

En esa búsqueda me encontré con el libro “The Art of Leadership, Small Things Done Well” de Michael Loop, líder tecnológico en empresas cómo Netscape, Slack y Apple. De este libro me gustaría citar la frase que me ha acompañado en las últimas semanas.

Remember, management isn’t a promotion, it’s a career restart. Michael Loop.

Estar en paz con la idea de que soy nuevo en el cargo ha sido complicado para mí, sé cómo ser un desarrollador, un buen desarrollador. He ganado cierta experiencia que me permite resolver problemas con cierta facilidad o al menos tengo cierta noción de como enfrentarlos. Pero ahora, todo se ve nuevo: la reunión con los Stakeholders, el diseño de arquitecturas en modelo C4, la revisión de métricas, la creación y planificación de historias de usuario, la administración de equipos y la responsabilidad sobre ellos. Todo es nuevo.

La frase de Loop ha resonado en mí precisamente por esto, y cómo lo explica el libro, un error que todo líder técnico junior comete es precisamente sentir que ha alcanzado un nuevo nivel de juego cuando lo que ha pasado es que ahora está en un juego diferente.

Esta idea es importante porque nos permite ser conscientes de nuestra falta de experiencia y estar tranquilos con ello, tomar las cosas con calma y cómo pasó al momento de empezar nuestra carrera, estar listos para tomar retos, equivocarse en el proceso y aprende de ello.

Lo que me lleva a mi segunda lección.

Lección 2: Pregunta, pregunta, pregunta

Recuerdo una vez que unos superiores me dijo: “Jean, si no sabes algo pregunta, trata de resolverlo por ti mismo por unos 30 minutos o una hora, pero si no logras, pregunta, todos queremos que esto salga bien”. Este consejo me ha acompañado a lo largo de los años.

Cómo lo explico en la sección anterior, las responsabilidades que trae el cargo de Arquitecto de Soluciones va más allá del desarrollo de código, de hecho casi no existe desarrollo, por lo que muchas cosas no vas a saber cómo resolverlas o al menos cómo empezar, ante esta situación pregunta.

Te piden que consigas los conformes del equipo de seguridades para la iniciativa del equipo, pregunta ¿con quién tengo que hablar? ¿cuál es proceso para recibir los conformes? ¿qué evidencia necesito adjuntar para conseguir la aprobación? ¿debo enviar la evidencia por correo o por mensaje?

Te piden que planifiques una migración de tecnología pregunta ¿por qué hacemos la migración? ¿qué componentes afectan este cambio? ¿qué tiempo tenemos? ¿quién tanto tiene que revisar este cambio?

Para ello apóyate de tus compañeros que tienen más experiencia que tú, ellos ya lo vivieron y han aprendido ciertos hacks para que los procesos salgan bien y más rápido. Apóyate de tu equipo, por lo general al inicio ellos tienen más contexto que tú del sistema, de las tecnologías que usan y por qué las usan. Apóyate de tus jefes, ellos te han dado la confianza, lo que significa que son conscientes de tus habilidades, pero también de lo mucho que tienes que aprender.

Y cómo decía mi compañero, por lo general a todos nos interesa que nos vaya bien, de ello depende nuestro trabajo. Así que pregunta, que por lo general todos están dispuestos a darte una mano.

Lección 3: El desarrollo no lo harás tú

Finalmente, un último gran aprendizaje que tuve este mes fue entender que el desarrollo no lo haré yo. La inercia hace difícil dejar de lado el impulso de ir por el código y programar las soluciones propuestas, pero esto no es lo más saludable, ¿por qué?

En primer lugar, tienes otras responsabilidades, por lo que a menos de que trabajes más de tus ocho horas o descuides tus principales responsabilidades, te convertirás en un cuello de botella para el equipo, cómo lo comenta Michael Loop en su libro.

Además, estarás descartando las ideas de los otros miembros del equipo que, por un lado, pueden contar con una mejor solución técnica al problema o por el otro necesitan trabajar en esta iniciativa para ganar experiencia y volverse mejores en su trabajo.

Esta idea también es importante tenerla en cuenta al momento de crear las historias de usuario y planificar el trabajo. Entender que el desarrollo no lo harás tú evitarás que subestimes o sobreestimes el tiempo que toma una tarea. Busca conocer a tu equipo, identifica cuáles son sus puntos fuertes y de mejora, planifica para ellos y busca su crecimiento, eso es parte de tu trabajo.

Finalmente, busca espacios para seguir practicando: pet projects, automatizaciones, cursos, hackatones, code reviews. La idea detrás de esto es simple, no pierdas la práctica. El desarrollo te ha llevado a tu puesto, además es el corazón y los cimientos de toda tu carrera.

Conclusión

Me falta mucho por aprender y cuatro semanas de trabajo no me vuelven un Arquitecto de Soluciones Senior, pero considero que estas primeras lecciones me acompañaran a lo largo de mi carrera y espero que puedan guiar a otros que están viviendo una experiencia similar a la mía.

Recuerda que este es nuevo comienzo, no te canses de preguntar y ten siempre en mente que ahora el desarrollo no lo haces tú.

Recursos

The Art of Leadership: Small Things, Done Well

¿Cómo funciona la función bisect en JS?

Jean Karlo Obando Ramos — Thu, 22 Jun 2023 17:18:00 +0000

Originalmente publicado en: https://blog.jeankaobando.com/blog/2023/bisect/

Tabla de Contenidos

Introducción
Binary Search
Función Bisect
Aplicando Bisect
Conclusión
Recursos

Mientras trabajaba en un ejercicio de algoritmos, me encontré con la siguiente situación: necesitaba determinar si dentro de un arreglo de posiciones de un carácter dentro en un string existía un valor después de una posición dada. Ejemplo:

// Existe un caracter "a" en el string después de la posición 4?
const string = 'aaabbabc'
const aPos = [0,1,2,5]
const targetPosition = 4

Introducción

Una manera sencilla de resolver este problema es la siguiente:

Iterar a través del arreglo
Comparar si el número es menor que el valor que se busca.

2.1. Si es menor avanzar al siguiente número

2.2. Si es igual retornar la siguiente posición. Si la siguiente posición es mayor o igual al tamaño del arreglo retornar -1

2.3 Si es mayor retornar la actual posición.
Si se itera todo el arreglo, significa que no existe esa posición, entonces retornar -1.

Aquí está la implementación:

const getNextPositionAfter = (positions, targetPosition) => {
  for (let pos of positions) {
    if (pos === targetPosition) {
      return pos + 1 < positions.length ? pos + 1 : -1;
    } else if (pos > targetPosition) {
      return pos;
    }
  }
  return -1;
}

console.log(getNextPositionAfter([0, 1, 2, 5], 4)); // 5
console.log(getNextPositionAfter([0, 1, 2, 5], 7)); // -1
console.log(getNextPositionAfter([0, 1, 2, 5], 1)); // 2
console.log(getNextPositionAfter([0, 1, 2, 5], 5)); // -1

Si analizamos la función vemos que la complejidad de tiempo es $O (n)$ . Y he aquí la pregunta de siempre, lo podemos hacer mejor? Pues sí, de hecho estamos obviando una caracteristica importante del arreglo, está ordenado. Eso significa que podemos intentar aplicar Binary Search o algún algoritmo similar a este.

Binary Search

Recordemos brevemente la definición del algoritmo Binary Search.

El algoritmo de búsqueda Binary Search define que dentro de un arreglo de datos ordenados, podemos analizar el elemento de la mitad, si es el elemento que busco retorno su índice, caso contrario verifico si el valor de la mitad es menor al elemento que busco. Si la sentencia es verdera descarto de mi busqueda el lado derecho, si es falsa el lado izquierdo de mi arreglo. Y así hasta encontrar mi valor o quedarme sin elementos por analizar. Su complejidad es $O (l o g n)$ . Mira más información aquí.

Su implementación sería la siguiente:

const binarySearch = (array, target) => {
  let startIdx = 0;
  let endIdx = array.length;

  while (startIdx < endIdx) {
    const midIdx = startIdx + Math.floor((endIdx - startIdx) / 2);
    const midValue = array[midIdx]

    if (target === midValue) {
      return midIdx;
    } else if (target < midValue) {
      endIdx = midValue;
    } else {
      startIdx = midValue + 1;
    }
  }

  return -1;
}

console.log(binarySearch([0, 1, 2, 5], 2)); // 2
console.log(binarySearch([0, 1, 2, 5], 5)); // 3
console.log(binarySearch([0, 1, 2, 5], 7)); // -1
console.log(binarySearch([0, 1, 2, 5], 4)); // -1

Podemos aplicar Binary Search a nuestro problema inicial? La respuesta es no ... todavía.
Nuestro problema exige no solamente que encontremos un valor, sino que retornemos la posición siguiente a un valor dado.
Si puedo plantear el problema en otras palabras puedo decir que lo que buscamos es:

Encontrar la posición en la que podemos insertar un elemento dado de tal manera que la lista siga ordenada.

Bajo esta premisa, me encontré que existe una función en Python que hace precisamente esto y está basada en Binary Search.

Función Bisect

Si vamos a la documentación de Python nos indica lo siguiente acerca de bisect.

Bisect provee un soporte para mantener listas ordenadas sin la necesidad de hacer un reordenamiento después de un inserción.
Más información aquí

Veamos a continuación cómo funciona:

from bisect import bisect

print(bisect([0, 1, 2, 5], 4)) # 3
print(bisect([0, 1, 2, 5], 5)) # 4
print(bisect([0, 1, 2, 5], 1)) # 2
print(bisect([0, 1, 2, 5], 7)) # 4
print(bisect([0, 1, 2, 5], -1)) # 0

Si analizamos las salidas, podemos concluir lo siguiente:

Si encuentra que el elemento es mayor o igual al valor que está analizando, devuelve su valor + 1, para mantener la lista ordenada
Si el elemento es mayor el último valor del arreglo, retorna como índice el tamaño del arreglo
Si el elemento es menor al primer valor del arreglo, retorna 0 como índice.

Cabe destacar que cuando el elemento está en la lista, no necesariamente debe devolverse el índice a la derecha, también puede ser el índice a la izquierda. Es por ello que Python define otras dos funciones denominadas bisect_left y bisect_right. Por defecto bisect funciona cómo bisect_right.

Lamentablemente, estas funciones no están implementadas en Javascript, por lo que procedemos a hacer nuestra propia implementación usando como base la función Binary Search. Empecemos con bisect_right.

Bisect Right

Si observamos bien la función Binary Search, lo que hace es acortar el rango de valores a analizar moviendo valores por la izquierda y la derecha. Esta acción produce que si el valor no se encuentra presente en la lista, el valor de startIdx va a ser el índice dónde debería estar ese valor.

Ejemplo.

Tomemos el arreglo [0, 1, 2, 5] y digamos que debemos insertar el valor 4;
Analizemos cómo se compartaría binary search.

startIdx	endIdx	midIdx	midValue
0	4	2	2
3	4	3	5
3	3	-	-

La respuesta sería falso.

Sin embargo startIdx (endIdx también) tiene el índice dónde debería estar 4, que es la posición 3. Esto es justamente lo que necesitamos para implementar bisect_right usando binary search.

Haciendo algunos cambios al algoritmo inicial, el resultado que tenemos es el siguiente.

const bisectRight = (array, target) => {
  let startIdx = 0;
  let endIdx = array.length;

  while (startIdx < endIdx) {
    const midIdx = startIdx + Math.floor((endIdx - startIdx) / 2);
    const midValue = array[midIdx]

    if (target < midValue) {
      endIdx = midIdx;
    } else {
      startIdx = midIdx + 1;
    }
  }

  return startIdx;
}

console.log(bisectRight([0, 1, 2, 5], 4)) // 3
console.log(bisectRight([0, 1, 2, 5], 5)) // 4
console.log(bisectRight([0, 1, 2, 5], 1)) // 2
console.log(bisectRight([0, 1, 2, 5], 7)) // 4
console.log(bisectRight([0, 1, 2, 5], -1)) // 0

Como se ve en el código, ya no tenemos la sentencia para verificar si el valor se encuentra en el arreglo. Lo que tratamos es forzar que el startIdx nos indique la posición en la que debería estar un valor dado en el arreglo.

Qué pasa si el valor está en el arreglo? Pues cómo se ve la sección else del algoritmo, el índice retornado será el de la derecha startIdx = midIdx + 1;.

Bisect Left

Ahora que pasa si lo que nos piden es devolver el índice a la izquierda del valor dado. Simple, evitamos que si el valor se encuentra en el arreglo se aumente el índice en 1, para ello hacemos el siguiente cambio en el algoritmo: if (target <= midValue) de tal modo que el resultado sería el siguiente:

const bisectLeft = (array, target) => {
  let startIdx = 0;
  let endIdx = array.length;

  while (startIdx < endIdx) {
    const midIdx = startIdx + Math.floor((endIdx - startIdx) / 2);
    const midValue = array[midIdx]

    if (target <= midValue) {
      endIdx = midIdx;
    } else {
      startIdx = midIdx + 1;
    }
  }

  return startIdx;
}

console.log(bisectLeft([0, 1, 2, 5], 4)) // 3
console.log(bisectLeft([0, 1, 2, 5], 5)) // 3
console.log(bisectLeft([0, 1, 2, 5], 1)) // 1
console.log(bisectLeft([0, 1, 2, 5], 7)) // 4
console.log(bisectLeft([0, 1, 2, 5], -1)) // 0

Aplicando Bisect

Cool!! Ahora que tenemos claro cómo funciona bisect, apliquémoslo a nuestro problema inicial.

// Existe un caracter "a" en el string después de la posición 4?
const string = 'aaabbabc'
const aPos = [0,1,2,5]
const targetPosition = 4

El algoritmo sería el siguiente:

const getNextPositionAfter = (positions, targetPosition) => {
  const nextIdx = bisectRight(positions, targetPosition);

  if (nextIdx === positions.length) {
     return -1;
  }
  return positions[nextIdx];
}

console.log(getNextPositionAfter([0, 1, 2, 5], 4)); // 5
console.log(getNextPositionAfter([0, 1, 2, 5], 7)); // -1
console.log(getNextPositionAfter([0, 1, 2, 5], 1)); // 2
console.log(getNextPositionAfter([0, 1, 2, 5], 5)); // -1

// Aquí debería estar implementado bisectRight

Boom!!! Tenemos una nueva solución para nuestro problema inicial, el cual tiene una complejidad de tiempo de $O (l o g n)$ , que es mucho mejor a $O (n)$ , cómo se puede ver en la siguiente gráfica.

Conclusión

La función bisect nos permite identificar la posición en la que debería ir un valor si fuera agregado a una lista.
Siempre debemos estar atentos a los datos ocultos de un problema, en este caso el saber que el arreglo es ordenado nos permitió aplicar bisect, lo que redujo la complejidad de nuestro problema significativamente.
Si una función no está implementada en tu lenguaje, siempre puedes implementarla tú :D.

Recursos

Binary Search: https://www.geeksforgeeks.org/binary-search/
Documentación acerca de Bisect en Python: https://docs.python.org/3/library/bisect.html#module-bisect