De la corrección a la convención: publicar un doc y su arch test en la misma versión del paquete
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:
- El documento. Es lo que leen las personas y lo que lee Claude: la guideline que importa
CLAUDE.mdremite a él, y la rule de modelos le pide a Claude que lo lea cuando toca uno. - El arch test. Convierte la regla escrita en algo que
composer qacomprueba 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. - El código. Cada repo actualiza el paquete en su propia pull request, y su QA le dice qué tiene que cambiar.
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.
- 02La convención en el documento de modelos
- 03El arch test de la convención
- 04La 1.4.0 del paquete
- 05helpdesk actualiza el paquete
- 06User y su Base
- 07helpdesk pide la 1.4
- 08Volver a la versión anterior del paquete