La monkeypatching è considerata una buona pratica di programmazione?

No, ma a volte il monkeypatch è un male minore (che avere un codice rotto :)). Le mie regole generali per i monkeypatch in ruby sono:

• ha una buona ragione per la patch di scimmia (l'hotfix critico temporaneo è una buona ragione. Una bella formattazione del metodo to_s non lo è, a meno che tu non stia lavorando su ActiveSupport)

• rendili il più trasparenti possibili: inseriscili in un posto specifico in codebase e file separati, scrivi la documentazione che descrive il motivo di monkeypatch (ecco un example ).

• facile da rimuovere - la documentazione dovrebbe includere informazioni sulla rimozione e su cosa guardare. Un sacco di oggetti monkeypatch sono temporanei, quindi dovrebbero essere facili da rimuovere.

Sì, la monkeypatching è molto utile!

In qualche modo, i nomi sembrano essere molto influenti sulla percezione della gente. Chiamalo "monkeypatch" e suona male, chiamalo "hot fix" o "fix al volo" e suona bene.

Indipendentemente da ciò, penso che la capacità di alterare metodi / attributi / funzioni in fase di esecuzione sia una cosa molto utile. Persino le persone javascript lo usano tutto il giorno senza forse saperlo.

Ad esempio:

button.onclick = function(e) { ...}

Questa semplice linea illustra il fatto che si modifica il comportamento del pulsante. È stato progettato in questo modo. Allo stesso modo, è possibile modificare ogni altra funzione, ma sarebbe sciocco farlo.

Ora, per la questione della consegna delle patch in questo modo ... beh ... perché no. Devi solo scaricare una piccola patch invece di una grande versione. Diamine, potresti persino patchare un server senza fermarlo, fantastico! E poi, un giorno, potresti anche recuperare l'ultima versione per un aggiornamento più grande. Giusto. Quindi sì, io voto per "patch di runtime" come una buona cosa.

È interessante notare come alcune lingue come Erlang siano state costruite attorno a questo concetto. La capacità di aggiornare un server al volo.

Naturalmente, alla fine, e come con tutto il resto, è una questione di come lo si usa. Puoi creare meravigliose cose OO e merdose, è lo stesso.

EDIT:

Consentitemi di aggiungere alcune distinzione tra maiuscole e minuscole, che si tratti di la propria libreria o di terze parti .

... in pratica, ciò che fai con una patch di questo tipo sta correggendo un bug della libreria tua o di di terze parti . In entrambi i casi è utile. Per il tuo, ti consente di consegnare una correzione al volo. Per uno di terze parti, o aspetti (diversi mesi?) Finché non lo risolvono da soli, o lo fai da solo. (puoi comunque inviare loro la patch, in modo che possano ripararla dalla loro parte). Quando rilasceranno la loro prossima versione di lib con il problema risolto, puoi ancora se vuoi aggiornare la libreria e rimuovere la patch dalla tua parte.

Ora, naturalmente, se si utilizza una patch per modificare il comportamento di una lib e alienare il suo scopo / modo di lavorare, ovviamente questa è una ricetta per il disastro. Anche una scimmia vedrebbe che ... beh, lo spero. ;)

Credo che tutte le patch siano intrinsecamente rischiose a causa della loro natura di runtime e dell'impossibilità di essere catturate in fase di progettazione.

Accolgono le eccezioni di runtime e richiedono debugger e orologi complessi solo per seguirli.

Sono usati quando le classi di SEAL delle persone, e quindi l'ereditarietà è impossibile. Tuttavia, esistono modi migliori per estendere gli oggetti senza danneggiarli.

I miei due centesimi

L'applicazione di patch in generale dovrebbe essere l'ultima risorsa, patch per scimmia ancora di più. Il problema è principalmente relativo alla manutenibilità.

Molto tempo fa, il mio kernel linux aveva applicato 3 patch separate, necessarie per il mio driver della scheda video e due applicazioni proprietarie che avevo. Due di loro avevano cambiamenti contrastanti, il che significava che avevo bisogno di una quarta patch per risolvere le differenze tra loro. Ora, ogni volta che veniva risolto un problema di sicurezza nel kernel upstream, dovevo aspettare che i produttori di queste 3 patch rilasciassero un aggiornamento alla nuova versione del kernel, che richiedeva da uno a sei mesi, o dovevo mantenere manualmente l'upstream patch di sicurezza fino al raggiungimento degli altri fornitori di patch.

Dopo alcuni anni, i venditori sono riusciti a essere inclusi nel sorgente del kernel upstream, e sono stato in grado di fermare il bilanciamento, ma puoi vedere che casino era nel frattempo. Non farlo nei tuoi programmatori a meno che non sia necessario.

No. Non è una tecnica standard per lo sviluppo di software. Rimane una soluzione per risolvere un problema acuto e presenta chiari svantaggi. Mi viene in mente la violazione del principio di sostituzione di Liskov . La patch delle scimmie rende molto più difficile ragionare sui programmi. Per i tuoi programmi personali devi inserire il codice a cui appartiene. Per le librerie di terze parti vivrai sempre in pericolo, che la tua patch non funzionerà con la prossima versione della lib.

Ovviamente il patch per le scimmie è utile se sai cosa stai facendo e non hai il tempo di implementare un SOLID soluzione. Ma dovresti mai considerarlo una tecnica standard e costruire una patch per scimmia sulla patch di scimmia.

A proposito, hai mai scritto un test unitario per una patch di scimmia?