[{"data":1,"prerenderedAt":115},["ShallowReactive",2],{"blog:es:how-we-agree-on-a-shape":3},{"id":4,"title":5,"author":6,"body":7,"date":101,"description":102,"extension":103,"meta":104,"navigation":105,"path":106,"publishAt":101,"seo":107,"stem":108,"tags":109,"__hash__":114},"blog_es\u002Fblog\u002Fhow-we-agree-on-a-shape\u002Fes.md","Cómo acordamos una forma antes de construirla","Aptli",{"type":8,"value":9,"toc":91},"minimark",[10,15,19,22,26,29,32,36,39,42,45,49,52,55,59,62,65,69],[11,12,14],"h2",{"id":13},"dónde-lo-dejamos","Dónde lo dejamos",[16,17,18],"p",{},"Hace unas semanas escribimos sobre cómo nuestro frontend obtiene los mismos patrones de diseño que reconocería un desarrollador de Java a partir de tablas y composables, casi sin ninguna clase por ningún lado. La conversación al respecto no terminó al publicarlo. Dentro del equipo siguió, porque ese texto tocaba algo más grande que cualquier patrón individual: teníamos un nombre para cada una de esas formas, y todos ya sabían qué significaba ese nombre antes de que empezara la conversación.",[16,20,21],{},"Esa costumbre merece una explicación propia, al margen de cualquier patrón concreto. Hace tiempo, alguien decidió que merecía la pena dedicar tiempo a dar nombre a una figura y anotarla, y el equipo ha seguido haciéndolo desde entonces.",[11,23,25],{"id":24},"qué-se-aprende-en-un-tutorial","Qué se aprende en un tutorial",[16,27,28],{},"Las bibliotecas de componentes son una comodidad real. Traes una, y un selector de fechas o un desplegable que funciona llega ya construido, probado por mucho más uso del que cualquier equipo por sí solo podría darle. Un fragmento de código ahorra los diez minutos que toma recordar la sintaxis exacta de algo que se hace tan poco que se olvida. Un tutorial suele ser la forma más rápida de aprender de verdad una técnica, porque recorre el razonamiento detrás de ella.",[16,30,31],{},"Todo eso resulta útil y está dirigido a una sola persona, que aprende una técnica en una sola sesión. Un equipo se plantea una segunda pregunta: a qué debería recurrir un grupo de personas, la mayoría de las cuales no escribieron el código original, la próxima vez que se plantee el mismo tipo de decisión. Esa respuesta corresponde al equipo.",[11,33,35],{"id":34},"la-práctica-real","La práctica real",[16,37,38],{},"Así es, más o menos, como nos pasa a nosotros. Alguien nota que la misma forma de problema aparece por segunda o tercera vez, normalmente mientras revisa un pull request que lo resuelve un poco distinto de como se resolvió la última vez. Le pone nombre a la forma en la conversación, en el propio comentario de la revisión. Si el nombre sobrevive a usarse unas veces más, se escribe: qué es la forma, cuándo aplica, y un ejemplo corto que ya está en el código.",[16,40,41],{},"La lista escrita es breve a propósito y recoge los patrones que utiliza el equipo. Su finalidad es que una decisión de diseño pueda resumirse en una sola frase. Cuando alguien escribe «conviértalo en un registro» en una revisión, todos los que leen el comentario saben ya a qué patrón se refiere, sin necesidad de diagramas ni reuniones.",[16,43,44],{},"Otro ámbito en el que resulta útil es durante la primera semana de un ingeniero recién incorporado. Al leer la lista, aprenden las pocas estructuras que utiliza el código fuente, tal y como las describe el propio equipo. Una guía de estilo explica cómo dar formato a una línea de código. Esta lista, por su parte, aborda cómo plantearse una decisión antes de escribir esa línea.",[11,46,48],{"id":47},"por-qué-nos-molestamos-en-hacerlo","Por qué nos molestamos en hacerlo",[16,50,51],{},"Dar nombre a una estructura requiere una conversación, y plasmarlo por escrito le lleva tiempo a alguien, algo que hay que revisar a medida que cambia el código. La ventaja es precisamente la que defiende directamente el libro que mencionamos la última vez: un nombre compartido permite tomar rápidamente una buena decisión y hace visible una mala decisión cuando aún es solo una idea, antes de que se convierta en una solicitud de incorporación de cambios que haya que deshacer.",[16,53,54],{},"El motor de notificaciones que describimos la vez pasada, todavía en unas cuarenta líneas tras cada adición, se sostuvo exactamente por esta razón. La forma ya tenía nombre antes de que llegara la cuarta o quinta notificación. Agregar una después no requirió deliberación.",[11,56,58],{"id":57},"la-parte-humana-de-una-decisión-arquitectónica","La parte humana de una decisión arquitectónica",[16,60,61],{},"Se trata, ante todo, de una forma en que un grupo de personas llega a acuerdos, más que de una práctica de programación. Un equipo toma decisiones, revisión a revisión y conversación a conversación, y la lista recoge dichas decisiones una vez que se han tomado. Cada decisión se toma una sola vez.",[16,63,64],{},"Eso vale igual si el lenguaje es Java o JavaScript, y si el equipo tiene cinco personas o cincuenta. La forma en el código sigue a la forma en que las personas que lo construyen hablan entre sí sobre él, y esa segunda parte es a la que le dedicamos la atención más deliberada.",[11,66,68],{"id":67},"resumen","Resumen",[70,71,72,76,79,82,85,88],"ul",{},[73,74,75],"li",{},"Las bibliotecas de componentes, los fragmentos de código y los tutoriales le enseñan cada uno una técnica a una persona en una sola sesión. Un vocabulario compartido para una forma de diseño vive entre las personas de un equipo, y lo usa todo el mundo a la vez.",[73,77,78],{},"La práctica, en concreto: un nombre propuesto en un comentario de revisión, probado contra unos cuantos casos reales más, y luego escrito con qué es, cuándo aplica, y un ejemplo corto que ya está en el código.",[73,80,81],{},"La lista escrita se mantiene corta a propósito. Existe para que una decisión de diseño pueda ser una frase.",[73,83,84],{},"Un desarrollador nuevo lee la lista en su primera semana. Aprende las formas que el código realmente usa, con las palabras del propio equipo, sin tener que armarlas a partir del código viejo.",[73,86,87],{},"La ganancia es la misma que plantea el libro detrás de nuestro texto anterior: un nombre compartido hace que una buena decisión sea rápida, y una mala decisión visible mientras todavía es una frase.",[73,89,90],{},"Esto es una costumbre organizacional antes que una costumbre de código. Un equipo se pone de acuerdo en las cosas, una conversación a la vez, y la lista es donde esos acuerdos quedan guardados.",{"title":92,"searchDepth":93,"depth":93,"links":94},"",2,[95,96,97,98,99,100],{"id":13,"depth":93,"text":14},{"id":24,"depth":93,"text":25},{"id":34,"depth":93,"text":35},{"id":47,"depth":93,"text":48},{"id":57,"depth":93,"text":58},{"id":67,"depth":93,"text":68},"2026-09-16","Hace unas semanas escribimos sobre cómo los patrones de diseño aparecen en nuestro código sin clases. La conversación dentro de nuestro propio equipo no terminó al publicarlo. Esta es la costumbre que hay debajo de todo eso, y por qué la tratamos como trabajo deliberado.","md",{},true,"\u002Fblog\u002Fhow-we-agree-on-a-shape\u002Fes",{"title":5,"description":102},"blog\u002Fhow-we-agree-on-a-shape\u002Fes",[110,111,112,113],"engineering","how-we-work","design-patterns","team-alignment","4Jr7zpzKzQhZfCviUPk2xc-dSgG5R7QQg_nNMzRdIaI",1791936518944]