Voy a contaros por donde andan últimamente mis ideas sobre como organizar una aplicación. Me parece muy pretencioso llamarlo Arquitectura, así que tal vez pueda dejarlo en Diseño de aplicaciones. O tal vez Narrativa de Aplicaciones, porque una aplicación cuenta una historia.

De hecho, la narrativa de aplicaciones es similar a la narrativa convencional (literaria o no). Del mismo modo que un relato necesita una estructura para que se pueda entender, una aplicación necesita una estructura para que sea comprensible.

Podemos usar diferentes estructuras para representar diferentes tipos de historias. Por ejemplo, la estructura narrativa más básica es algo así como "presentación, nudo y desenlace", pero para contenidos más expositivos podríamos utilizar una estructura "problema, solución", etc.

La historia que cuenta una aplicación es la historia de los deseos e intenciones de sus usuarios o consumidores, que en último término siempre serán humanos, aunque a veces haya otras aplicaciones trabajando en su nombre.

Estas intenciones y deseos deben estar reflejados en el código de alguna forma y constituyen uno de los tres pilares básicos que componen una aplicación, junto con un modelo del mundo y las soluciones tecnológicas de implementación.

Las intenciones y deseos de los usuarios se representan mediante casos de uso, que los describen en código. Pueden ser de dos tipos: comandos y queries. Los comandos provocan cambios en el sistema y las queries obtienen información del mismo.

Los casos de uso son como micro aplicaciones que ejecutan una parte del modelo del mundo para satisfacer las necesidades de los usuarios. Usualmente los implementamos con el patrón command + command handler (o query + query handler)

¿Y qué es es de un modelo del mundo? Pues es una representación del trozo del universo en el que los usuarios quieren satisfacer sus necesidades. Esta representación incluye conceptos, procesos y reglas que definen lo que es posible y lo que no y sus condiciones.

Los elementos de este modelo del mundo actúan de la forma definida por esas reglas. La forma de implementar este modelo del mundo debería ser totalmente independiente de cualquier tecnología específica que no sea el lenguaje de programación usado para desarrollar la aplicación.

Esto es así para no introducir en el modelo del mundo elementos que, de hecho, no existen en la realidad de ese cachito del universo. Deberías poder ejecutar la aplicación sin ninguno de estos elementos tecnológicos, usando para ellos objetos del lenguaje que los representen.

Pero para que una aplicación sea útil es cierto que tiene que implementarse mediante algunas tecnologías específicas, que la hagan efectiva. Todas estas soluciones tecnológicas deberían implementarse de tal forma que sean reemplazables.

Estos tres elementos básicos se pueden representar en el código en forma de carpetas que agrupen sus componentes. En la propuesta de DDD de Eric Evans estos elementos serían Dominio, Aplicación e Infraestructura. En la propuesta de la Arquitectura Hexagonal, el modelo del mundo..

y las intenciones de los usuarios forman parte de la aplicación, mientras que los elementos tecnológicos se representan mediante sus adaptadores, que implementan puertos (o interfaces) definidos por la aplicación.

No hay ninguna razón por la que debas seguir uno de estos modelos, u otro si vamos al caso. Pero es importante seguir algunos principios organizativos. Por ejemplo, el modelo del mundo, no debe tener dependencias de la implementación técnica, así que usarás inversión de control.

Tampoco es necesario que estas capas sean las que definan la raíz del código de tu proyecto. Desde el punto de vista narrativo, lo que cuenta la historia son los casos de uso, así que esta podría ser una mejor forma de estructurar la aplicación desde su raíz.

Y tal vez, si la aplicación es muy grande, debas agrupar estos casos de uso en bloques relacionados. En cualquier caso, una regla importante, a la hora de estructuras carpetas y archivos del código es que en los casos de uso y en el modelo del mundo no debe haber ninguna mención

a elementos técnicos de cualquier tipo (salvo alguna excepción), así que nunca deberían aparecer menciones a entidades, value objects, servicios, bases de datos, etc. Esto es, no estoy diciendo que no haya conceptos representados en forma de entidad o value object, sino que no

debes organizarlos por sus tipos (no tengas carpetas llamadas entidades, value objects, servicios, o similares). Usa siempre el lenguaje del fragmento del mundo que estas modelando.

En general, organiza el código en torno a este modelo del mundo, Usa conceptos agregadores que existan en ese mundo. Destierra cualquier mención al soporte tecnológico.

