¿Cuál es el término para una confirmación de código fuente realmente GRANDE? [cerrado]

37

A veces, cuando verificamos el historial de confirmación de un software, podemos ver que hay algunas confirmaciones que son realmente GRANDES: pueden cambiar 10 o 20 archivos con cientos de líneas de código fuente (delta) cambiadas. Recuerdo que hay un término de uso común para este gran compromiso, pero no puedo recordar exactamente cuál es ese término. ¿Alguien puede ayudarme? ¿Cuál es el término que los programadores suelen usar para referirse a este compromiso GRANDE y gigante?

Por cierto, ¿comprometer muchos cambios en conjunto es una buena práctica?

ACTUALIZACIÓN: ¡gracias a todos por la inspiradora discusión! Pero creo que "bomba de código" es el término que estoy buscando.

Ida
fuente
15
"Romper compromiso". :-)
Peter K.
3
Personalmente, llamaría un commit de ese tamaño acluster f...
Ramhound
1
Mi jefe hace esto todo el tiempo. Comentario de registro: "todo; o)"
MetalMikester
+1 para la pregunta porque me encantan todas las respuestas hasta ahora, y he sufrido por haber cometido al menos uno de los pecados al menos una vez en mi carrera y quiero que otros no lo hagan =)
Patrick Hughes
¡Podría decir código de avalancha!
Brian

Respuestas:

50

(1) Ben Collins-Sussman : "..." bombas de código ". Es decir, ¿qué haces cuando alguien se presenta a un proyecto de código abierto con una nueva característica gigantesca que tardó meses en escribirse? ¿Quién tiene tiempo para revisar? miles de líneas de código? ... "

(2) Dan Fabulich : "La bomba de código, o: el novato con grandes ideas ... Una bomba de código es un parche tan grande que nadie puede revisarlo".

(3) Google Summer of Code: Directrices : "Comprométase temprano, comprométase a menudo ... Por favor, no trabaje todo el día y luego empuje todo en una sola bomba de código . En cambio, cada compromiso debe ser autónomo para una sola tarea que debe resumirse en el mensaje de registro ".

(4) Jeff Atwood : "bombas de código ... Regla # 30: No te quedes oscuro ...

David Cary
fuente
enlace 2 y 4 enlace directo y cita enlace 1. No hay nada malo con la difusión del concepto, pero es un poco menos relevante. Me gusta el término, pero no parece que lo haya atrapado demasiado.
haylem
1
¿Qué sucede si el código comprometido es un código nuevo que está bastante aislado del resto del proyecto? En este caso, creo que una sola gran confirmación de código (casi) terminado y limpiado es mejor que muchas confirmaciones pequeñas que obligan a las personas a revisar (1) correcciones de errores intermedias, (2) refactorizar como renombrar clases, etc., ( 3) código preliminar que eventualmente se eliminará. Solo mis 2 centavos.
Giorgio
Esta es la razón por la que estoy en contra de la reescritura / rebase de la historia
dukeofgaming
@Giorgio: para eso están las ramas.
Brian
@Brian: Sí, esa es una posibilidad. En este caso, tiene una gran confirmación en la rama principal cuando combina la funcionalidad que ha desarrollado en la rama.
Giorgio
38

Probablemente lo llamemos un mal compromiso . :)

Mala práctica

Y sí, eso generalmente se consideraría una mala práctica , ya que tiene los efectos negativos de:

  • haciendo que sea difícil de revisar ,
  • haciendo que sea difícil captar fácil y rápidamente la intención original del commit ,
  • haciendo que sea difícil ver cómo impactó el código para solucionar o resolver un problema explícitamente ,
  • lo que dificulta saber si el tamaño de la confirmación se debe al ruido de otros cambios posiblemente no relacionados (por ejemplo, pequeñas limpiezas u otras tareas).

Casos aceptables

Sin embargo, puede tener casos en los que grandes confirmaciones son perfectamente aceptables . Por ejemplo:

  • cuando se fusiona a través de ramas ,
  • al agregar nuevas fuentes de otra base de código no versionada,
  • al reemplazar una característica grande en el lugar (aunque debería hacerlo en una rama, con confirmaciones más pequeñas que aborden diferentes partes del cambio, y luego fusionar todo de nuevo, para que pueda tener una mejor ventana en el desarrollo incremental de la característica y los problemas que pueden haberse encontrado en el camino),
  • al refactorizar una API que afecta a muchas clases descendientes y de consumo.

Por lo tanto, siempre que sea posible, prefiera los tipos de confirmaciones de "ataque quirúrgico" (¡y vincúlelos a las ID de tareas en su rastreador de problemas!). Si tiene una razón válida, continúe.


Aparte de eso, en realidad no sé y creo que nunca escuché un nombre especial para una gran confirmación. ¿Un monstruo comprometido? ¿Un compromiso gordo?

Actualización: la respuesta de David Cary se vincula con actores notables de TI que usan el término "bomba de código" (lo más importante, Collins-Sussman, creador original de Subversion ). Así (aunque hasta ahora no puedo decir que escuché si a menudo).

