Do łatki (małpy) lub nie (małpy), to jest pytanie

Question

Rozmawiałem z kolegą o jednym raczej nieoczekiwanym/niepożądanym działaniu jakiegoś pakietu, którego używamy. Chociaż na naszym końcu jest łatwa łatka (lub przynajmniej obejście) bez widocznych efektów ubocznych, zdecydowanie zalecił rozszerzenie odpowiedniego kodu poprzez mocne łatanie i umieszczanie łaty w górę strumienia, miejmy nadzieję, że zostanie zaakceptowany w pewnym momencie w przyszłości. W rzeczywistości utrzymujemy poprawki przeciwko konkretnym wersjom kilku pakietów, które są stosowane automatycznie w każdej nowej kompilacji. Głównym argumentem jest to, że jest to słuszne, w przeciwieństwie do "brzydkiego" obejścia lub kruchej łatki małpy. Z drugiej strony, faworyzuję praktyczność nad czystością, a moja ogólna zasada jest taka, że ​​"bez łatki"> "łatka małpy"> "łatka", przynajmniej dla czegoś innego niż (krytyczna) łatka.

Zastanawiam się, czy istnieje zgoda co do tego, kiedy lepiej jest (twarda) łatka, łatka małpy lub po prostu próbować obejść pakiet innej firmy, który nie robi dokładnie tego, co by się chciał. Czy ma to głównie związek z przyczyną łatki (np. Naprawianie błędu, modyfikowanie zachowania, dodawanie brakującej cechy), dany pakiet (rozmiar, złożoność, dojrzałość, responsywność programisty), coś innego lub nie ma ogólnych zasad i jeden powinien decydować indywidualnie dla każdego przypadku?

Answer 1

moim zdaniem:

Jeśli 'nieoczekiwany/niepożądane zachowanie' = bug, następnie monkeypatching (lub duckpunching) byłoby wskazane!.

Jeśli uważasz, że jest to błąd w bibliotece, ciężkie łatanie i przesuwanie łatki w górę strumienia ma sens.

Jeśli rozumiem, że definicja "pracy w pobliżu" ma na celu zwiększenie złożoności aplikacji, aby zrekompensować zachowanie libów, musiałbym powiedzieć, że monkeypatching to zdecydowanie lepszy pomysł.

moje .2 peso.

Answer 2

Cóż, to dość klasyczne ryzyko kontra korzyść.

Czy plaster jest wolny od ryzyka? i ciężkie w korzyściach? monkeypatch to. Jeśli jest trochę ryzyka i tylko odrobina korzyści, nie będę go monkeypatch, i po prostu podłącz poprawkę do typowego procesu wydania.

Answer 3

Krosowanie jest "słuszne" z jakiegoś powodu: z oprogramowaniem open source, jeśli odkryłeś prawdziwy błąd lub potrzebujesz funkcji, którą podejrzewasz, że inni mogą również potrzebować, łatanie i przesyłanie łatki w górę to sposób, aby zwrócić społeczności i przyczynić się do lepszego oprogramowania, jako całości. Jeśli łatka jest akceptowana, jest to darmowa szansa dla Ciebie lub Twojej firmy. Nikt nigdy nie był smutny, ponieważ mieli zbyt wiele przykładów użytecznych, otwartych kodów, które wnieśli do społeczności w swoich CV ...

Nie zawsze robimy to, co trzeba, w czasie, w okopach. Ale jeśli mamy zamiar przeprowadzić abstrakcyjną dyskusję na temat najlepszych praktyk, jeśli wydaje się, że właściwą kolejnością jest "poprawianie i przesyłanie"> sprytne obejście> znajdowanie pakietu, który działa lepiej> brzydki monkeypatch ;-)

Answer 4

jeden kawałek informacji, które tracisz, czy nieoczekiwane zachowanie można opisać to bug, czysty i prosty, lub jeśli jest to zachowanie niektórzy konsumenci chcą pakietu.

Jak już zostało powiedziane przez innych tutaj, jest to kompromis z ryzykiem i wysiłkiem. Nie mogę sformułować żadnych konkretnych twierdzeń, nie znając twoich konkretnych okoliczności.

Jednak moje przeczucie, że łatanie i przesunąć w górę spowoduje mniejsze ryzyko i wysiłek w długim okresie, przy założeniu, że Twój poprawka zostanie przyjęta.Niezależnie od tego, czy masz kłopoty z poprawkami czy monkeypatch, będziesz musiał ponieść koszty - za każdym razem, gdy aktualizujesz wersję pakietu, z którego korzystasz, będziesz musiał sprawdzić, czy twoja poprawka nadal działa i ewentualnie zaktualizować ją w zależności od w sprawie zmian w pakiecie. W przypadku trudnej łatki będziesz musiał ponownie zastosować poprawkę, ale to będzie mniej pracy niż testowanie/aktualizacja, którą będziesz musiał zrobić z każdą opcją, najprawdopodobniej.

Są dwie wygrane na łatanie w tym scenariuszu, jak widzę.

Jeśli zapomnisz o łatce podczas aktualizacji, z twardą łatką, twoja łatka zniknie całkowicie, powodując katastrofalną i widoczną awarię, najprawdopodobniej. Podczas gdy z łatką małpy twoja łatka nadal będzie istniała, ale nie przetestowałeś jej, wciąż ma ten sam efekt, który moim zdaniem jest o wiele bardziej niebezpiecznym stanem, niż całkowity brak łatki.

Inną wygraną na twarde łatanie jest to, że z twardą łatką należy ją ostatecznie zintegrować z pakietem, a koszty znikną. Podczas gdy łatka małpy będzie wisieć w nieskończoność, aż kwestia zostanie w jakiś sposób rozwiązana niezależnie.

Jeśli nieoczekiwane zachowanie jest czymś, czego chcą inni konsumenci, a nie zwykłym błędem, komplikuje to obraz, który maluję. W takim przypadku rozwiązanie poprawki małpy musiałoby po prostu usunąć zachowanie. Jednak trudna łatka musiałaby zachować zachowanie dla tych, którzy tego chcą.

Ta analiza ignoruje wszelkie zobowiązania moralne, jakie możesz mieć wobec opiekunów pakietów i innych konsumentów.

Również jestem filozoficznie przeciwieństwie do całej koncepcji małpa łatania, ale to nie jest istotne dla tej dyskusji :-)