La infraestructura o capa técnica debería también organizarse en torno a esos conceptos.

Esto tiene un valor práctica. Recuerda el principio de co-variación: las cosas que cambian juntas deberían estar juntas. Una implementación de persistencia del concepto usuario, p.ej., cambiará en respuesta a cambios en el concepto de usuario. Pero no lo hará si cambia

una implementación de persistencia del concepto facturas. En resumen: no uses criterios técnicos como agregadores de conceptos en una aplicación.

Al respecto la capa técnica, utilizada siempre como si no fuese tuya. Para ello tienes que abstraerla usando un patrón adapter, de tal modo que tú controles la interfaz pública de esa solución tecnológica.

Muy posiblemente, una aplicación estará mejor estructura, será más escaladle y fácil de mantener si se estructura en torno al modelo del mundo que contiene y no a los elementos tecnológicos que la implementan.

Deja que el código cuente la historia de ese modelo del mundo y de las intenciones y deseos de sus usuarios.

Narrativa de aplicaciones

Con frecuencia hay hilos de "las N tecnologías/lenguajes/herramientas que debes aprender para impulsar tu carrera de desarrolladora".
Voy a proponer una lista de cosas que aprender que realmente van a marcar una diferencia y que no te atan a ninguna tecnología.

Si quieres tener una referencia única de estas técnicas, consigue este libro, que aumenta su valor cada día: Working Effectively with Legacy Code de @mfeathers 

https://www.amazon.es/Working-Effectively-Legacy-Robert-Martin/dp/0131177052

1. Hacer tests de caracterización: aprende a hacer tests cuando no conoces el código con el que trabajas, logrando alta cobertura y entender cómo funciona el software. Por ejemplo, con este vídeo de Emily Bache https://www.youtube.com/watch?v=zyM2Ep28ED8

Una alternativa es este vídeo de mi compa  @jchacana sobre la técnica Golden Master (que es muy similar) https://www.youtube.com/watch?v=cI7CtKwsE_w

2. Romper dependencias. Una de las fuentes de alto acoplamiento son las dependencias duras. Para esto hay varias técnicas. Por ejemplo, los "seams" o costuras. Aquí un vídeo de Codely, con @JavierCane  https://www.youtube.com/watch?v=uQwaicxUbb0

3. Sprout. En vez de cambiar código existente y que tal vez no tenga tests, introduce una versión nueva en paralelo (con TDD y todo eso) y finaliza llamándolo desde el viejo. Ejemplos aquí: https://biratkirat.medium.com/working-effectively-with-legacy-code-mechanics-of-change-part-ii-chapter-1-91f2129c3b72

4. Wrap. Renombra un método que quieres cambiar y añade uno nuevo con el mismo nombre y signatura que el "viejo". Llama al viejo desde el nuevo. Progresivamente, realiza los cambios que necesites en el nuevo método. https://biratkirat.medium.com/working-effectively-with-legacy-code-mechanics-of-change-part-ii-chapter-1-91f2129c3b72

5. Cambio paralelo. Supón que quieres reemplazar cierto método usado desde muchos lugares del código. Introduce el cambio en un nuevo método (usa TDD). Marca el viejo como deprecated. Migra progresivamente las llamadas al viejo método por el nuevo. Cuando no quedan llamadas...

elimina la versión deprecated.  Una explicación aquí: http://xurxodev.com/trabajando-con-codigo-legado-parallel-change/

6. Branch by abstraction. En lugar de ramas en Git haz las "ramas" en código. Introduce una abstracción que aisle el código que necesitas cambiar, de modo que el resto "no se entere". Cambia progresivamente el nuevo código  haciendo commits a main https://www.branchbyabstraction.com/

7. Aprende Calisthenics: una serie de prácticas simples que te ayudarán a desarrollar un sentido del diseño de código limpio y legible.

https://blog.avenuecode.com/object-calisthenics-principles-for-better-object-oriented-code

8. Método Mikado. Introduce un cambio deseado en el código y observa qué error genera. Deshaz el cambio y modifica para que no se vuelva a producir el error. Repite hasta que el cambio funcione. 
Lo tienes en libro: https://mikadomethod.info/ y https://understandlegacycode.com/blog/a-process-to-do-safe-changes-in-a-complex-codebase/