haylem
fuente
11
¡Un compromiso de Godzilla! Eeeeeeeek !!!
Péter Török
@ PéterTörök: Me gusta. Hagámoslo una tendencia. Otras opciones: un commit de ballena, un commit de Gargantuan o simplemente un BigFatCommit.
haylem
1
Sí, "malo" o "tarde". Si su empresa no tiene un nombre, asígnele el nombre del desarrollador en cuestión. "¡Hola, chico nuevo, no hagas Jerry! Comprométete temprano y comprométete a menudo"
chooban
No hagas un Jerry, ¡ese es un enfoque útil! Además, el compromiso masivo puede provenir de desarrolladores estresados ​​que no creen o entienden el uso de las versiones. ¡Comprueba el conocimiento!
Independiente
¿Qué pasa si alguien se llama Jerry?
Loïc Faure-Lacroix
12

Por cierto, ¿comprometer muchos cambios en conjunto es una buena práctica?

Bueno, no es una buena práctica retener los cambios durante mucho tiempo e implementar una variedad de características y correcciones de errores, y luego confirmarlos, que es una de las formas en que podría ocurrir una gran confirmación.

Otra forma en que esto podría suceder es si una refactorización cambia la firma de una función ampliamente utilizada, y luego todas ellas deben cambiarse. Esto no es necesariamente malo, y no quisiera que los desarrolladores se abstengan de limpiar el código por temor a cruzar algún umbral.

Entonces, hay más que solo mirar la cantidad de archivos tocados en una confirmación.

JohnMcG
fuente
55
Esta. Lo que realmente importa no es la cantidad de archivos cambiados o la cantidad de líneas cambiadas, sino el alcance de los cambios. Si puede describir de manera sucinta y precisa el conjunto de cambios en un mensaje de confirmación breve que no deja nada, el recuento de cambios físicos es relativamente intrascendente. No sin importancia, pero yo mismo, prefiero tener una gran confirmación que mantenga el código construible que un conjunto de confirmaciones donde solo algunas de ellas dan como resultado un árbol de código fuente que se construirá (cf cambios de firma del método).
un CVn
8

El término que he escuchado es "registros gruesos" . Y no soy fanático de ellos. Me gustan los commits más pequeños que aseguran que nada más se rompa en un paso razonable en un proyecto. El gran compromiso generalmente está plagado de problemas que resuenan por un tiempo cuando eso sucede.

Jesse C. Slicer
fuente
+1 ya que no lo recordaba en ese momento (aunque no creo que sea un término genérico, o no lo sé), pero escuché la palabra "fragmento" utilizada específicamente por mercurial en relación con una extensión que permite enviar un gran commit con diferentes fragmentos de datos, pero aparte de eso, no creo haber escuchado ese término para commits en general.
haylem
La compañía en la que estaba cuando el desarrollador usó ese término estaba usando SourceGear Vault.
Jesse C. Slicer
3

Lo llamo "confirmación SVN típica" o "mañana es la confirmación del día de lanzamiento"

Por mucho que me encante SVN, simplemente me desanima el hecho de que no puedo hacer commits locales.

EDITAR: generalmente tienen las palabras "cosas" y "cerveza" en el mensaje de confirmación.

EDITAR DE NUEVO: Cometer muchos cambios, aunque no necesariamente es una mala práctica, debe evitarse tanto como sea posible. Me resulta más fácil revisar una revisión / confirmación que es breve y concisa. (emparejado con un mensaje de confirmación bien escrito, vea mi edición anterior para un mal ejemplo)

Hermano Kevin D.
fuente
2

Un "fragmento de código humeante". :-)

Ross Patterson
fuente
2
  • confirmación inicial : el proyecto que no estaba bajo control de revisión lanzado en SVN
  • refactorización : el arquitecto tiene una idea brillante sobre cambiar los nombres de clase de / a la Convención de nomenclatura de pitufos o cambiar la raíz de la jerarquía de paquetes
  • formato de código : el arquitecto ha decidido cambiar la sangría del código de 4 a 3 espacios o cambiar las terminaciones de línea de Unix a Windows (o revertir)
  • Compromiso del viernes : Joe siempre se compromete a trabajar toda la semana los viernes a las 16:30
  • uuups commit : Ted eliminó por error el directorio raíz, lo confirmó y ahora bombea una vez más toda la jerarquía de archivos a SVN
Marinero danubiano
fuente
0

Por lo general, muchas personas tienden a realizar una gran confirmación utilizando VCS centralizado, especialmente el servidor aplica una buena política de confirmación. Es decir, el commit debe pasar todas las pruebas y las pruebas toman más tiempo (más de unos segundos). Por lo tanto, los desarrolladores no quieren esperar tanto tiempo para confirmar varias veces y desglosar los cambios en varias pequeñas confirmaciones.

Y los desarrolladores que son ecológicos para VCS pueden olvidar dividir los cambios en múltiples pequeñas confirmaciones. Solo recuerdan comprometerse cuando lanzan el programa al equipo de control de calidad. Peor aún, para evitar que otros vean código defectuoso, no se comprometen antes de pasar con éxito las pruebas de control de calidad. Por último, no se dieron cuenta de que habían comprometido los archivos binarios de salida, los archivos temporales y la salida del enlazador, que realmente producen un compromiso "grande".

linquizar
fuente