Saltar al contenido
Curso Claude Code en equipo: una sola forma de trabajar
21/29 Bloque opcional · El paquete Composer de convenciones De la corrección a la convención: publicar un doc y su arch test en la misma versión del paquete
Tu lectura Quedan 24 min
Lección 21 de 29 · Bloque opcional · El paquete Composer de convenciones

De la corrección a la convención: publicar un doc y su arch test en la misma versión del paquete

24 min de lectura Claude Code 2.1

Hola, bienvenido. En esta lección vamos a convertir una corrección que se repite en las revisiones de código en una convención del equipo. Vamos a escribirla en el documento de modelos del paquete, añadir el arch test que la comprueba y publicar los 2 en la misma versión, la 1.4.0. Después vamos a actualizar helpdesk, que no la cumple, y a corregirlo en su propia pull request.

Jorge lleva 3 revisiones de código escribiendo el mismo comentario: "los traits, en el Base". Los modelos del equipo se organizan en capas, y la Base abstracta guarda la configuración de Eloquent. Para Jorge, los traits del modelo, como HasFactory o Notifiable, también tienen que estar en la Base, y el modelo final no usa ninguno. Pero eso no está escrito en el documento de modelos. Está en la auto memory de Jorge y en la de Aitor, que lo aprendió a base de correcciones, así que Claude solo lo tiene en cuenta en sus sesiones. Las de Marta y Lucía no lo saben, y cada pull request que toca un modelo vuelve a recibir el comentario de Jorge.

Esa corrección ya es una regla del equipo, solo que no está escrita donde la lee todo el mundo. Vamos a llevarla al paquete de convenciones, con el mismo orden que seguiremos con cualquier convención nueva.

El orden: documento, arch test y código

Una convención nueva se publica siempre en este orden:

  1. El documento. Es lo que leen las personas y lo que lee Claude: la guideline que importa CLAUDE.md remite a él, y la rule de modelos le pide a Claude que lo lea cuando toca uno.
  2. El arch test. Convierte la regla escrita en algo que composer qa comprueba en cada repo, sin que nadie tenga que acordarse. Se publica en la misma versión del paquete que el documento, así que un repo que actualiza recibe las 2 cosas a la vez, nunca una sin la otra.
  3. El código. Cada repo actualiza el paquete en su propia pull request, y su QA le dice qué tiene que cambiar.
Diagrama del ciclo de una versión del paquete en 4 pasos que se repiten: escribir la convención, añadir su arch test, publicar la versión, destacado, y actualizar cada repo

El paso destacado es el que hace llegar la convención a todos los repos: hasta que no hay versión publicada, el documento y el test solo existen en la rama de quien los ha escrito.

Lo que queda de esta lección
  1. 02La convención en el documento de modelos
  2. 03El arch test de la convención
  3. 04La 1.4.0 del paquete
  4. 05helpdesk actualiza el paquete
  5. 06User y su Base
  6. 07helpdesk pide la 1.4
  7. 08Volver a la versión anterior del paquete
Sigue leyendo con tu suscripción El curso completo, con su proyecto final, el certificado y el foro, está incluido en la suscripción. Ver los planes