Hay muchas más técnicas que puedes aprender. Todas ellas son independientes de tecnología concreta y todas ellas te serán útiles.

Por otro lado, sé que estas técnicas se refieren a trabajar con código "legacy", pero en realidad todo código es "legacy" en cuanto está en producción, así que... haz cuentas.

(corrijo: el vídeo sobre Golden Master es de mi también compa Sebastian Kulinski, y presentado por Javi Chacana)

Cosas que aprender para mejorar de verdad como developer

Muy resumido, una kata es un pequeño ejercicio de código, que realizas de forma repetida para ayudarte a practicar una técnica de programación. De hecho, el objetivo no es resolver el problema planteado, sino ejercitar y automatizar ciertas formas de trabajar.

Es una manera de llevar a cabo una práctica de aprendizaje deliberada e intencional. Es decir, haces katas porque quieres aprender a trabajar de cierta manera. Por ejemplo, usando TDD, usando un enfoque funcional, haciendo OOP estricta, con un lenguaje nuevo, lo que quieras.

El nombre viene de las katas de las artes marciales, en el sentido de que son ejercicios para automatizar ciertas destrezas.

Puedes encontrar repositorios de katas en Internet. Algunas son muy comunes y conocidas (leap year, fizzbuzz, gilded rose, mars rover, bowling...), pero se crean nuevas todos los días. Son problemas simples que plantean algún aspecto interesante.

También hablamos de coding-dojo, que sería un espacio comunitario en que se lleva a cabo la kata.

Este espacio debe ser un espacio seguro e inclusivo. Es un entorno para el aprendizaje. No es competitivo, sino cooperativo. Personas de diferente origen, experiencia, etc. participan juntas y se ayudan mutuamente. No se requiere un stack, experiencia, rol o nivel de seniority.

Si no se desarrolla en un espacio seguro entonces no estás haciendo un coding-dojo. Estás haciendo otra cosa (no sé lo qué). Por eso, si alguien se siente mal en esa situación es que hay algo que no está bien hecho. El entorno, la elección del ejercicio, el objetivo...

Por supuesto, puedes practicar con katas de forma individual y privada. Pero le puedes sacar mucho más partido en comunidad.

Los coding dojo pueden ser muy divertidos. Son una buena manera de organizarse como parte del proceso de formación interna en una empresa, que de esa forma es autogestionada por el equipo.

Las reglas de los Open Spaces encajan perfectamente con los coding dojo, por cierto.

Otro punto importante es que esto se hace con problemas de código que no son de trabajo. No queremos añadir la presión o la necesidad de conseguir un resultado que vaya a aplicarse. 

Por lo general, los ejercicios en las katas son realmente sencillos. Se pretende que entiendas el dominio del problema en unos pocos minutos y que desarrollar la solución no requiera mucho tiempo.


Por supuesto, hay ejercicios que son más largos porque quieres trabajar alguna idea o metodología que requiere más tiempo de por sí. Por ejemplo, BDD o TDD outside-in suelen requerir más tiempo. O si quieres practicar desarrollo iterativo con requisitos que cambian.

Algunos ejercicios están pensados para ayudar en ciertos aprendizajes específicos o bien se adaptan mejor a aprender ciertos conceptos. La forma de presentación también puede ser importante.

Pero sobre todo, no hay una solución correcta ni un proceso correcto. De hecho, si lo haces en un coding-dojo lo habitual es compartir y explicar la solución para que las demás personas puedan ver esa distintas aproximaciones que tal vez no conozcan.

Incluyendo lenguajes o paradigmas que no usan habitualmente. Lo ideal sería que esto genere debate, preguntas, etc. de modo que se comparta conocimiento de diversas formas.

De hecho, no se debe avanzar si hay alguien que tiene dudas sobre una solución propuesta.

Lo mejor que puedes hacer si no te sale una kata es borrar todo, empezar de nuevo si tienes ganas, y si no... a otra cosa.

Da igual que sea que te la hayas propuesto como ejercicio personal o que estés es un coding-dojo. Lo dejas, y a otra cosa.

No se trata de hacer ejercicios en plan hacker-rank y ganar puntos, no se trata de demostrar que sabes más o menos que nadie. Se trata de aprender a hacer algo de una forma determinada y practicarla hasta que nos va saliendo de forma natural.

