Comandos de Git para ejecutar antes de leer el código

 (piechowski.io)
89 puntos por GN⁺ 21 일 전 | 1 comentarios | Compartir por WhatsApp
  • Al abordar una base de código nueva, analiza el historial de Git para entender la estructura del proyecto y las zonas de riesgo y así definir una dirección de exploración más eficiente
  • Encuentra los archivos modificados con mayor frecuencia durante el último año y cruza la frecuencia de cambios con la concentración de bugs para identificar código de alto riesgo
  • Revisa la distribución de contribuyentes y las tendencias de actividad para evaluar el bus factor, vacíos de mantenimiento y posibles quiebres de conocimiento
  • Usa la cantidad de commits por mes para seguir los cambios en la velocidad y el impulso de desarrollo del equipo, y evalúa la estabilidad de despliegue con la frecuencia de Revert y Hotfix
  • Estos cinco comandos pueden usarse como herramientas prácticas para diagnosticar rápidamente el estado de salud del proyecto antes de abrir una sola línea de código

Cinco comandos de Git para ejecutar antes de leer el código

  • Al analizar una base de código nueva, se propone un enfoque para diagnosticar la salud del proyecto con el historial de Git antes de abrir archivos
    • A través del historial de commits se puede entender quién lo construyó, dónde se concentran los problemas y qué tan estable despliega el equipo

  • ¿Qué es lo que cambia con más frecuencia?

    • Comando: 
      git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20
    • Muestra los 20 archivos más modificados en el último año
    • Los archivos del ranking suelen ser aquellos que el equipo “teme tocar”; cuando se combinan una alta frecuencia de cambios (churn) y la evasión de propiedad, se convierten en la mayor carga de la base de código
    • Según una investigación de Microsoft Research (2005), las métricas basadas en frecuencia de cambios predicen mejor los defectos que las métricas de complejidad
    • Si cruzas los 5 archivos principales con el comando de concentración de bugs, puedes identificar como mayor riesgo los archivos que cambian mucho y también fallan mucho

  • ¿Quién construyó este código?

    • Comando: 
      git shortlog -sn --no-merges
    • Ordena a los contribuyentes según la cantidad de commits
    • Si una sola persona concentra más del 60%, existe riesgo de bus factor
    • Si el principal contribuyente no ha tenido actividad en los últimos 6 meses, puede haber un vacío de mantenimiento
    • Si de 30 contribuyentes solo 3 han estado activos durante el último año, puede haberse producido una ruptura de conocimiento por rotación de desarrolladores
    • Sin embargo, en equipos que usan estrategia de squash-merge, la información de autoría puede quedar sesgada hacia quien hace el merge, así que es necesario revisar la estrategia de fusión

  • ¿Dónde se concentran los bugs?

    • Comando: 
      git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20
    • Extrae los 20 archivos principales donde aparecen bugs basándose en commits con palabras clave relacionadas con errores
    • Al comparar esta lista con la de frecuencia de cambios, se puede identificar como código de alto riesgo a los archivos que se corrigen seguido y se rompen seguido
    • La precisión del resultado depende de la calidad de los mensajes de commit, pero incluso como mapa aproximado de densidad de bugs ya resulta muy útil

  • ¿El proyecto está acelerando o estancándose?

    • Comando: 
      git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c
    • Permite entender visualmente la tendencia de actividad a partir de la cantidad de commits por mes
    • Un ritmo constante suele indicar un proyecto saludable
    • Si en un solo mes la cantidad de commits se reduce a la mitad, podría haber habido salida de personal clave
    • Una disminución sostenida durante 6 a 12 meses sugiere pérdida de impulso del equipo, mientras que picos periódicos seguidos de estancamiento apuntan a un patrón de releases por lotes
    • En un caso real, un gráfico de velocidad de commits permitió que un CTO reconociera: “ese fue el momento en que se fue un ingeniero senior”
    • Estos datos tienen valor como datos del equipo, no del código

  • ¿Con qué frecuencia el equipo está respondiendo a emergencias?

    • Comando: 
      git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'
    • Mide la frecuencia de Revert y Hotfix
    • Unos pocos casos al año son normales, pero si ocurre cada dos semanas, es señal de desconfianza en el proceso de despliegue
    • Esto puede ser indicio de problemas más profundos, como tests inestables, ausencia de staging o procedimientos de rollback complejos
    • Si el resultado es 0, puede significar que el equipo es estable o que los mensajes de commit no reflejan bien la situación
    • Los patrones de crisis se hacen visibles con claridad, y su sola presencia ya permite juzgar el nivel de confiabilidad

