¿Parche de mono o no?

Question

Esta es una pregunta más general que específica del idioma, aunque me topé con este problema mientras jugaba con el módulo ncurses de Python. Necesitaba mostrar caracteres locales y hacer que se reconocieran como caracteres, por lo que simplemente configuré rápidamente algunas funciones / métodos del módulo de curses.

Esto fue lo que yo llamo una solución rápida y fea, incluso si funciona. Y los cambios fueron relativamente pequeños, así que espero no haber estropeado nada. Mi plan era encontrar otra solución, pero al ver que funciona y funciona bien, ya sabes cómo es, pasé a otros problemas con los que tuve que lidiar, y estoy seguro de que si no hay ningún error en esto, nunca lo haré hazlo mejor.

Sin embargo, la pregunta más general me pareció: obviamente, algunos idiomas nos permiten parchear grandes cantidades de código dentro de las clases. Si este es el código que solo uso para mí, o si el cambio es pequeño, está bien. Sin embargo, si algún otro desarrollador toma mi código, él ve que uso algún módulo conocido, para que pueda asumir que funciona como solía hacerlo. Entonces, este método de repente se comporta diferente de lo que debería.

Entonces, muy subjetivo, ¿deberíamos usar parches de mono, y si es así, cuándo y cómo? ¿Cómo deberíamos documentarlo?

---

editar: para @guerda:

El parcheo de mono es la capacidad de cambiar dinámicamente el comportamiento de algún fragmento de código en el momento de la ejecución, sin alterar el código en sí.

Un pequeño ejemplo en Python:

import os
def ld(name):
    print("The directory won't be listed here, it's a feature!")

os.listdir = ld

# now what happens if we call os.listdir("/home/")?
os.listdir("/home/")

Answer 1

¡No!

Especialmente con el software libre, tiene todas las posibilidades para llevar sus cambios a la distribución principal. Pero si tiene un hack débilmente documentado en su copia local, nunca podrá enviar el producto y actualizar a la próxima versión de maldiciones (actualizaciones de seguridad para cualquiera) tendrá un costo muy alto.

Ver esta respuesta para echar un vistazo a lo que es posible en bases de código extranjeras. El screencast vinculado realmente vale la pena un reloj. De repente, un truco sucio se convierte en una valiosa contribución.

Si realmente no puede obtener el parche en sentido ascendente por alguna razón, al menos cree un repositorio local (git) para rastrear en sentido ascendente y tener sus cambios en una rama separada.

Recientemente me he encontrado con un punto en el que tengo que aceptar el parcheado de mono como último recurso: Puppet es una" ejecución en todas partes " pieza de código ruby. Dado que el agente debe ejecutarse en sistemas potencialmente certificados, no puede requerir una versión específica de ruby. Algunos de ellos tienen errores que pueden solucionarse mediante métodos de selección de parches de mono en el tiempo de ejecución. Estos parches son específicos de la versión, están contenidos y el objetivo está congelado. No veo otra alternativa allí.

Answer 2

Yo diría que no.

Cada parche de mono debe ser una excepción y marcado (por ejemplo, con un comentario // HACK) como tal para que sean fáciles de rastrear.

Como todos sabemos, es muy fácil dejar el código feo en su lugar porque funciona, así que ¿por qué dedicar más tiempo a ello? Entonces el código feo estará allí por mucho tiempo.

Answer 3

Estoy de acuerdo con David en esa producción de parches de mono El código no suele ser una buena idea.

Sin embargo, creo que para los idiomas que lo admiten, el parche de mono es una herramienta muy valiosa para la prueba de unidades. Le permite aislar el fragmento de código que necesita probar incluso cuando tiene dependencias complejas, por ejemplo, con llamadas al sistema que no se pueden inyectar dependencias.

Answer 4

Creo que la pregunta no puede abordarse con una sola respuesta definitiva sí / no / buena-mala: las diferencias entre los idiomas y sus implementaciones deben considerarse.

En Python, uno debe considerar si una clase puede ser parcheada (vea esto Pregunta SO para discusión), que se relaciona con la implementación ligeramente menos OO de Python. Por lo tanto, sería cauteloso e inclinaría un poco de esfuerzo buscando alternativas antes de parchar monos.

En Ruby, OTOH, que se creó para ser OO en el intérprete, las clases se pueden modificar independientemente de si se implementan en C o Ruby. Incluso Object (más o menos la clase base de todo) está abierto a modificaciones. Por lo tanto, el parche de monos se adopta con más entusiasmo como una técnica en esa comunidad.

Answer 5

Una palabra: oscommerce.

Si nunca has jugado con eso antes, está plagado de

// BOF: Fixed/added/removed bla bla bla
...
// EOF

Sin mencionar que toda la base de código se ha degradado debido a la función " poner la funcionalidad donde quiera que esté " mentalidad. Los conceptos de programación más nuevos como OO (herencia y clases compuestas vienen a la mente) están diseñados para hacer que estos no sean problemas. ¡Úsalos!