Y si lo haces en compañía es también una forma de aprender a trabajar juntas. Una buena idea es tratar de trabajar con gente con la que no trabajes habitualmente.

Es bastante típico hacer katas para aprender TDD, pero también para aprender técnicas de refactoring, identificar smells, aprender un lenguaje nuevo, practicar un paradigma diferente... o cualquier cosa que consideres que quieres practicar.

Acerca de las katas

Voy a intentar resumir algunas ideas que he sacado de esta conversación sobre el desarrollo profesional. Creo que han salido cosas interesantes y agradezco a todas las participantes por sus ideas.

Un primer nivel sería el crecimiento dentro de un equipo. En este punto tengo que decir que para mi el desarrollo de software es una actividad social y técnica. Personas creando software que afecta a la vida de otras personas. Por supuesto, no incluye la idea de trabajar aislado.

De hecho, es un comentario que he visto, pero nada más alejado de la realidad. No se trata de trabajar en aislamiento, sino de progresar sin tener que seguir un camino de management.

Dentro de un equipo a medida que se gana experiencia y "senitority" se contribuye con mentoring y liderazgo. Esto de una forma orgánica. No es que adquieras un cargo nominal de mentor o lead o manager. Es una cuestión de actuar en beneficio del equipo y sus objetivos.

Esto permite un espacio de crecimiento, aunque es posible que dependiendo de las personas o de las propias circunstancias del equipo, esto tenga un límite en lo que toca al progreso profesional. P. ej., al no cambiar de puesto nominal podrías no tener opción a mejorar salario.

Pero también podría ser que el producto de ese equipo esté en una fase de mantenimiento y no evolución, que no presente desafíos interesantes o que no ofrezca oportunidades para introducir nuevas prácticas o tecnologías.

¿Qué opciones de carrera se pueden dar entonces?

Un problema es que diría que no siempre coinciden las definiciones de roles y posiciones entre distintas empresas. Por ejemplo, yo pienso que los roles de liderazgo técnico son también roles de gestión. No la misma que la del path de Engineering Manager, pero gestión...

En el sentido de de organizar equipos, convencer, gestionar recursos, responsabilizarse de objetivos, etc. Y, por supuesto, implicar gestionar personas y lidiar con sus intereses, motivaciones, aunque sea relacionado con una meta técnica.

O sea, que estos dos caminos: el manager y el técnico, implican un cierto nivel de gestión (management). Y son las que pueden conllevar aumento de salarios, a la par que responsabilidades e influencia. Pero también creo que significan un salto cualitativo.

No es lo mismo ser developer que engineering manager o tech lead. Implican diferentes conjuntos de habilidades y conocimientos. ¿Se solapan cosas? Por supuesto.

Y, volviendo al punto inicial, ¿Existen otras opciones?

Por ejemplo, no parece que se hable mucho de la posibilidad de moverse horizontalmente entre equipos de una misma empresa, abordando nuevos problemas de negocio o nuevas opciones de tecnología.

La opción más "popular" parece ser cambiar de empresa si se busca mejor salario o una situación más estimulante que facilite nuevos retos y aprendizajes.

Me surge la pregunta de si los paths de carrera están excesivamente orientados en el crecimiento de management y dejan de lado cuidar a las profesionales que no se sienten llamados al management, pero que pueden aportar mucho desde sus puestos.

Y si la opción que queda es marcharse... ¿No significa eso una pérdida de valor y un aumento de coste al tener que contratar personal nuevo, que tiene que aprender hasta llegar al nivel de la persona que se ha marchado?

Career path

¿Qué es el buen diseño de software? Es una de esas preguntas para las que es difícil encontrar una respuesta convincente. Muchas veces no entendemos lo que es el buen diseño hasta que lo vemos. Si es que lo vemos, porque el buen diseño tiende a parecer obvio.

Y al parecer obvio es como si no requiriese un esfuerzo. Todas las piezas encajan. Es aprehensible. Es intuitivo. Pero el buen diseño suele ser fruto de mucho trabajo y mucha reflexión. Puede ser muy complicado explicar cómo diseñar bien por lo que a veces tenemos que centrarnos

en lo opuesto. O sea, en cómo diseñar mal y evitarlo. Parafraseando algo que leí alguna vez sobre cine: podemos discutir mucho sobre lo que hace buena a una película, pero hay mucho acuerdo en aquello que la hace mala. En software es algo parecido, es fácil ver lo que está mal.

