Herramientas que estan de acuerdo entre si

¿Por qué importa que tu formateador y tu analizador estático coincidan entre repositorios? Porque en cuanto no lo hacen, cada persona tiene que recordar en qué repositorio está antes de fiarse de la herramienta.

Pint acierta en esto en toda la flota: api-license, api-server y merchants llevan el mismo pint.json idéntico.

// pint.json
{
    "preset": "laravel",
    "rules": {
        "declare_strict_types": true,
        "class_attributes_separation": {
            "elements": {
                "const": "none",
                "property": "none",
                "method": "one",
                "trait_import": "none"
            }
        }
    }
}

Ejecuta vendor/bin/pint en cualquiera de ellos y obtienes las mismas decisiones de formato. Quien ha arreglado una queja de Pint en un repositorio la ha arreglado en todos, porque la configuración no cambió bajo sus pies.

PHPStan es el contraejemplo honesto, y merece decirse claramente en lugar de fingir que no está ahí. api-license y api-server corren a nivel 9. merchants corre a nivel 5, con su propia lista de patrones de error ignorados. El mismo analizador, la misma flota, dos listones distintos de qué cuenta como limpio. merchants es una aplicación más grande y más antigua y api-license es un servicio hoja pequeño, así que la brecha tiene razón de ser, pero quien se mueve entre repositorios sigue sin poder asumir que el silencio significa lo mismo en todas partes.

Las herramientas consistentes no son un lujo. Son lo que permite a alguien fiarse de una marca verde sin volver a deducir qué verificó exactamente esa marca.

Revisar codigo sin rediscutir el estilo

Lo que mata la velocidad de las revisiones más rápido que el código malo: código bueno que desata una discusión sobre formato.

composer run format   # ./vendor/bin/pint
composer run check    # ./vendor/bin/phpstan analyse --memory-limit=2G
composer run test     # ./vendor/bin/pest

Tres comandos, ejecutados antes de pedirle a nadie que mire tu diff. Pint decide espaciado y colocación de llaves. PHPStan decide si los tipos se sostienen. Pest, incluido ArchTest.php, decide si el cambio sigue las convenciones estructurales. Nada de eso necesita un ojo humano.

Lo que queda para quien revisa es lo único que una persona debería revisar: ¿esto resuelve el problema correcto y la lógica hace lo que dice? Quien gasta atención en el ancho de tabulación en lugar de en la lógica no está siendo cuidadoso: está gastando un recurso escaso en algo que una máquina ya comprobó gratis.

Repaso

• [X] Primera hora: un README con recuentos de rutas y pruebas que quien llega puede verificar, no prosa en la que tiene que confiar
• [X] Instalación: un comando, no una lista que alguien hará a medias
• [X] Convenciones: impuestas por pruebas arch(), no sólo descritas en un comentario que alguien dejó de leer
• [X] Documentación: regenerada, no mantenida a mano hasta que se desvía
• [X] Errores: cada rama responde qué pasó y qué hacer al respecto
• [X] Herramientas: el mismo pint.json en todas partes; la brecha de nivel de PHPStan es una deuda conocida, no oculta
• [X] Revisiones: formato, comprobación y pruebas se ejecutan antes de que una persona abra el diff

Una base de código con buena experiencia de desarrollo no necesita que le cuenten a nadie cómo funciona. Se lo cuenta ella sola, en la primera hora, y sigue diciéndole la verdad cada hora después.