parche (mono) parche o no (mono), esa es la pregunta

Question

Estaba hablando con un colega sobre un comportamiento inesperado/no deseado de algún paquete que utilizamos. Aunque hay una solución fácil (o al menos una solución) de nuestro lado sin ningún efecto secundario aparente, él sugirió fuertemente extender el código relevante parcheándolo y publicando el parche corriente arriba, con suerte para ser aceptado en algún momento en el futuro. De hecho, mantenemos parches contra versiones específicas de varios paquetes que se aplican automáticamente en cada compilación nueva. El argumento principal es que esto es lo correcto, en lugar de una solución "fea" o un parche de mono frágil. Por otro lado, estoy a favor de la practicidad sobre la pureza y mi regla general es que "sin parche"> "parche de mono"> "parche duro", al menos para cualquier cosa que no sea una corrección de errores (crítica).

Así que me pregunto si hay un consenso sobre cuándo es mejor parche (duro), parche mono o simplemente tratar de trabajar con un paquete de terceros que no hace exactamente lo que a uno le gustaría. ¿Tiene que ver principalmente con la razón del parche (por ejemplo, corregir un error, modificar el comportamiento, agregar la característica que falta), el paquete dado (tamaño, complejidad, madurez, capacidad de respuesta del desarrollador), otra cosa o no hay reglas generales y una debería decidir caso por caso?

Answer 1

en mi opinión:

Si se indicaría 'inesperado/comportamiento no deseado' = error, entonces monkeypatching (o duckpunching)!.

Si crees que es un error en la lib, tiene sentido aplicar parches y empujar el parche en sentido ascendente.

Si entiendo que la definición de 'trabajar alrededor' está agregando complejidad a su aplicación para compensar un comportamiento de lib, tendría que decir que monkeypatching es definitivamente una mejor idea.

mi .2 pesos.

Answer 2

Bueno, es el riesgo bastante clásico frente a los beneficios.

¿El parche está libre de riesgos? y pesado en beneficios? monopatch él. Si hay un poco de riesgo, y solo un poco de beneficio, no lo pondría en un par, y simplemente conecte el arreglo en su típico proceso de lanzamiento.

Answer 3

La aplicación de parches es lo "correcto" por una razón: con software de código abierto, si ha descubierto un error genuino o necesita una característica que sospecha que otros pueden necesitar, parcheando y enviando el parche corriente arriba es una forma de retribuir a la comunidad y contribuir a mejorar el software en su conjunto. Si se acepta el parche, es un +1 gratuito para usted o la reputación de su empresa. Nadie estaba triste porque tenían demasiados ejemplos de códigos fuente abiertos útiles que han contribuido a la comunidad en su currículum ...

No es que siempre hagamos lo correcto, en ese momento, en las trincheras. Pero si vamos a tener una discusión abstracta sobre las mejores prácticas, si parece que el orden correcto de precedencia sería "parche y envíe"> solución inteligente> encontrar un paquete que funcione mejor> feo monkeypatch ;-)

Answer 4

Una parte de la información que nos falta es si el comportamiento inesperado que describes es un error, puro y simple, o si su comportamiento lo desean algunos consumidores del paquete.

Como han mencionado otros aquí, es la compensación de riesgo y esfuerzo. No puedo hacer afirmaciones definitivas sin conocer sus circunstancias específicas.

Sin embargo, mi intuición es que el parcheo y el empuje aguas arriba darán lugar a menos riesgo y esfuerzo en el largo plazo, suponiendo que piense que su parche será aceptado.Independientemente de si tiene un parche duro o parche de mono, tendrá un costo: cada vez que actualice la versión del paquete que usa, tendrá que probar que el parche aún funciona y posiblemente actualizarlo dependiendo de sobre los cambios en el paquete. Con un parche duro, también tendrá que volver a aplicar el parche, pero eso será menos trabajo que la prueba/actualización que tendrá que hacer con cualquiera de las opciones, lo más probable.

Hay dos victorias para el parcheo en este escenario, como yo lo veo.

Si se olvidó del parche cuando realiza la actualización, con un parche duro, su parche desaparecerá por completo, causando una falla catastrófica y visible, lo más probable. Mientras que con un parche de mono, tu parche seguirá allí, pero no lo habrás probado, todavía tiene el mismo efecto, que en mi opinión es un estado mucho más peligroso que el parche duro que falta por completo.

La otra ventaja para el parche duro es que, con un parche duro, con el tiempo debe integrarse en el paquete y el costo desaparece. Mientras que un parche de mono se mantendrá indefinidamente, hasta que el problema se resuelva de manera independiente.

Si el comportamiento inesperado es algo que otros consumidores desean, y no simplemente un error, esto complica la imagen que pinto. En este caso, la solución de parche de mono simplemente tendría que eliminar el comportamiento. El parche duro, sin embargo, tendría que mantener el comportamiento para aquellos que lo deseen.

Este análisis ignora cualquier obligación moral que pueda tener con los mantenedores del paquete y otros consumidores.

Además, estoy filosofía opuesta a todo el concepto de mono parches, pero eso no es relevante para esta discusión :-)