Veamos algunos anti-principios (que me he sacado de la manga)

Anti-principio de inutilidad. El software no hace lo que se espera de él, no responde a las necesidades de las usuarias o lo hace de tal manera que es preferible no usarlo. Tenemos unos cuantos ejemplos en administraciones públicas.

Anti-principio de defectuosidad. El software puede ser útil, pero está plagado de defectos. No es confiable. A veces funciona, a veces no. Depende de condiciones que no podemos controlar (alto acoplamiento, dependencias técnicas, etc.)

Anti-principio de no reutilización. Los módulos de código no se pueden reutilizar. De nuevo, el acoplamiento es tan alto que es muy costoso reutilizarlo, lo que lleva a duplicaciones de conocimiento y resultados incongruentes según cómo lo utilices.

Anti-principio de desorganización. El código es una gran bola de lodo en el que es muy difícil encontrar algo, lo que favorece que sea más barato añadir más lodo en forma de módulos que duplican funcionalidad porque no podemos reutilizar lo existente.

Anti-principio de no testeabilidad. El código no es testeable. Por su falta de organización, modularización inadecuada o inexistente, el código es muy difícil de poner bajo test. Incluso podría ser imposible.

Anti-principio de ilegibilidad. El código por sí mismo no sirve para entender el conocimiento que representa. Es necesario disponer de documentación extensiva que lo explique, existiendo el riesgo de que esta documentación haya perdido la sincronía con el código.

Anti-principio de insostenibilidad. Modificar el código es una operación que entraña riesgos, porque no es posible garantizar que no generará efectos negativos en otras partes del sistema que no podemos predecir.

Probablemente haya alguno más, pero es algo por donde empezar.

Principios de mal diseño

Estoy buscando formas nuevas de explicar lo que es TDD, Test Driven Development. El mayor problema es, por supuesto, que el nombre no ayuda. Cierto que TDD consiste en escribir primero un test que defina el comportamiento que queremos desarrollar usando un ejemplo del mismo.


Por esa razón, algunas personas proponen usar la expresión Specificación by example (Especificación mediante ejemplos) que captura mejor lo que hacemos en el proceso TDD: poner ejemplos del comportamiento deseado especificando el contexto, los datos de entrada y lo que...

esperamos que suceda como consecuencia del comportamiento, ya sea una respuesta o un side effect. 

El hecho de usar Test en el nombre también tiene el efecto negativo de que mucha gente piensa en lo difícil que resulta a veces testear su código. Precisamente, es difícil

porque ese código no está pensado para ser testeado, probablemente requiere mucha preparación (un smell a la hora de hablar de tests) y puede que hasta sea imposible ponerlo bajo test tal como está.

Eso se previene haciendo TDD.

En fin. Como se ha dicho muchas veces TDD no es testing, sino desarrollo y diseño, aunque la herramienta que utilizamos sea la misma (los tests automaticos). Y lo que debe hacer un test de TDD es mostrar un ejemplo del comportamiento.

En este punto se plantea el problema de cómo tienen que ser esos ejemplos. Y aquí viene la típica historia de "empezar por el caso más sencillo". En realidad, lo correcto sería decir algo así como "el ejemplo más sencillo". "Caso" es terminología de testing.

Tampoco tengo claro que decir "el más sencillo" sea un buen consejo. A decir verdad, cualquier ejemplo nos valdría para el primer test porque nuestro primer código de producción va a ser devolver una constante. Los siguientes ejemplos son los que moverán el desarrollo.

Sin embargo, si prevemos que ciertos ejemplos van a ser más fáciles de desarrollar puede ser buena idea empezar con ellos. Pero en realidad, lo que nos interesa es desarrollar el siguiente comportamiento que nos interese más, por razones de negocio/dominio.

Una cosa que se suele pasar por alto es cuál es la función de cada fase del ciclo de TDD.

La primera es el test que falla. Esta fase define el comportamiento que queremos alcanzar para un ejemplo concreto. Este ejemplo representa un comportamiento que no existe aún y que nos interese implementar a continuación, posiblemente por razones de negocio.

El test adecuado debería construirse de una forma trivial: instanciar el componente bajo test y ejecutarlo con la

