Tech Lead compartiendo ideas prácticas sobre artesanía del software, TDD, liderazgo, Bitcoin e IA. Artículos, resúmenes de libros y charlas.Zola2023-04-14T00:00:00+00:00https://chemaclass.com/es/tags/architecture/atom.xmlCómo introducir nuevas tecnologías en tu equipo2023-04-14T00:00:00+00:002023-04-14T00:00:00+00:00 Chemaclasshttps://chemaclass.com/es/blog/introducing-a-new-tech-stack/

Cuando introduces una nueva tecnología en tu equipo, necesitas explicar el porqué y tener una estrategia clara. Va a afectar a todos.

<p>Cuando introduces una nueva tecnología en tu equipo, necesitas explicar el porqué y tener una estrategia clara. Va a afectar a todos.</p> <span id="continue-reading"></span><h2 id="por-que-ese-nuevo-stack-tecnologico">¿Por qué ese nuevo stack tecnológico? <a class="heading-anchor" href="#por-que-ese-nuevo-stack-tecnologico" title="Copy link" aria-label="Link to this section">#</a> </h2> <p>Antes de decidir, recuerda que es una decisión de equipo. Piensa en la estandarización y mantenibilidad del proyecto. Pero lo más importante: ¿qué problema quieres resolver? ¿Es porque mola? ¿O hay una necesidad real que esta tecnología resuelve?</p> <h3 id="la-direccion-de-la-tecnologia">La dirección de la tecnología <a class="heading-anchor" href="#la-direccion-de-la-tecnologia" title="Copy link" aria-label="Link to this section">#</a> </h3> <p>Cuando propones adoptar una nueva biblioteca, framework o tecnología, hay que conocer su trasfondo y hacia dónde se dirige.</p> <p>¿Cuál es la motivación detrás de esa tecnología? ¿Por qué quieres añadirla a tu stack actual?</p> <h3 id="acoplamiento-y-dependencias">Acoplamiento y dependencias <a class="heading-anchor" href="#acoplamiento-y-dependencias" title="Copy link" aria-label="Link to this section">#</a> </h3> <p>Al adoptar nuevas tecnologías en el día a día, es fácil acoplarse a ellas. Eso hace más difícil dar marcha atrás si después nos arrepentimos.</p> <p>No me malinterpretes: aprender y experimentar con nuevas tecnologías está genial. Pero introducirlas en tu trabajo diario es otra historia. Afecta a todo el equipo, así que hay que ser cuidadosos.</p> <p><img src="/images/blog/2023-04-14/middle.webp" alt="blog-middle" /></p> <h2 id="el-enfoque-de-la-conversacion">El enfoque de la conversación <a class="heading-anchor" href="#el-enfoque-de-la-conversacion" title="Copy link" aria-label="Link to this section">#</a> </h2> <ul> <li>¿Qué aporta esta nueva tecnología al proyecto?</li> <li>¿Qué problema queremos resolver?</li> <li>¿Podemos resolverlo con nuestra tecnología actual?</li> <li>Si ya tenemos algo similar, ¿queremos mezclar ambas?</li> <li>¿Cuáles son los trade-offs de usarla vs. no usarla?</li> <li>¿Vale la pena la complejidad extra a largo plazo?</li> <li>¿Cuál es la estrategia para que todos se suban al carro?</li> </ul> <h3 id="architectural-decision-records-adrs">Architectural Decision Records (ADRs) <a class="heading-anchor" href="#architectural-decision-records-adrs" title="Copy link" aria-label="Link to this section">#</a> </h3> <p>Sea cual sea el resultado, escríbelo como un <a rel="external" href="https://adr.github.io/">ADR</a> para poder revisarlo con el tiempo. Un ADR documenta las decisiones del equipo: pros, contras y los argumentos que encontrasteis juntos para decidir qué hacer y por qué.</p> <p>Los ADRs ayudan a entender decisiones antiguas. Guárdalos en el control de versiones, en el mismo proyecto si es posible. Son útiles para el equipo actual y para los nuevos que lleguen.</p> <p><img src="/images/blog/2023-04-14/footer.webp" alt="blog-footer" /></p> <aside class="kudos"> <span class="kudos__icon" aria-hidden="true">🧠</span> <div class="kudos__content"> <p>Gracias a mis amigos <a rel="external" href="https://x.com/evrtrabajo">Manu</a>, <a rel="external" href="https://x.com/Tito_Kati">Antonio</a> y <a rel="external" href="https://x.com/JesusValera96">Jesus</a>, que me ayudaron a crear este resumen de ideas haciendo brainstorming juntos.</p> </div> </aside>2022-11-28T00:00:00+00:002022-11-28T00:00:00+00:00 Matthias Nobackhttps://chemaclass.com/es/readings/recipes-for-decoupling/

