¿Vale la pena hacer un compromiso únicamente para resolver errores tipográficos no críticos?

67

Si me encuentro con un error tipográfico no crítico en el código (por ejemplo, un apóstrofe errante en una declaración de impresión (error)), ¿vale la pena hacer un compromiso para resolver ese error, o simplemente debería dejarse solo?

Específicamente, tengo curiosidad por sopesar el engomamiento del registro de confirmación con el valor de resolver estos errores tipográficos no críticos. Me inclino por resolverlos. ¿Estoy siendo pedante?

version-control grammar Christopher Berman
fuente
40
Si un compromiso trivial arruina algo, debe invertir en un mejor VCS, mejores herramientas de filtrado de registros o mejores prácticas para anotar diferentes severidades de corrección.
Rex Kerr
@ root45 Aunque si observa los resultados, todos son un tipo de gramática diferente de lo que esta pregunta está haciendo.
Izkata

Respuestas:

130

Mi sensación personal es que mejorar la calidad vale la menor molestia de una entrada de registro de confirmación adicional, incluso para pequeñas mejoras. Después de todo, las pequeñas mejoras cuentan mucho cuando se tiene en cuenta el efecto de ventana rota .

Es posible que desee agregar un prefijo con una TRIVIAL:etiqueta, o marcarlo como trivial si su VCS lo admite.

thiton
fuente
72
Solo quiero agregar a esto es que preferiría que cosas como esta se cometan por separado que agrupadas con otra cosa. El problema con el agrupamiento es que demasiado ruido puede distraer a un revisor de código de los cambios relevantes. +1
Andy
9
+1 por mencionar el efecto de ventana rota. Las cosas pequeñas importan. Si todo está realmente limpio, la gente lo pensará dos veces antes de cometer código descuidado escrito o sin probar.
Roy Tinker
25
Además, si lo agregas con una función, retrocede la función y pierdes el cambio. Cometer una cosa a la vez.
ctrl-alt-delor
44
Me interesaría mucho qué VCS permiten marcar comentarios como triviales. He trabajado con SVN, Hg y Git, y tampoco me he dado cuenta de nada de eso.
Xion
3
@Andy ese ruido no es la peor parte ... si luego alguien decide, por ejemplo, revertir este commit porque no quiere esa característica, de repente también pierdes una pequeña mejora que fue parte del commit (s).
rFactor
49

No estás siendo pedante, y es mejor resolverlos individualmente. Cuanto más atómico sea un cambio, mejor: no querrá que una corrección de error se mezcle con 500 comentarios / errores tipográficos.

jmoreno
fuente
9
+1 Cada revisión debe relacionarse solo con una solución específica. Se convierte en una PESADILLA para las correcciones de backport si cada revisión también tiene un montón de errores tipográficos aleatorios arreglados entre cambios reales.
Grant
28

En el caso general: sí

Es siempre vale la pena para aumentar la capacidad de mantenimiento de su software.

Solo házlo.

Si estás a punto de enviar un lanzamiento ...

... y si no eres el líder del equipo, consulta con él / ella .

En cuanto al contenido del registro de confirmación ...

Estoy de acuerdo con otros en que al menos deberías escribir algo que lo haga diferente de los commits relacionados con "características", si solo se trata de arreglar un error tipográfico aislado.

Una práctica común es tener algunas tareas que nunca mueren en su rastreador de problemas para rastrear cambios eternos e interminables. Por ejemplo, no es raro tener una tarea para:

  • grandes limpiezas automáticas e inofensivas (barridos de espacios en blanco),
  • juergas de caza de gramática y error tipográfico,
  • construir modificaciones del sistema,
  • etc ...

Solo tenga cuidado de que estos no se usen como ID de tareas descartables para casi cualquier cosa cuando las personas se vuelven flojas sobre la creación de tickets correctamente documentados. Especialmente si rechaza las confirmaciones que no están vinculadas a una ID (lo cual es bueno, pero las tareas grandes como estas serán aún más atractivas para los desarrolladores perezosos).