La siguiente fase es añadir el código de producción necesario para que el test que fallaba, pase. Esta fase busca establecer la "línea base" de comportamiento hasta ese momento. No implica implementar el algoritmo completo. Sólo lo suficiente para tener el nuevo comportamiento...

a la vez que se mantiene el que ya existía. Es decir, se trata de poner el test en verde cuando antes y establecer la red de seguridad para la fase de refactor. En este punto nos bastaría devolver la respuesta esperada tal cual o abrir una condicional sólo para un ejemplo.

La tercera fase es la de refactor. En TDD clásica esta fase busca introducir o mejorar el diseño de la solución mediante la identificación de oportunidades de generalizar un algoritmo para los ejemplos de que disponemos en el test, sin preocuparse de los que puedan venir después.

Esto se puede hacer aplicando las técnicas de refactoring comunes, buscando los smells generados por las implementaciones simples que hacemos en la segunda fase. Es fundamental mantener todos los tests existentes pasando, lo que garantizará que mantenemos el comportamiento.

Así que en resument, TDD o especificación mediante ejemplos es:
* Especificar mediante un ejemplo el comportamiento que deseamos implementar a continuación, para lo que usamos un test.
* Implementar la solución más obvia posible.
* Eliminar los code smells refactorizando.

Decimos muchas veces que TDD no es testing. Es que no lo es, pues forma parte del proceso de diseño. 

Sin embargo, tiene un side-effect interesante al proporcionarnos una batería de tests base. Esta batería necesita cierta limpieza ya que tras el proceso de TDD pueden quedar...

muchos ejemplos por caso (un caso se puede representar con uno o más ejemplos), que hacen tests redundantes y se pueden eliminar.
También se eliminarán alguno tests que han servido para mover el desarrollo, pero no que no aportan nada al proceso de verificación.

Dependiendo de tu enfoque al hacer TDD puedes tener distintos niveles de testing. Por ejemplo, si haces BDD posiblemente con ello tengas un tests de aceptación que ejercita el sistema desde fuera. Además de varios tests unitarios.

Entendiendo TDD

En alguna ocasión he dicho que considero que todo código en producción es legacy, ya sea que lleve meses, semanas o minutos desplegado. Este último caso puede parecerte más chocante, pero tiene una explicación. 🧻👇

En un equipo verdaderamente ágil se está poniendo código en producción a un rimo sostenido. En el instante siguiente de mezclar, el equipo ya está pensando en la siguiente pieza que va a desarrollar.

Porque además un equipo verdaderamente ágil puede desplegar con toda confianza y poner el foco en el siguiente desarrollo.

Eso implica que su conocimiento del dominio ya está cambiando. Además, el último despliegue genera nuevo feedback sobre el producto. En otras palabras, el conocimiento del dominio representando por el software existente y el conocimiento del equipo han comenzado a divergir.

Puede que poco, pero ese cambio es importante.

Esa divergencia entre el conocimiento representado en el código y el conocimiento actual del equipo puede generar una cierta cantidad de "deuda técnica": el coste de cambiar el software para reflejar correctamente el conocimiento del equipo.

Por esa razón resulta útil considerar legacy el código existente y, por tanto, refactorizarlo agresivamente.

Este refactor es necesario para reducir el coste del cambio que requerirá la nueva feature que se implemente.

Un equipo ágil habrá implementado una solución adecuada para el problema en base a su nivel de conocimiento, sin intentar generalizar antes de tiempo (principio YAGNI).

Pero una vez que sabe que va a cambiar cosas y hacía donde apunta el cambio, es conveniente trabajar en el refactor preparatorio. Ese que nos permite abaratar el coste (en dificultad y riesgo) de introducir nuevo código.

Este refactor es lo bastante pequeño para que el código sólo esté un breve tiempo en estado no desplegable. De hecho, es posible trabajar y refactorizar reduciendo el estado no desplegable a segundos.

Si no se realiza este trabajo de mantenimiento del código basado en pequeños refactors seguros, llegará un momento en que el desfase será lo bastante grande como para que el equipo se plantee un rediseño arriesgado.

Este rediseño se caracteriza por afectar gravemente a la posibilidad de desplegar el código. Es decir, el rediseño suele implicar que el código queda en estado no desplegable por días.

Es frecuente que llamemos a estos grandes cambios refactor (y que queramos tener espacio en la planificación para llevarlo a cabo). Pero no podemos considerarlos refactor si la rama de rediseño va a "vivir" varios días. Ni siquiera horas.