¿Qué es el acoplamiento y por qué nos perjudica? Este libro recopila estrategias prácticas para separar tu código de dominio de la infraestructura y mantener un sistema sano a largo plazo.

<span id="continue-reading"></span> <p>¿Qué es el acoplamiento y por qué nos perjudica? ¿Cómo desacoplar de forma eficiente? Este libro recopila estrategias para separar tu código de dominio de los detalles de infraestructura. El resultado: un sistema más sano a largo plazo.</p> <p>Aprenderás a crear reglas de <a rel="external" href="https://phpstan.org/"><strong>PHPStan</strong></a> desde cero. Además, el libro te guía por múltiples oportunidades de desacoplamiento:</p> <ul> <li>framework web</li> <li>frameworks cli</li> <li>validación de formularios</li> <li>orm y base de datos</li> <li>framework de testing</li> </ul> <p>Lee más sobre el libro: <a rel="external" href="https://matthiasnoback.nl/book/recipes-for-decoupling/">matthiasnoback.nl/book/recipes-for-decoupling/</a></p> <blockquote> <p>Cómpralo aquí: <a rel="external" href="https://leanpub.com/recipes-for-decoupling">leanpub.com/recipes-for-decoupling</a></p> </blockquote>Haciendo lo que funciona para construir mejor software más rápido2022-06-29T00:00:00+00:002022-06-29T00:00:00+00:00 David Farleyhttps://chemaclass.com/es/readings/modern-software-engineering/

El desarrollo de software como práctica de ingeniería real. Para dominarlo hay que ser experto en aprender y gestionar la complejidad.

<span id="continue-reading"></span> <p>El libro presenta el desarrollo de software como una práctica de ingeniería real. Para dominarlo hay que ser experto en aprender y gestionar la complejidad.</p> <h3 id="optimizar-para-aprender">Optimizar para aprender <a class="heading-anchor" href="#optimizar-para-aprender" title="Copy link" aria-label="Link to this section">#</a> </h3> <p>El libro presenta cinco comportamientos clave para aprender mejor:</p> <ul> <li>Trabajar de forma iterativa</li> <li>Buscar feedback</li> <li>Incrementalismo</li> <li>Empirismo</li> <li>Ser experimental</li> </ul> <p>La idea central: trabajar en pasos pequeños, recoger feedback y ajustar.</p> <h3 id="optimizar-para-gestionar-la-complejidad">Optimizar para gestionar la complejidad <a class="heading-anchor" href="#optimizar-para-gestionar-la-complejidad" title="Copy link" aria-label="Link to this section">#</a> </h3> <p>Cinco ideas para manejar la complejidad:</p> <ul> <li>Modularidad</li> <li>Cohesión</li> <li>Separación de responsabilidades</li> <li>Ocultación de información y abstracción</li> <li>Gestión del acoplamiento</li> </ul> <p>Gestionar la complejidad de nuestros sistemas es fundamental.</p> <h3 id="herramientas-para-apoyar-la-ingenieria">Herramientas para apoyar la ingeniería <a class="heading-anchor" href="#herramientas-para-apoyar-la-ingenieria" title="Copy link" aria-label="Link to this section">#</a> </h3> <p>El libro profundiza en ideas como:</p> <ul> <li>Testeabilidad</li> <li>Desplegabilidad</li> <li>Control de variables</li> <li>Entrega continua</li> </ul> <hr /> <p>Un vídeo donde el autor explica las ideas principales del libro:</p> <div style="position:relative;aspect-ratio:16/9;width:100%;"> <iframe src="https://www.youtube-nocookie.com/embed/TRqYQnCfgH8" title="YouTube video" width="560" height="315" loading="lazy" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;inset:0;width:100%;height:100%;border:0;" allowfullscreen> </iframe> </div>Organizando equipos de negocio y tecnología para flujo rápido2022-03-31T00:00:00+00:002022-03-31T00:00:00+00:00 Matthew Skelton Manuel Paishttps://chemaclass.com/es/readings/team-topologies/

