Cuando te enfrentas a un nuevo código base, es tentador sumergirte directamente en los archivos. Sin embargo, Ally Piechowski, un experto en el campo, propone un enfoque diferente: ejecutar una serie de comandos Git antes de siquiera abrir un archivo. Este método proporciona una visión general del proyecto, revelando patrones y riesgos potenciales que de otra manera podrían pasar desapercibidos.
¿Cómo funciona? La técnica se basa en analizar el historial de commits de Git. El primer comando (git log --format=format: --name-only --since="1 year ago" ...) identifica los archivos con mayor actividad (churn). Un alto churn no siempre es negativo, pero cuando se combina con una falta de propiedad o una historia de parches sobre parches, indica una zona problemática. Un estudio de Microsoft Research confirma que las métricas de churn son predictivas de defectos. El segundo comando (git shortlog -sn --no-merges) revela la distribución de contribuciones, lo que permite identificar un posible 'bus factor' (dependencia crítica en un único desarrollador). Un bus factor alto, especialmente si el desarrollador clave ya no está, es una señal de alerta. El tercer comando (git log -i -E --grep="fix|bug|broken" ...) busca commits relacionados con correcciones de errores, comparando los resultados con los archivos de alto churn para identificar los puntos más críticos.
¿Para qué sirve? Estos comandos son valiosos para desarrolladores, arquitectos de software, líderes técnicos y consultores que se unen a nuevos proyectos o realizan auditorías de código. Permiten una evaluación rápida y objetiva de la salud del código, identificando áreas de riesgo, cuellos de botella y posibles problemas de mantenimiento. Por ejemplo, si un archivo tiene un alto churn y también está asociado con muchos errores, es probable que sea una prioridad para la refactorización.
Consideraciones: Es importante tener en cuenta que la precisión de estos comandos depende de la disciplina del equipo al escribir mensajes de commit descriptivos. El uso de 'squash merges' puede distorsionar la información sobre la autoría. Además, estos comandos proporcionan una instantánea, no una solución completa. Son un punto de partida para una investigación más profunda y deben complementarse con una revisión manual del código. Finalmente, la interpretación de los resultados requiere experiencia y contexto; un alto churn podría ser indicativo de un desarrollo activo y no necesariamente de un problema.