Existen técnicas para hacer refactor que permiten mantener el código en situación inestable (no desplegable) unos pocos segundos. En algunos casos, ni siquiera llega a estar no desplegable.

Es decir, no sólo podemos aprender los patrones de refactor, sino también las técnicas prácticas que nos permiten aplicarlos de forma completamente segura.

El código de producción es legacy

Por aclarar un poco mi argumento... no hace falta DDD o Hexagonal para hacer aplicaciones bien hechas y mantenibles. Cada equipo busca su solución y son puntos extra si es la más sencilla posible teniendo en cuenta sus circunstancias. https://twitter.com/talkingbit1/status/1500931422168793095

(Y por sencilla no digo una chambonada hecha en dos tardes con el magic framework de turno. Eso igual vale para un prototipo, para un spike, una prueba de concepto...).

Lo que quiero decir es que debemos usar nuestro propio lenguaje con propiedad y rigor porque terminamos abusando de las palabras y vaciándolas de significado de tanto hacer "mi interpretación" de lo que he leído en un post que dijo en una charla no se quién citando tal libro.

(El teléfono estropeado, vaya. Ya sabes como termina eso.)

Así te encuentras con quien define TDD como hacer test unitarios, que los tests funcionales sólo son los end to end, o que DDD es tener carpetas de dominio, aplicación e infraestructura.

O como los mocks, que le llamamos a todo mocks y hay como 5 clases diferentes.

Y claro, en algún momento no nos entenderemos al hablar, porque el mismo término será una cosa totalmente diferente para cada equipo o persona. ¿Alguien dijo lenguaje ubicuo?

Aclaro que me parece genial que se coja cualquiera de estos conceptos y se cambie porque te parece que tenga limitaciones para aplicarlo a tu problema. Simplemente, no lo llames lo que no es.

Tal vez tu problema no necesita eso. Tu trabajo es conocer esas herramientas y averiguar si sirven o no. Y desarrollar la solución que satisface mejor a tus clientes.

Y si crees que establece un patrón o una metodología nueva y útil, dale un nombre y difúndelo. Por ejemplo, BDD viene de hacer evolucionar la idea de TDD acercándola a las necesidades de los clientes. En un nivel de abstracción muy alto es lo mismo, pero en la práctica...

... hay muchas diferencias y es importante que tengamos una denominación distinta.

Que, por supuesto, eres libre de desarrollar metodologías nuevas, descubrir y nombrar patrones nuevos... pero para eso hace falta un mínimo de rigor intelectual y eso empieza por usar los nombres de las cosas con precisión.

No necesitas DDD

Para quienes no conozcan este flujo, aquí una pequeña explicación: 🧻👇 https://twitter.com/talkingbit1/status/1492176666994651138

El flujo de trabajo TCR (Test &amp;&amp; Commit || Revert) consiste en que tras cada cambio en el código de producción se lanzan los tests. Si los test pasan, se ejecuta un commit con los cambios.

Pero si los tests NO pasan, se borran los cambios aplicando un reset "duro" para eliminarlos. Es decir, si tu cambio rompe los test, se descarta.

Para automatizarlo se crea un pequeño script que realiza todo el proceso. La versión más básica simplemente hace lo que se indica: ejecutar los tests y hacer commit si han pasado o revert si no.

Esta versión simple tiene algunos problemas, porque también borraría los tests si no pasan. O si haces TDD sería bastante engorroso ya que, por defecto, se borrarían los tests nuevos al intentar ejecutarlos.

Por esa razón, se han creado algunas versiones "tuneadas" que, por ejemplo, aseguran que el código compila y que sólo se revierten los cambios en el código de producción y no se revierten los tests.

Con eso, se puede hacer TDD con TCR. Y resulta hasta mágico.

Haces un test, ejecutas el script TCR y lo ves fallar. Añades código de producción para hacerlo pasar y TCR de nuevo. Y así hasta terminar. Si metes la pata y un test que pasaba, falla, el código de producción que lo provoca se elimina. Vuelta a empezar.

Con este flujo puedes aprender a refactorizar en pequeños pasos, ya que favorece la parte de "make the change easy", manteniendo los tests en verde.

Además, como no querrás perder mucho código de una vez, te fuerza a añadir muy poquito código de producción. Si lo pierdes que sea poco.