Cómo estructurar equipos dinámicos e interacciones que permitan adaptarse rápido a nuevas condiciones y entregar software de forma ágil y segura.

<span id="continue-reading"></span> <p>El libro explica cómo estructurar equipos dinámicos y sus interacciones para adaptarse rápido a nuevas condiciones y entregar software de forma ágil y segura.</p> <h2 id="estructura-de-equipo">Estructura de equipo <a class="heading-anchor" href="#estructura-de-equipo" title="Copy link" aria-label="Link to this section">#</a> </h2> <ul> <li>Alta cohesión: agrupa las cosas relacionadas.</li> <li>Bajo acoplamiento: límites claros entre equipos.</li> <li>Carga cognitiva: es como la RAM del equipo. Si lo sobrecargas, se quema.</li> </ul> <blockquote> <p>Para evitar cuellos de botella, asegúrate de que la carga cognitiva del equipo no sea excesiva.</p> </blockquote> <h2 id="ley-de-conway">Ley de Conway <a class="heading-anchor" href="#ley-de-conway" title="Copy link" aria-label="Link to this section">#</a> </h2> <ul> <li>La estructura organizacional influye en la arquitectura del software.</li> <li>Las organizaciones diseñan sistemas que copian su estructura de comunicación.</li> <li>Resultado: nadie se enfoca en la arquitectura óptima para el proyecto.</li> <li>Primero define la arquitectura, luego forma los equipos.</li> </ul> <h2 id="el-equipo-primero">El equipo primero <a class="heading-anchor" href="#el-equipo-primero" title="Copy link" aria-label="Link to this section">#</a> </h2> <ul> <li>Quién está en el equipo importa menos que su dinámica.</li> <li>Al medir rendimiento, el equipo importa más que las personas individuales.</li> <li>Equipo = grupo de 5-9 personas trabajando hacia metas compartidas. <ul> <li>Ver el <a href="/es/blog/dunbar-number/">número de Dunbar</a>.</li> </ul> </li> <li>Formar un equipo toma de 2 semanas a 3 meses.</li> <li>La carga cognitiva es el esfuerzo mental total usado en la memoria de trabajo.</li> <li>3 tipos de carga cognitiva: <ul> <li>Intrínseca: fundamentos del problema. Ej: lenguaje de programación.</li> <li>Extrínseca: relacionada con el entorno. Ej: cómo desplegar.</li> <li>Germane: requiere atención especial. Ej: dominio de negocio.</li> </ul> </li> <li>Heurísticas: <ul> <li>3 tipos de dominio: simple, complicado, complejo.</li> <li>Si el dominio es muy grande, divídelo en subdominios.</li> <li>Un equipo puede manejar: <ul> <li>2-3 dominios simples.</li> <li>1 dominio complejo.</li> <li>Evita 2 dominios complicados; mejor divide el equipo.</li> </ul> </li> </ul> </li> <li>Define una API de equipo: <ul> <li>Código: endpoints, librerías, clientes…</li> <li>Versionado.</li> <li>Documentación.</li> <li>Prácticas y principios.</li> <li>Herramientas de comunicación.</li> </ul> </li> </ul> <h2 id="topologias-de-equipo">Topologías de equipo <a class="heading-anchor" href="#topologias-de-equipo" title="Copy link" aria-label="Link to this section">#</a> </h2> <blockquote> <p>Organiza equipos por áreas de dominio de negocio, no por conocimiento técnico o actividades.</p> </blockquote> <ul> <li>El éxito depende tanto de los miembros como del entorno, otros equipos e interacciones.</li> <li>Divide responsabilidades para romper silos.</li> <li>Tipos de dependencias: conocimiento, tarea y recurso.</li> <li>Cuatro tipos de equipos: <ul> <li>Stream-aligned: entregar funcionalidades y productos al mercado cuanto antes.</li> <li>Enabling: desarrollar capacidades para los equipos stream-aligned.</li> <li>Complicated-subsystem: reducir la carga cognitiva de los equipos stream-aligned.</li> <li>Platform: dar autonomía a los equipos stream-aligned.</li> </ul> </li> </ul> <h2 id="interacciones-de-equipo">Interacciones de equipo <a class="heading-anchor" href="#interacciones-de-equipo" title="Copy link" aria-label="Link to this section">#</a> </h2> <ul> <li>Colaboración: trabajo cercano entre equipos con distintas habilidades.</li> <li>X-as-a-Service: propiedad clara, baja carga cognitiva.</li> <li>Facilitación: eliminar impedimentos y mejorar la calidad de las interacciones entre equipos.</li> </ul>Cómo crear componentes de software reutilizables2020-11-12T00:00:00+00:002020-11-12T00:00:00+00:00 Matthias Nobackhttps://chemaclass.com/es/readings/packaging-design/

