¿Qué tan comunes son las correcciones de "vendaje"? [cerrado

Question

Imagina el siguiente escenario:

Ha detectado que su programa (o de otra persona) tiene un error: una función produce el resultado incorrecto cuando se le da una entrada en particular. Examina el código y no puede encontrar nada malo: parece que se empujará cuando se le da esta entrada.

Ahora puede hacer una de dos cosas: o examina más el código hasta que haya encontrado la causa real; O abofeteas en un vendaje agregando un if Comprobación de instrucciones si la entrada es esta entrada en particular: si es así, devuelva el valor esperado.

Para mí, aplicar el vendaje sería completamente inaceptable. Si el código se está comportando de manera inexpectada en esta entrada, qué otro Entrada que se ha perdido, ¿reaccionará extrañamente? Simplemente no parece una solución en absoluto, solo estás palizando el problema debajo de la alfombra.

Como ni siquiera consideraría hacer esto, me sorprende la frecuencia con la que los profesores y los libros nos recuerdan sobre cómo aplicar correcciones de "vendaje" no es una buena idea. Entonces esto me hace preguntarme: ¿qué tan comunes son este tipo de "correcciones"?

Answer 1

Las presiones de tiempo/fecha límite son una razón.

Si te enfrentas a una fecha límite ajustada y tienes a tu jefe respirando por tu cuello (¡posiblemente literalmente!) Entonces hacer esto y pensar "volveré y arreglaré esto más tarde" es muy tentador y podría ser lo único que tú puede hacer.

Por supuesto, la cantidad de veces que realmente regresa y soluciona correctamente son muy pocos y distantes porque tiene un nuevo problema que necesita solucionar ayer.

Answer 2

Por mucho que a nosotros, como a los programadores, no les gusta admitirlo, el software bellamente codificado no siempre se traducirá en más valor para la empresa o los clientes. Esto es doblemente cierto en una situación de desastre, por ejemplo, el software está cobrando dos tarjetas de crédito de las personas. A veces, como un vendaje, solo necesita detener el sangrado por cualquier medio necesario y prometer regresar después de que el paciente haya sido estabilizado y solucionar el problema central.

El truco es que una vez que la urgencia se ha ido, es realmente difícil convencer a cualquiera de priorizar el reemplazo del vendaje con una verdadera solución. Especialmente teniendo en cuenta que siempre hay otro problema urgente esperando en la fila detrás del primero. Solo tienes que estar atento a quedarte con el problema más allá de la fijación rápida.

Answer 3

Tiempo

Es la razón #1 en mi opinión. Aunque si el problema es en cuanto a la base de código, podría tomar más tiempo para investigarlo. A menudo, mis soluciones de "vendaje" involucran ajustes CSS o UI. He escrito algunos CSS en línea bastante desagradables y JavaScript para tratarlos rápidamente. Volver y solucionarlo siempre es una opción si tiene tiempo.

Answer 4

Los hacemos excepcionalmente.

---

Para las soluciones durante el desarrollo, nos aseguramos de que no se haga ninguna solución sin conocer la causa raíz. Sin embargo:

• Excepcionalmente, la búsqueda de la causa raíz comenzará a tomar demasiado tiempo o en el puesto y hay una fecha límite difícil,
• Excepcionalmente los cambios en el código para solucionar la causa raíz no son factibles tácticamente (el cambio tardará demasiado y se acercará a la fecha límite)

En esos casos optamos por las correcciones de "vendaje". Luego abrimos defectos internos para abordar la causa raíz. Sí, la mayoría de las veces estos defectos internos se tratan con muy baja prioridad.

---

Para las soluciones en el flujo de mantenimiento, nos aseguramos de que no se haga ninguna solución sin conocer la causa raíz. Sin embargo:

• Muy excepcionalmente la búsqueda de la causa raíz se detendrá,
• Excepcionalmente puede ocurrir que la fijación de la causa raíz no sea factible (el cambio no es trivial y el cliente necesita la solución ayer).

En esos casos, optamos por la solución temporal de "vendaje" primero y una vez que el cliente está contento, trabajamos en la solución adecuada y solo entonces se resuelve el defecto.

Answer 5

Desambiguación.

• Dado un error en particular, existe una dificultad considerable para definir objetivamente si una solución en particular es un "vendaje" porque: la "solución correcta" de uno puede ser el "vendaje" de otra persona.
• Entonces, uso la siguiente definición: para arreglar un defecto de una manera que sea menos elegante y menos estudiada de lo que desearía haber hecho profesionalmente.

---

Primero, con respecto al frecuencia de las correcciones de "vendaje":

• Nuevo código: casi ninguno.
• Código anterior:
  • Encontrarás algunos, aunque generalmente se escriben con elegancia (Consulte "Mitigación basada en datos" a continuación) que no parecen vendajes y sobrevivirán a todas las reseñas de código.
  • También preste atención al "vendaje invisible": simplemente no llame a esa función. Con la falta de código, ni siquiera hay un rastro de sugerencia de que existe un error.
• Código antiguo con muchas dependencias externas:
  • Casi lleno de eso.
  • Casi siempre se escribió para una versión obsoleta de la dependencia, y nadie realmente leyó las "Notas de versión" de la dependencia antes de actualizar la dependencia a una nueva versión.

---

Segundo, mi consejo:

Si el error ocurre en el propio código fuente del equipo de desarrollo:

• Arreglarlo de manera profesional. (Si lo arreglas, lo posees).
• Cuando esté bajo presión, haga las mejores cosas que pueda, lo que requiere que lo haga:
  • Mire el impacto potencial en el usuario final: del error en sí, y de la solución propuesta, para decidir si aceptar la solución.
  • Estudie fragmentos de código relacionados (utilizando la información del historial de su herramienta de gestión del código fuente) y discuta con sus compañeros de trabajo (pero no ocupe demasiado de su tiempo), hasta que haya entendido bien el problema y la solución.
• Siempre rastree el error con un sistema de seguimiento de defectos.

Si el error ocurre en el código fuente de otro equipo:

• Empuja a ese equipo para que solucione su error.
• Siempre presente ese error con el otro equipo sistema de seguimiento de defectos.

Si el error ocurre en el producto de otra empresa (o no de ninguna empresa):

• En este caso, las correcciones de cinta de conducto (o soluciones basadas en datos) podría ser la única forma de solucionar el error.
• Si es de código abierto, presente ese error con algunos (posiblemente público) sistema de seguimiento de defectos De todos modos, para que alguien pueda investigarlo.

Answer 6

Depende mucho de la edad de la base del código, creo. En el código antiguo, creo que es muy común, reescribir que la rutina de Cobol de 20 años no es divertida. Incluso en código moderadamente nuevo que está en producción, sigue siendo bastante común.

Answer 7

Yo diría que es muy común.

Mira la publicación del blog de Joel Spolsky: El programador de cinta adhesiva

Puedo decir fácilmente que casi todos los proyectos en los que he estado he tenido que aplicar algún tipo de vendaje o cinta adhesiva para cumplir con los plazos y completar una tarea. No es bonito, no está limpio, pero hace el trabajo para que un negocio pueda continuar funcionando, y el proyecto puede avanzar de alguna manera.

Hay una diferencia entre el mundo académico y el mundo real en el que el software realmente necesita enviar bajo contrantes de tiempo y negocios.

En cierto modo, lo pone debajo de la alfombra, para diferir una solución, hasta que con suerte, más tarde. Lamentablemente, con demasiada frecuencia, la solución diferida nunca ocurre y este código encuentra su camino en la producción.

Answer 8

Es difícil decir sin más contexto: en su ejemplo, ¿por qué agregar la declaración IF no es la solución correcta? ¿Es porque supuestamente hay algún otro bloque de código allí en algún lugar que se supone que está tratando con esa entrada?

Con qué frecuencia se usan las correcciones de vendaje depende de una serie de cosas, como cuán complejo es el código, ya sea que la persona más familiarizada con el código esté disponible (la persona responsable de la rutina de Cobol de 20 años de Craig puede haber dejado la compañía hace años ) y las escalas de tiempo involucradas.

Con una fecha límite que te mira a la cara, a veces te rellenas la solución más segura, incluso si solo abofeteando un yeso en lugar de arreglar la causa raíz. Está bien siempre que no empeore las cosas, pero es importante rastrear el hecho de que todavía no es correcto y aún necesita ser arreglado correctamente.

Answer 9

Hay casos en los que ese tipo de solución está realmente bien y probablemente el ideal (en lo que respecta a la cantidad de tiempo que lleva depurar).

Imagine un escenario en el que tiene 20 DLL que se supone que actúan como algún tipo de módulos para su ejecutable principal, pero también requieren información del ejecutable principal para ejecutar.

Si alguna vez desea usar esos DLL fuera del ejecutable principal, deberá falsificar algunos valores de retorno del ejecutable principal porque. A.) No existe en este contexto y B.) No desea que exista en este contexto.

Dicho esto, es mejor que ponga algunas directivas de compilador en su código para asegurarse de que está ejecutando un código completamente diferente cuando está evitando los resultados frente a los resultados reales.

En lugar de poner un if Dentro de la función de otra persona, pondría un {$ifdef} Alrededor de la función, de esa manera, nadie lo confunde con algo que debería estar allí.