Imagine el siguiente escenario:

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

Ahora puede hacer una de dos cosas: puede examinar el código más a fondo hasta que encuentre la causa real; o golpea un vendaje agregando una ifdeclaración que verifica si la entrada es esta entrada en particular; si es así, devuelve el valor esperado.

Para mí, aplicar el vendaje sería completamente inaceptable. Si el código se comporta inesperadamente en esta entrada, ¿a qué otra entrada que se haya perdido reaccionará de manera extraña? Simplemente no parece una solución en absoluto: solo está resolviendo 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 siguen recordando que la aplicación de soluciones de "vendaje" no es una buena idea. Entonces esto me hace preguntarme: ¿qué tan comunes son este tipo de "soluciones"?

Las presiones de tiempo / fecha límite son una de las razones.

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 puede hacer.

Por supuesto, el número de veces que realmente regresa y lo repara correctamente es muy poco frecuente porque tiene un nuevo problema que debe solucionarse ayer.

Por mucho que a nosotros como programadores no nos guste admitirlo, un 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 doblemente a las tarjetas de crédito de las personas. A veces, como un vendaje, solo necesita detener el sangrado por cualquier medio necesario y prometer que volverá después de que el paciente se haya estabilizado y realmente solucione el problema central.

El truco es que, una vez que desaparece la urgencia, es realmente difícil convencer a alguien para que priorice reemplazar el vendaje con una solución verdadera. Especialmente teniendo en cuenta que siempre hay otro problema urgente esperando en la cola detrás del primero. Solo tiene que estar atento para mantenerse con el problema más allá de la solución rápida.

Hora

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

Los hacemos excepcionalmente.

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

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

En esos casos, optamos por soluciones 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 correcciones en la secuencia de mantenimiento, nos aseguramos de que no se realice ninguna correcció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 arreglar la causa raíz no sea tácticamente factible (el cambio no es trivial y el cliente necesitaba la solución ayer).

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

Desambiguación

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

Primero, con respecto a la frecuencia de arreglos de "vendaje":

• Nuevo código: casi ninguno.
• Código antiguo
  • Encontrará algunas, aunque generalmente están escritas con suficiente elegancia (consulte "mitigación basada en datos" a continuación) para que no parezcan vendajes y sobrevivan a todas las revisiones 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 indicio de que exista 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 la 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:

• Arreglalo de manera profesional. (Si lo arreglas, te pertenece.)
• Cuando esté bajo presión de tiempo, haga lo mejor que pueda, lo que requiere que:
  • Observe el impacto potencial en el usuario final: del error en sí y del arreglo propuesto, para decidir si acepta el arreglo.
  • Estudie fragmentos de código relacionados (utilizando la información del historial de su herramienta de administración de código fuente) y discuta con sus compañeros de trabajo (pero no ocupe demasiado 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:

• Empuje a ese equipo para corregir su error.
• Siempre presente ese error con el sistema de seguimiento de defectos del otro equipo .

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

• En este caso, las correcciones de cinta adhesiva (o soluciones alternativas basadas en datos ) podrían ser la única forma de corregir el error.
• Si es de código abierto, archiva ese error con algún sistema de seguimiento de defectos (posiblemente público) de todos modos, para que alguien pueda investigarlo.

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

Yo diría que es muy común.

Echa un vistazo a la publicación del blog de Joel Spolsky: The Duct Tape Programmer

Puedo decir fácilmente que en 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 una empresa pueda seguir funcionando y el proyecto pueda avanzar de alguna manera.

Hay una diferencia entre el mundo académico y el mundo real donde el software realmente necesita enviarse bajo tiempo y limitaciones comerciales.

En cierto modo, lo está poniendo 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 llega a la producción.

Es difícil de 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 en algún lugar que se supone que está tratando con esa entrada?

La frecuencia con la que se usan las correcciones de vendaje depende de varias cosas, como cuán complejo es el código, si la persona más familiarizada con el código está disponible (la persona responsable de la rutina COBOL de 20 años de Craig puede haber dejado la compañía hace años). ) y los plazos involucrados.

Con una fecha límite que lo mira a la cara, a veces se encontrará con la solución más segura, incluso si solo está golpeando un yeso en lugar de solucionar la causa raíz. Eso está bien siempre y cuando no empeore las cosas, pero es importante hacer un seguimiento del hecho de que todavía no es correcto y aún debe repararse correctamente.

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

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

Si alguna vez desea utilizar esas 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 coloque algunas directivas de compilación en su código para asegurarse de que está ejecutando un código completamente diferente cuando está falsificando los resultados frente a cuando obtiene los resultados reales.

En lugar de poner una función ifdentro de otra persona, pondría una {$ifdef}alrededor de la función, de esa manera nadie la confunde con algo que debería estar allí.