Czy śledzenie małp jest uważane za dobrą praktykę programowania?

Miałem wrażenie, że monkeypatching jest bardziej w kategorii szybkiego i brudnego hacka, niż w standardowej dobrej praktyce programowania. Chociaż od czasu do czasu używałem do naprawy drobnych problemów z bibliotekami stron trzecich, uważałem to za tymczasowe i przesyłam odpowiednią łatkę do projektu strony trzeciej.

Jednak widziałem tę technikę jako „normalną drogę” w projektach głównego nurtu, na przykład w gevent.monkeymodule Geventa .

Czy monkeypatching stał się głównym nurtem, normalną, akceptowalną praktyką programowania?

Zobacz także: „Monkeypatching For Humans” Jeffa Atwooda

Nie, ale czasami małpa jest mniejszym złem (niż złamanie kodu :)). Moje ogólne zasady dotyczące małp w rubinie to:

• ma naprawdę dobry powód dla łaty małp (tymczasowa krytyczna poprawka jest dobrym powodem. Ładne formatowanie metody to_s nie jest, chyba że pracujesz na ActiveSupport)

• uczyń je tak przejrzystymi, jak to możliwe: umieść je w określonym miejscu w bazie kodu i osobnych plikach, napisz dokumentację opisującą powód monkeypatch (oto przykład ).

• łatwe do usunięcia - dokumentacja powinna zawierać informacje o usuwaniu i na co uważać. Wiele małp jest tymczasowych, więc powinny być łatwe do usunięcia.

Tak, monkeypatching jest bardzo przydatny!

Jakoś imiona wydają się mieć duży wpływ na postrzeganie ludzi. Nazwij to „monkeypatch” i brzmi źle, nazwij to „hot fix” lub „on-the fix” i brzmi dobrze.

Niezależnie od tego uważam, że możliwość zmiany metod / atrybutów / funkcji w czasie wykonywania jest bardzo przydatną rzeczą. Nawet javascript używają go przez cały dzień, nie wiedząc o tym.

Na przykład:

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

Ta prosta linia ilustruje fakt, że zmieniasz zachowanie przycisku. Zostało tak zaprojektowane. Podobnie możesz zmienić każdą inną funkcję, ale byłoby to niemądre.

A teraz pytanie dotyczące dostarczania łat w ten sposób ... no cóż ... dlaczego nie. Musisz tylko pobrać małą łatkę zamiast dużej wersji. Cholera, możesz nawet załatać serwer bez zatrzymywania go, świetnie! A pewnego dnia możesz także pobrać najnowszą wersję, aby uzyskać większą aktualizację. Słusznie. Tak więc głosuję na „łaty czasu wykonywania” jako dobrą rzecz.

Co ciekawe, niektóre języki, takie jak Erlang, były nawet oparte na tej koncepcji. Możliwość aktualizacji serwera w locie.

Oczywiście ostatecznie i podobnie jak we wszystkich innych kwestiach, zależy od tego, jak z niego korzystasz. Możesz robić wspaniałe rzeczy OO i gówno, wszystko jest takie samo.

EDYTOWAĆ:

Pozwól, że dodam pewne rozróżnienie spraw, niezależnie od tego, czy łatasz własną bibliotekę, czy bibliotekę innej firmy .

... w zasadzie to, co robisz z taką łatką, naprawia błąd w bibliotece własnej lub innej firmy . W obu przypadkach jest to przydatne. Na własną rękę pozwala ci to naprawić w locie. W przypadku strony trzeciej albo czekasz (kilka miesięcy?), Aż sami to naprawią, albo robisz to teraz samodzielnie. (nadal możesz przesłać im łatkę, aby naprawili ją po swojej stronie). Po wydaniu kolejnej wersji lib z naprawionym problemem nadal możesz, jeśli chcesz zaktualizować bibliotekę i usunąć łatkę po swojej stronie.

Teraz, oczywiście, jeśli użyjesz łatki, aby zmienić zachowanie lib i zrazić jego cel / sposób działania, to oczywiście jest to przepis na katastrofę. Nawet małpa to zobaczy ... mam nadzieję. ;)

Uważam, że wszystkie łatki są z natury ryzykowne ze względu na ich charakter wykonawczy i niemożność złapania w czasie projektowania.

Przyjmują wyjątki czasu wykonywania i wymagają tylko złożonych debuggerów i zegarków.

Są używane, gdy ludzie SEAL klas, a więc dziedziczenie jest niemożliwe. Istnieją jednak lepsze sposoby rozszerzania obiektów bez ich uszkadzania.

Moje dwa centy

Ogólnie łatanie powinno być ostatecznością, a jeszcze bardziej łatanie małp. Chodzi przede wszystkim o łatwość konserwacji.

Dawno temu, moje jądro Linuksa miało na sobie 3 oddzielne łaty, niezbędne dla mojego sterownika karty graficznej i dwóch zastrzeżonych aplikacji, które miałem. Dwie z nich miały sprzeczne zmiany, co oznaczało, że potrzebowałem czwartej łatki, aby rozwiązać różnice między nimi. Teraz, ilekroć problem bezpieczeństwa został naprawiony w jądrze nadrzędnym, albo musiałem czekać, aż dostawcy tych 3 łat wydadzą aktualizację do nowej wersji jądra, co trwało od jednego do sześciu miesięcy, lub musiałem ręcznie utrzymywać nadrzędny łatki bezpieczeństwa, dopóki inni dostawcy łatek nie nadrobią zaległości.

Po kilku latach dostawcom udało się włączyć do źródłowego źródła jądra i udało mi się zatrzymać proces równoważenia, ale widać, jaki był bałagan w międzyczasie. Nie narzucaj tego swoim programistom, chyba że musisz.

Nie. To nie jest standardowa technika tworzenia oprogramowania. Rozwiązanie tego problemu pozostaje nierozwiązane i ma wyraźne wady. Przychodzi na myśl naruszenie zasady substytucji Liskowa . Łatowanie małp znacznie utrudnia rozumowanie programów. W przypadku własnych programów należy umieścić kod tam, gdzie należy. W przypadku bibliotek stron trzecich zawsze będziesz żył w niebezpieczeństwie, że twoja łatka nie będzie działać z następną wersją biblioteki.

Oczywiście łatanie małp jest przydatne, jeśli wiesz, co robisz i nie masz czasu na wdrożenie rozwiązania SOLID . Ale nigdy nie powinieneś uważać tego za standardową technikę i budować łatkę małpy na łatce małpy.

BTW, czy napisałeś kiedyś test jednostkowy dla łaty dla małp?