Este flujo complementa a TDD en a parte de refactor ya que se parte de que los tests están en verde y se trata de mantenerlos en verde.

Y puede ser una buena base para hacer refactor en código legacy una vez que hayas introducido tests (por ejemplo, mediante Approval tests)

Test and commit or revert

Mi opinión de 💩 sobre la discusión de Clean Code en forma de 🧻 👇

La primera cosa es que tengo la sensación de que se confunde clean code (código limpio o código inteligible) con el libro Clean Code (y toda su serie de Clean *) y como su autor resulta tan polémico, pues el lío está servido.

Porque entonces más que intentar analizar las ideas las miramos con el filtro de las sensaciones que nos produce el autor. Unamos eso a la tendencia bastante generalizada en el sector de intentar buscar recetas simples para todo.

Que sí, que tenemos que reconocer que buscamos recetas que se puedan aplicar sin pensar mucho. De eso se ve mucho con el paradigma del DDD, que tanta urticaria da leerse el libro azul.

En fin, a lo que íbamos, la idea de que el código debería ser inteligible por sí mismo no es monopolio del tío Bob. Otros muchos referentes del sector han defendido y defienden esto desde hace mucho tiempo.

Que Bob es uno de los más vocales, polémicos y todo lo demás, también es cierto. 
Miraos las charlas y los libros de Sandi Metz y veréis la misma idea. O la biblia de Feathers sobre Legacy que al final es la búsqueda de significado en el código.

Y Pragmatic Programmer, ídem de lienzo. 

Y es que el código es un lenguaje, un idioma, con el que expresar ideas y conocimientos. Y nos olvidamos de eso.

En cualquier caso, no se trata de una guerra santa de comentaristas vs no comentaristas. Yo soy más de los segundos y explicaré por qué.

Que nadie ha pedido nunca que desaparezcan o se prohiban los comentarios, sino que se usen con cabeza, como cualquier otra herramienta.

Del mismo modo que en código buscamos evitar la duplicación cuando podemos detectar un concepto general emergente, deberíamos evitar la duplicación entre código y comentarios.

Los comentarios son una segunda narrativa aplicada al código y siempre tenemos el riesgo de que esa doble narrativa diverja en algún momento (similar a que dos pedazos de código similares pueden divergir y meternos en un lio)

Así que deberíamos considerar los comentarios como algo que añadir cuando la ocasión lo merece y cuando la posibilidad de divergencia futura con el código sea la mínima posible.

Así, por lo general, los mejores comentarios son los que explican el por qué (no el qué o el cómo, que debería ser explicado por el código mismo)

Para lograr esto utilizamos recursos de todo tipo, como nombres largos y expresivos, o extracción de métodos para igualar los niveles de abstracción en cada bloque de código, ocultando los detalles.

¿Que os parece excesivo extraer métodos de una línea? Bueno, pues puede que sí o puede que no. Cada base de código es un mundo y también diría que no es buena idea juzgar ejemplos en blogs o libros como si fuesen las tablas de la ley.

Los ejemplos en blogs y libros suelen hacerse extremos para que se vea bien la idea que se pretende transmitir. Pero si vas a copiapegar el ejemplo para aplicarlo a tu problema sin entender la razón, pues mira, apechuga con las consecuencias, que no serán bonitas.

Eso sí, hacer el ejercicio de "extraer hasta que no puedas más", "No más de de cinco líneas por función", "sólo un nivel de indentación", por ejemplo, es sanísimo.

Calistenia.

Es el equivalente para programadores de hacer sentadillas, planchas o isométricos, para la forma física. Es un modo de entrenar al cerebro para encontrar patrones y descubrir la simplicidad en un mar de líneas de código confusas.

Con ese entrenamiento de los básicos es con lo que vamos luego a enfrentarnos a los problemas de nuestros respectivos dominios.
Pero no hay recetas, no hay atajos, hay que entrenar el cerebro y usarlo. Y decidir cosas y hacerse responsable de esas decisiones.

Y un código claro, en el que se pueda entender lo que pasa es clave para eso. Y si hay que complementarlo con comentarios útiles, pues también.

Por otro lado, hay muchísima vida más allá de Clean Code (el libro) y de los principios SOLID, que parece que el diseño de software se haya reducido a si SOLID sí y SOLID no. O que si lo que dice tío Bob va a misa o mejor hagamos lo contrario.