Pour singe-patch ou ne pas?

Question

Ceci est une question plus générale que spécifique à la langue, bien que je me suis heurté à ce problème en jouant avec le module python ncurses. J'avais besoin d'afficher les caractères régionaux et de les faire reconnaître comme des caractères, donc je viens d'appliquer rapidement quelques fonctions/méthodes à partir du module curses.

C'est ce que j'appelle une solution rapide et laide, même si cela fonctionne. Et les changements étaient relativly petit, donc j'espère que je n'ai rien gâché. Mon plan était de trouver une autre solution, mais en voyant ça fonctionne et fonctionne bien, vous savez comment c'est, j'ai fait face à d'autres problèmes que j'ai dû affronter, et je suis sûr que s'il n'y a pas de bug, je ne fais le mieux. La question plus générale me paraissait cependant évidente - certains langages nous permettent de corriger de gros morceaux de code à l'intérieur des classes. Si c'est le code que je n'utilise que pour moi-même, ou si le changement est petit, ça va. Que se passe-t-il si un autre développeur prend mon code, il voit que j'utilise un module bien connu, donc il peut supposer qu'il fonctionne comme d'habitude. Ensuite, cette méthode se comporte soudain différemment alors il devrait. Donc, très subjectif, devrions-nous utiliser des correctifs de singe, et si oui, quand et comment? Comment devrions-nous le documenter?

---

edit: pour @guerda:

Monkey-patcher est la capacité de changer le comportement dynamicly d'un morceau de code au moment de l'exécution, sans modifier le code lui-même.

Un petit exemple 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

Ne le faites pas!

Surtout avec le logiciel libre, vous avez toutes les possibilités pour obtenir vos changements dans la distribution principale. Mais si vous avez un hack faiblement documenté dans votre copie locale, vous ne serez jamais en mesure d'expédier le produit et la mise à niveau vers la prochaine version de curses (mises à jour de sécurité n'importe qui) sera très coûteuse. Voir this answer pour un aperçu de ce qui est possible sur les bases de code étranger. Le linked screencast vaut vraiment le coup d'oeil. Soudain, un hack sale devient une contribution précieuse. Si vous ne pouvez vraiment pas obtenir le correctif en amont pour une raison quelconque, créez au moins un repo local (git) pour suivre en amont et avoir vos modifications dans une branche distincte. Récemment, je suis tombé sur un point où je dois accepter le patch-singe en dernier recours: Puppet est un morceau de code ruby ​​"run-everywhere". Puisque l'agent doit fonctionner sur des systèmes potentiellement certifiés, il ne peut pas exiger une version de ruby ​​spécifique. Certains d'entre eux ont des bogues qui peuvent être corrigés par des méthodes de sélection de singe-patching dans le runtime. Ces correctifs sont spécifiques à la version, contenus et la cible est gelée. Je ne vois pas d'autre alternative là-bas.

Answer 2

Je dirais non.

Chaque patch de singe doit faire l'objet d'une exception et être marqué (par exemple avec un commentaire // HACK) en tant que tel afin qu'il soit facile de le repérer.

Comme nous le savons tous, il est facile de laisser le code laid en place parce que cela fonctionne, alors pourquoi y consacrer plus de temps. Donc, le code moche sera là pour longtemps.

Answer 3

Un mot: oscommerce.

Si vous ne l'avez jamais joué avec cette avant qu'il ne soit criblé de

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

Sans oublier que l'ensemble a dégradé codebase en raison de la « mettre la fonctionnalité où que vous soyez » mentalité. Des concepts de programmation plus récents tels que OO (hérité et classes composites viennent à l'esprit) sont conçus pour rendre ces non-problèmes. Utilise les!

Answer 4

Je pense que la question ne peut pas être adressée avec un seul oui-non/bonne-mauvaise réponse définitive - les différences entre les langues et leurs implémentations doivent être considérées.

En Python, il faut se demander si une classe peut être patchée avec un singe (voir SO question pour la discussion), qui se rapporte à l'implémentation légèrement moins OO de Python. Je serais donc prudent et enclin à faire des efforts pour trouver des solutions de rechange avant de procéder à l'application des patchs.

Dans Ruby, OTOH, qui a été conçu pour être OO dans l'interpréteur, les classes peuvent être modifiées, qu'elles soient implémentées en C ou en Ruby. Même Object (à peu près la classe de base de tout) est ouvert à la modification. Le rapiéçage de singes est donc adopté avec plus d'enthousiasme en tant que technique dans cette communauté.

Answer 5

Je suis d'accord avec David en ce que le code de production de correction de singe n'est généralement pas une bonne idée.

Cependant, je crois que pour les langages qui le supportent, le patch singe est un outil très précieux pour les tests unitaires. Il vous permet d'isoler le morceau de code que vous devez tester, même s'il a des dépendances complexes, par exemple avec des appels système qui ne peuvent pas être Dependency Injected.