Cómo crear paquetes con la cohesión y el acoplamiento justos, útiles tanto para usuarios como mantenedores

<span id="continue-reading"></span> <p>Aprende a aplicar principios de diseño a tus clases para que sean reutilizables. El libro te enseña a crear paquetes con la cohesión y acoplamiento adecuados, pensados para usuarios y mantenedores.</p> <p>La primera parte cubre los cinco principios SOLID para mejorar el diseño de clases. La segunda parte entra en las mejores prácticas de diseño de paquetes: principios de cohesión y de acoplamiento.</p> <p>Los principios de cohesión te dicen qué clases van juntas, cuándo dividir un paquete, y cuándo un grupo de clases puede llamarse “paquete”. Los de acoplamiento te ayudan a elegir bien las dependencias y evitar ciclos en el grafo de dependencias.</p> <h3 id="lo-que-aprenderas">Lo que aprenderás <a class="heading-anchor" href="#lo-que-aprenderas" title="Copy link" aria-label="Link to this section">#</a> </h3> <ul> <li>Aplicar los principios SOLID</li> <li>Decidir si las clases pertenecen al mismo paquete</li> <li>Saber cuándo un paquete puede depender de otro</li> </ul>DDD explicado de forma clara y práctica2020-09-10T00:00:00+00:002020-09-10T00:00:00+00:00 Vaughn Vernonhttps://chemaclass.com/es/readings/domain-driven-design-distilled/

Una introducción accesible a DDD para desarrolladores, consultores y cualquiera que quiera entender el diseño guiado por dominio