haylem
fuente
77
¿Verificando con el líder de su equipo una solución tipográfica? Si yo fuera el líder del equipo que está estresado con el próximo lanzamiento, no quisiera que me molesten esas trivialidades.
Joh
2
@Joh: no es que necesariamente pueda romper la compilación, pero puede haber otros trabajos de compilación, o uno ya esté etiquetado y listo para usar, y sus controles de auditoría (dependiendo de su industria) podrían obligarlo a vincular este compromiso inofensivo a tareas y requisitos, así que si surge de la nada, eso puede ser un poco de dolor de cabeza; que podría guardar fácilmente durante unos días después de que se publique el lanzamiento. Pero, en general, estaría de acuerdo con usted, e incluso diría que una empresa que funciona así lo está haciendo mal. Pero no eres tú quien lo arreglará, así que hazlo si no eres mayor.
haylem
2
@Joh: básicamente, si el líder de mi equipo ve una nueva construcción que repentinamente salta sobre el sistema de construcción cuando está a punto de comenzar una nueva construcción (o ya comenzó), entonces puedo asegurarle que sus niveles de estrés aumentarán con este enfoque. también ...
haylem
7

Los errores tipográficos deben agregarse como confirmación. Corregir palabras mal escritas o errores gramaticales aumentará la legibilidad de su código.

El uso de un mensaje de confirmación como "Error tipográfico fijo" o "Error tipográfico fijo en el archivo.c" le ayudará a distinguir estas confirmaciones de otras confirmaciones de código principales.

Trevor
fuente
7

Sí, absolutamente debe hacer esto, especialmente al principio de un proyecto.

¿Por qué? Dos puntos:

  1. Es probable que no sepa si un error tipográfico es "crítico" o no hasta que sea demasiado tarde. Algunas soluciones probablemente no se solucionen porque todos piensan que no será un gran problema. Hasta que lo sea.

  2. Arreglar un error tipográfico desde el principio y deliberadamente será mucho más fácil que arreglarlo después de que se hayan realizado cientos de líneas de código / llamadas de función con él. Una vez más, los hacks temporales pueden volverse semipermanentes sorprendentemente rápidos. Es por eso que tengo que tratar con objetos que tienen los métodos "CollapseAll" Y "ColapseAll".

joshin4colours
fuente
2
Sí, de todas las respuestas correctas, esta me gusta más por mencionar que depende del "cuándo".
Wonko the Sane
4

Para errores gramaticales que pueden ser vistos por un usuario final, entonces sí, por todos los medios vale la pena realizar el compromiso, ya que es completamente posible que un usuario o QA pueda aparecer y reportar el error y necesitaría ser rastreado. Si ya está solucionado, podría acelerar el tiempo que lleva resolver el problema.

Sin embargo, si es un error gramatical en los comentarios sobre el código, no haría nada al respecto a menos que también sea parte de los cambios en el código real, en cuyo caso está actualizando la documentación del código.

rjzii
fuente
3

Si te preocupa engrosar el registro de confirmación, entonces estás haciendo algo más mal. :-) ¡Los commits frecuentes son algo bueno! Cometo errores tipográficos todo el tiempo. ¡Consígalos en la base de código lo antes posible y acelere el ciclo de desarrollo!

Brian Knoblauch
fuente
2
I commit typo fixes all the timeOMI que es preocupante, ¿intentas encontrar programadores con un mejor inglés?
Mentira Ryan
Toma lo que puedes conseguir estos días. ¡Encontrar programadores que puedan escribir código viable es un problema serio!
Brian Knoblauch
2

Yo voto si. Verifíquelos. Trabajé para una compañía que odiaba a las personas que registraban cosas. Me refiero a casi cualquier cosa. Las revisiones de código fueron extensas y, por lo tanto, si registró un cambio que simplemente solucionó un error tipográfico, se le quejó. Puedes imaginar el estado del código. En realidad, el código no era terrible, pero rezumaba como melaza en lugar de fluir como vino.

Ian
fuente
0

¿Su proceso de gestión de cambios lo permite?

En mi entorno, cada compromiso que realizo debe estar vinculado a una solicitud de cambio que haya sido solicitada por los usuarios comerciales o un cambio obligatorio a nivel del sistema, completo con los procesos de prueba correspondientes del usuario final. Un error tipográfico simple como el que estás describiendo probablemente no se registraría como ninguno de esos (he encontrado errores tipográficos y gramaticales en una de mis aplicaciones que existieron durante más de 4 años sin que nadie lo notara), así que si / cuando vinieron los auditores llamando me costaría mucho explicarme.