Conclusión

  • Estos cinco comandos pueden ejecutarse en pocos minutos y, antes de abrir una sola línea de código, indican por dónde conviene empezar a leer
  • Así, en lugar de explorar a ciegas durante el primer día, es posible hacer un análisis sistemático del código centrado en las zonas problemáticas
  • Este procedimiento corresponde a la primera hora de una auditoría de base de código (codebase audit) y luego se extiende a un proceso de análisis de una semana

Lecturas relacionadas

1 comentarios

 
GN⁺ 21 일 전
Opiniones en Hacker News

  • Comparten ejemplos de cómo reemplazar comandos de análisis de git con Jujutsu
    Con jj log se puede ver cuáles fueron los archivos que más cambiaron en el último año, los principales contribuidores, dónde se concentran los bugs, la vitalidad del proyecto y la frecuencia de correcciones urgentes
    La sintaxis se parece más a programar que a escribir scripts de shell, pero hay menos flags que memorizar

    • Para mí, jujutsu se siente como el Nix de los sistemas de control de versiones
      Así como Nix es genial pero agrega complejidad, jujutsu me dio una sensación parecida
      Lo usé unos meses y luego volví a git. git ya lo tengo incorporado y se usa en todas partes
    • No entiendo cómo la gente logra memorizar todos estos lenguajes de scripting personalizados
      Ya me doy por satisfecho si recuerdo cómo iterar arreglos en jq, así que con estas sintaxis no conecto para nada
    • Tanto los comandos de jj como los de git son demasiado largos y complejos como para memorizarlos
      Si fuera algo de uso frecuente, mejor lo acortaría con alias
    • Que no haya commits no significa que el proyecto esté muerto; incluso puede significar que es estable
      Por ejemplo, hay una librería para generar códigos QR que no se actualiza desde hace 10 años y funciona perfecto
      A veces hasta me pregunto si debería meter commits inútiles con un bot solo para que no parezca abandonada
    • No quiero programar git, solo quiero terminar el trabajo
      Por eso prefiero los tradicionales comandos con pipes de UNIX antes que herramientas como jujutsu
      Por la misma razón uso Maven en vez de Gradle

  • Fue gracioso que el autor asumiera que los desarrolladores escriben buenos mensajes de commit
    En la práctica, la mayoría son del nivel “changed stuff”
    La gente como yo, que sí le da importancia al log de commits, es minoría
    Los mensajes de commit generados por IA podrían ayudar bastante con este problema

    • Esto es un problema de liderazgo. Un buen líder técnico o CTO deja claras las expectativas sobre la calidad de los mensajes de commit
    • En los equipos que hacen squash al hacer merge de un PR, el cuerpo del PR termina siendo el mensaje de commit, así que suele tener mejor calidad
    • En un flujo de trabajo de squash & merge, al final el título del PR es el mensaje clave
      El desarrollador puede escribir los commits como quiera, total después nadie los lee
    • En nuestro equipo distinguimos entre repos Core y Non-Core
      En Core, la revisión de PR y una explicación detallada son obligatorias; en Non-Core se puede experimentar con más libertad
      En Core, a veces el mensaje de commit es 20 veces más largo que el código; en Non-Core puede ser algo como “hope this works”
    • Que los desarrolladores no escriban buenos mensajes de commit es un problema cultural
      En nuestra empresa eso sí se exige entre todos

  • Probé esos comandos en varias bases de código y los resultados no coincidían con la realidad
    Por ejemplo, en el resultado de git shortlog -sn --no-merges, la persona con más commits a veces ya ni trabaja en la empresa
    Tener muchos commits no significa haber contribuido más

    • Por eso prefiero squash-and-merge
      Los commits de más se quedan solo en la rama del feature, y a la rama principal entra un historial limpio
    • Este tipo de comandos sirve cuando estás diagnosticando un proyecto problemático
      En una base de código normal suelen arrojar resultados sin mucho valor
    • Sinceramente, dudo que el autor realmente haya ejecutado esos comandos; se siente como un texto escrito por un LLM
    • Si un flujo automatizado usa las credenciales de una sola persona, las estadísticas pueden quedar distorsionadas
    • A mí también me pasa que tengo muchísimos más commits que los demás en el repositorio central de una empresa
      Fue porque armé el proyecto desde cero; hoy otros hacen commits con más frecuencia que yo

  • Me pareció interesante la idea de que “el archivo que más cambia es el que la gente teme tocar”

    • Es como la paradoja de “el restaurante al que nadie va porque siempre está demasiado lleno”
    • Lo probé y los archivos que más se modificaban eran archivos generados automáticamente o cosas aburridas como puntos de entrada
    • Este tipo de comandos necesita advertencias
      Sacar conclusiones solo con el resultado puede hacerte ver hasta ingenuo
      En realidad, muchas veces solo muestran en qué features se trabajó durante el último año
    • Si miras juntos Churn (frecuencia de cambios) y Complexity (complejidad), el análisis se vuelve mucho más útil
      Donde ambas son altas está la verdadera zona problemática
      Cuando esas zonas se acumulan, empieza a aparecer el clásico “hay que reescribir la app desde cero”
    • Los archivos que la gente teme tocar son los archivos esenciales y complejos
      Todos tienen que modificarlos, pero son tan grandes que cuesta muchísimo trabajar con ellos

  • Yo tengo un alias de resumen en git que imprime de una vez el resumen de ramas, cantidad de commits, cantidad de autores, cantidad de archivos, etc.
    Saqué la idea de GitAlias/gitalias

    • Me da curiosidad por qué lo hizo como una función en .gitconfig; parece más simple convertirlo en un script git-summary
    • Eso de escribir estos comandos manualmente cada vez también suena a texto generado por IA; alguien con experiencia los reutilizaría con aliases
    • Buen script, pero en mi entorno no existe un comando como log-of-count-and-email
    • Estaría bueno tener una página man local para esto

  • Hay que agregar límites de palabra (\b) a la expresión regular
    Por ejemplo, “bug” dentro de “debugger” puede dar resultados incorrectos
    Un ejemplo corregido sería el siguiente
    git log -i -E --grep="\b(fix|fixed|fixes|bug|broken)\b" ...

    • En macOS \b no está soportado, así que en vez de -E habría que usar la opción de regex de Perl -P
      Se puede corregir a algo como git log -i -P --grep="\b(...)\b"
    • Nosotros también usamos la palabra “rollback” con otro significado, así que hace falta filtrarla
    • Buena observación, queda mucho más preciso

  • Si no haces squash-merge, la persona con más commits podría ser justamente el peor desarrollador
    Antes trabajé con alguien así: tocaba el mismo archivo una y otra vez hasta que terminó despedido
    El squash ayuda bastante a ocultar ese problema

  • Las estadísticas simples de cantidad de commits son poco confiables
    Hay gente que hace commits solo cuando el código ya está perfectamente testeado, y otra que commitea una línea a la vez
    El valor de un commit puede variar 100 veces según la persona

    • Pero el objetivo del autor era mirar la tendencia de cambio
      La velocidad de cambio importa más que el valor absoluto

  • Este enfoque de análisis me recordó a “Your Code as a Crime Scene” de Adam Tornhill
    Enlace original
    También se parece al concepto de Developer’s Legacy Index

    • Me gustaban sus primeros artículos sobre C, qué bueno volver a verlo mencionado

  • Habría estado mejor si el autor hubiera mostrado directamente los resultados de cada comando
    Más que la explicación, ejemplos de salida habrían sido mucho más convincentes

    • A mí también me pareció que el texto tenía un ligero aire de haber sido escrito por IA, pero igual aprendí cinco comandos, así que no estuvo mal