<p>Este libro hace que DDD cobre vida. Da igual si eres desarrollador, consultor o cliente: te ayuda a entenderlo y sacarle provecho.</p> <span id="continue-reading"></span> <hr /> <p>Desarrolladores de todo el mundo lo están adoptando porque da resultados reales. Es una guía accesible que responde:</p> <ul> <li>¿Qué es DDD?</li> <li>¿Qué problemas resuelve?</li> <li>¿Cómo funciona?</li> <li>¿Cómo sacarle valor rápido?</li> </ul> <p>Aprenderás a separar modelos de dominio con <strong>Contextos Acotados</strong> (Bounded Contexts), a desarrollar un <strong>Lenguaje Ubicuo</strong> dentro de cada contexto, y a lograr que <strong>expertos de dominio</strong> y <strong>desarrolladores</strong> colaboren para crear ese lenguaje.</p> <p>También cubre cómo usar Subdominios para manejar sistemas legacy e integrar varios Contextos Acotados definiendo relaciones entre equipos.</p> <blockquote> <p>Domain-Driven Design Distilled da vida a <strong>DDD</strong>.</p> </blockquote>La guía que lleva tus habilidades de código al siguiente nivel2020-08-16T00:00:00+00:002020-08-16T00:00:00+00:00 Matthias Nobackhttps://chemaclass.com/es/readings/advance-web-application-architecture/

Cómo desacoplar tu aplicación del framework y la base de datos con PHP moderno y diseño modular

<p>Este libro te ayuda a poner en forma tus aplicaciones web. Trae muchas técnicas para desacoplar tu código de la infraestructura (el framework, la base de datos, etc.).</p> <span id="continue-reading"></span> <p>La Parte 1 presenta patrones de diseño para separar código de negocio e infraestructura. La Parte 2 muestra cómo estos patrones encajan con conceptos arquitectónicos como capas, puertos y adaptadores (arquitectura Hexagonal). El libro cierra con estrategias de testing y decisiones de diseño.</p> <h3 id="lo-que-aprenderas">Lo que aprenderás <a class="heading-anchor" href="#lo-que-aprenderas" title="Copy link" aria-label="Link to this section">#</a> </h3> <ul> <li>Separar código mezclado en código de negocio e infraestructura usando patrones.</li> <li>Dividir tu código en capas con una distinción clara entre puertos y adaptadores.</li> <li>Testear aplicaciones desacopladas.</li> </ul> <blockquote> <p>Compra el libro: <a rel="external" href="https://leanpub.com/web-application-architecture">https://leanpub.com/web-application-architecture</a></p> </blockquote> <hr /> <h3 id="patrones-de-diseno-para-modernizar-codigo-legacy">Patrones de diseño para modernizar código legacy <a class="heading-anchor" href="#patrones-de-diseno-para-modernizar-codigo-legacy" title="Copy link" aria-label="Link to this section">#</a> </h3> <div style="position:relative;aspect-ratio:16/9;width:100%;"> <iframe src="https://www.youtube-nocookie.com/embed/WI1QY6OMglE" title="YouTube video" width="560" height="315" loading="lazy" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" referrerpolicy="strict-origin-when-cross-origin" style="position:absolute;inset:0;width:100%;height:100%;border:0;" allowfullscreen> </iframe> </div>Symfony 5: La Vía Rápida2020-02-20T00:00:00+00:002020-02-20T00:00:00+00:00 Fabien Potencierhttps://chemaclass.com/es/readings/symfony-5/

Una guía práctica del creador de Symfony para desarrollar aplicaciones web desde cero hasta producción.

<span id="continue-reading"></span> <p>Escrito por el creador de Symfony, este libro presenta un enfoque práctico para desarrollar aplicaciones web con Symfony 5: desde cero hasta producción. Si estás descubriendo Symfony por primera vez o quieres refrescar tus conocimientos, esta guía te da una introducción completa a las aplicaciones modernas con Symfony.</p>Guía del artesano para la estructura y diseño de software2018-06-04T00:00:00+00:002018-06-04T00:00:00+00:00 Robert C. Martinhttps://chemaclass.com/es/readings/clean-architecture/

Cómo estructurar y diseñar software de forma profesional. Principios SOLID, componentes y capas explicados con claridad.