Guardaría un cambio como el que está describiendo (y de hecho tengo uno, de hecho, el nombre de un método está mal escrito y lo acabo de descubrir) para un momento en que tengo un cambio "real" que debe ser hecho también y poner "arreglados varios errores tipográficos" en el registro.

alroc
fuente
+1 En algunos entornos esto es cierto. Por favor, no haga un voto negativo solo porque esto no es cierto donde trabaja.
MarkJ
-1 su proceso de gestión de cambios parece ser muy malo . Entendería (e incluso preferiría ) que cada confirmación debe estar relacionada con la solicitud de cambio; esta parte de su proceso se ve bien. Pero OMG parece que las solicitudes iniciadas por el desarrollador (como refactorizar esto / corregir errores tipográficos en eso ) están prohibidas, lo que me genera una gran señal de alerta. En cierto modo se asume usuarios de negocios / auditores siempre saben mejor que los desarrolladores - si eso sería siempre cerca de la verdad, entonces que iba a escribir el código ellos mismos
mosquito
Si el desarrollador puede convencer a las personas que aprueban seguir adelante con los cambios que vale la pena hacer, entonces pueden avanzar. Pero si encuentro un error tipográfico simple en el nombre de un método, o encuentro algún código que se copia / pega que debería refactorizarse en un método, no puedo realizar el cambio sin autorización. No se trata simplemente de "hacer lo correcto con el código": se deben realizar pruebas de aceptación y los desarrolladores no están en una posición en la que puedan decirle a la gente de negocios "Hice este cambio, nunca notarán lo que lo hizo, pero hay que pasar por un ciclo de prueba ".
alroc
@alroc que "si puede convencer" simplemente esconde un proceso contraproducente bajo una superficie de aspecto razonable. El requisito de convencer a la empresa / auditoría sobre los grandes cambios, sobre los puntos de control / lanzamientos de hitos acordados, etc., tiene sentido, está bien. Pasar unas horas / días para justificar un esfuerzo que lleva una semana de desarrollo y control de calidad, es tedioso pero justo, está bien. Pero forzar esto para cada método de corrección o extracción de ortografía ... dame un descanso: esto no es más que control insensible insertado en la etapa incorrecta en el momento equivocado
mosquito
Déjame intentar explicar esto de nuevo. Si puedo corregir un error tipográfico o extraer un método mientras trabajo en otro cambio aprobado, puedo introducirlo sin tener que vender a nadie. Pero no puedo hacer un cambio que no sea visible para el usuario y que no tenga un impacto positivo directo en el negocio / usuarios sin vender los poderes que están en él primero.
alroc
-1

Use DVCS para editar el historial

Si le preocupa un historial de confirmación limpio, considere hacer su trabajo principal en las ramas de características . Si trabaja con un VCS distribuido , puede editar fácilmente su historial de confirmación antes de llevarlo a la rama principal. Si está en SVN, intente con Git: puede interactuar bidireccionalmente con Subversion y también puede editar el historial antes de comprometerse realmente con Subversion.

Mantenga el sentido común de lo contrario

Si no desea o no puede editar el historial de confirmaciones, no hay ninguna razón funcional para realizar una confirmación temprana o atómica para un error tipográfico menor que no afecte las pruebas automáticas o la compilación . En este caso, en mi opinión, mantener limpio el historial de confirmaciones debería ser más importante que realizar confirmaciones realmente atómicas. Mezclar una o dos correcciones tipográficas con una modificación "regular" no dañará ningún proceso de revisión potencial. Sin embargo, es posible que desee agrupar varias correcciones triviales en una confirmación, tal vez al "limpiar" después de una sesión de codificación más grande.

Tenga en cuenta que los errores funcionales aún deben confirmarse lo antes posible en una confirmación atómica.

El tono general de las respuestas aquí parece sugerir una estrategia de "comprometer todo rápido" incluso para errores tipográficos menores. Tiendo a estar en desacuerdo y agradezco la discusión.

krlmlr
fuente