<span id="continue-reading"></span><h3 id="principios-de-diseno-de-codigo-solid">Principios de diseño de código (SOLID) <a class="heading-anchor" href="#principios-de-diseno-de-codigo-solid" title="Copy link" aria-label="Link to this section">#</a> </h3> <ul> <li><strong>Responsabilidad Única</strong>: una clase debe tener una sola razón para cambiar. O en su versión nueva: un módulo responde ante un solo actor.</li> <li><strong>Abierto-cerrado</strong>: abierta para extensión, cerrada para modificación.</li> <li><strong>Sustitución de Liskov</strong>: puedes reemplazar objetos por instancias de sus subtipos sin romper el programa.</li> <li><strong>Segregación de Interfaces</strong>: mejor muchas interfaces específicas que una general.</li> <li><strong>Inversión de Dependencias</strong>: depende de abstracciones, no de implementaciones concretas.</li> </ul> <h3 id="principios-de-componentes">Principios de componentes <a class="heading-anchor" href="#principios-de-componentes" title="Copy link" aria-label="Link to this section">#</a> </h3> <h4 id="cohesion-de-componentes">Cohesión de componentes <a class="heading-anchor" href="#cohesion-de-componentes" title="Copy link" aria-label="Link to this section">#</a> </h4> <ul> <li><strong>Equivalencia Reutilización/Liberación</strong>: las clases reutilizadas juntas deben liberarse juntas. Mismo número de versión y changelog adecuado.</li> <li><strong>Cierre Común</strong>: las clases que cambian juntas van juntas. Es el principio de responsabilidad única a nivel de componente.</li> <li><strong>Reutilización Común</strong>: no obligues a los usuarios a depender de lo que no necesitan. Segregación de interfaces a nivel de componente.</li> </ul> <h4 id="acoplamiento-de-componentes">Acoplamiento de componentes <a class="heading-anchor" href="#acoplamiento-de-componentes" title="Copy link" aria-label="Link to this section">#</a> </h4> <ul> <li><strong>Dependencias Acíclicas</strong>: sin ciclos en el grafo de dependencias. Los ciclos fuerzan a liberar componentes juntos. Usa inversión de dependencias para romperlos.</li> <li><strong>Dependencia Estable</strong>: los componentes menos estables dependen de los más estables. Depende en dirección de la estabilidad.</li> <li><strong>Abstracciones Estables</strong>: los componentes estables deben ser abstractos. Ejemplo: una política de alto nivel que se extiende siguiendo abierto-cerrado.</li> </ul> <h3 id="principios-de-arquitectura">Principios de arquitectura <a class="heading-anchor" href="#principios-de-arquitectura" title="Copy link" aria-label="Link to this section">#</a> </h3> <h4 id="estableciendo-limites">Estableciendo límites <a class="heading-anchor" href="#estableciendo-limites" title="Copy link" aria-label="Link to this section">#</a> </h4> <p>Los límites separan elementos de software: lo que importa de lo que no, lo de alto nivel de lo de bajo nivel. Si el código de alto nivel depende del de bajo nivel, los cambios se propagan hacia arriba. Ponemos un límite usando polimorfismo para invertir el flujo. Esto es el Principio de Inversión de Dependencias de SOLID.</p> <h4 id="separando-capas">Separando capas <a class="heading-anchor" href="#separando-capas" title="Copy link" aria-label="Link to this section">#</a> </h4> <p>Cuatro capas principales (aunque puede variar):</p> <ul> <li><strong>Entidades</strong>: objetos con lógica de negocio crítica. Ejemplo: un banco que no da préstamos a clientes sin cierta puntuación crediticia. Se comparten entre aplicaciones de la empresa.</li> <li><strong>Casos de uso</strong>: reglas de negocio específicas de la aplicación. Ejemplo: la secuencia de pantallas para hacer una transferencia.</li> <li><strong>Adaptadores de interfaz</strong>: gateways, presenters, controllers. Aquí va la arquitectura MVC de la GUI y la transformación de datos entre base de datos y casos de uso.</li> <li><strong>Frameworks y drivers</strong>: frameworks web, base de datos, la vista de MVC.</li> </ul>