To (Affe) Patch oder nicht (Affe) Patch, das ist die Frage

Question

Ich sprach mit einem Kollegen über ein eher unerwartetes/unerwünschtes Verhalten eines Pakets, das wir verwenden. Obwohl es eine einfache Lösung (oder zumindest einen Workaround) an unserem Ende ohne offensichtlichen Nebeneffekt gibt, hat er dringend empfohlen, den relevanten Code zu erweitern, indem man ihn flickt und den Patch upstream veröffentlicht, hoffentlich irgendwann in der Zukunft akzeptiert zu werden. Tatsächlich pflegen wir Patches für bestimmte Versionen mehrerer Pakete, die bei jedem neuen Build automatisch angewendet werden. Das Hauptargument ist, dass dies das Richtige ist, im Gegensatz zu einem "hässlichen" Workaround oder einem fragilen Affen-Patch. Auf der anderen Seite, bevorzuge ich Praktikabilität gegenüber Reinheit und meine allgemeine Faustregel ist, dass "kein Patch"> "Affe-Patch"> "Hard-Patch", zumindest für etwas anderes als eine (kritische) Bugfix.

Also ich frage mich, ob es einen Konsens gibt, wenn es besser ist, (Hard) Patch, Affe-Patch oder einfach versuchen, um ein Third-Party-Paket zu arbeiten, das nicht genau das tut, was man möchte. Hat es hauptsächlich mit dem Grund für den Patch zu tun (zB einen Fehler beheben, Verhalten ändern, fehlende Funktion hinzufügen), das gegebene Paket (Größe, Komplexität, Laufzeit, Entwicklerreaktion), etwas anderes oder es gibt keine allgemeinen Regeln und eine sollte von Fall zu Fall entscheiden?

Answer 1

meiner Meinung nach:

Wenn unerwartetes/unerwünschtes Verhalten '= Fehler, dann monkeypatching (oder duckpunching) angegeben werden würde!.

Wenn Sie glauben, dass es sich um einen Fehler in der lib handelt, macht das Hard Patching und Pushing des Patch Upstreams Sinn.

Wenn ich Sie Definition von "herum arbeiten", um Komplexität zu Ihrer App hinzufügen, um eine Lib Verhalten zu kompensieren, würde ich sagen, dass Monkeypatching ist definitiv eine bessere Idee.

meine .2 Pesos.

Answer 2

Nun, es ist das ziemlich klassische Risiko vs Nutzen.

Ist der Patch risikolos? und schwere Vorteile? monkeypatch es. Wenn es ein gewisses Risiko gibt und nur ein kleiner Vorteil, würde ich es nicht monkeyern und den Fix einfach in den typischen Release-Prozess einbinden.

Answer 3

Patchen ist aus gutem Grund das Richtige: Wenn Sie bei Open-Source-Software einen echten Fehler entdeckt haben oder ein Feature benötigen, von dem Sie vermuten, dass es auch andere benötigen, patchen Sie und senden Sie den Patch upstream ist ein Weg, der Gemeinschaft etwas zurückzugeben und dazu beizutragen, die Software als Ganzes besser zu machen. Wenn der Patch akzeptiert wird, ist das ein kostenloser +1 für Sie oder die Reputation Ihres Unternehmens. Niemand war jemals traurig, weil sie zu viele Beispiele für nützlichen, offenen Quellcode hatten, den sie in ihrem Lebenslauf zur Gemeinschaft beigetragen haben ...

Nicht dass wir immer das Richtige tun, zu der Zeit, in den Schützengräben. Aber wenn wir eine abstrakte Diskussion über Best Practices haben, scheint es, als wäre die richtige Rangfolge "patch and submit"> cleverer Workaround> das Finden eines Pakets, das besser funktioniert> hässlicher Monkeypatch ;-)

Answer 4

Ein Teil der Informationen, die wir vermissen, ist, ob das unerwartete Verhalten, das Sie beschreiben, ein Fehler ist, rein oder einfach, oder ob es das Verhalten ist, das einige Verbraucher des Pakets wollen.

Wie von anderen hier erwähnt, ist es der Kompromiss aus Risiko und Aufwand. Ich kann keine bestimmten Behauptungen machen, ohne Ihre spezifischen Umstände zu kennen.

Aber mein Bauchgefühl ist, dass Patching und Push Upstream auf lange Sicht zu weniger Risiko und Aufwand führen wird, vorausgesetzt, Sie denken, dass Ihr Patch akzeptiert wird.Unabhängig davon, ob Sie einen Hard-Patch oder Monkeypatch verwenden, haben Sie Kosten davon - jedes Mal, wenn Sie die Version des verwendeten Pakets aktualisieren, müssen Sie den Patch immer noch testen und gegebenenfalls aktualisieren über die Änderungen im Paket. Mit einem harten Patch müssen Sie auch den Patch erneut anwenden, aber das ist wahrscheinlich weniger Arbeit als das Testen/Aktualisieren, das Sie mit beiden Optionen durchführen müssen.

Es gibt zwei Gewinne für das Patchen in diesem Szenario, wie ich es sehe.

Wenn Sie bei einem Upgrade den Patch vergessen haben, wird Ihr Patch mit einem harten Patch vollständig verschwinden, was höchstwahrscheinlich zu einem katastrophalen und sichtbaren Fehler führen wird. Während bei einem Affe-Patch dein Patch immer noch da ist, du ihn aber nicht getestet hast, hat er immer noch den gleichen Effekt, was meines Erachtens viel gefährlicher ist als das Fehlen des Hard-Patch.

Der andere Gewinn für Hard-Patching ist, dass mit einem harten Patch schließlich sollte es in das Paket integriert werden, und die Kosten verschwinden. Während ein Affe-Patch auf unbestimmte Zeit herumhängen wird, bis das Problem irgendwie unabhängig gelöst wird.

Wenn das unerwartete Verhalten ist etwas anderes Paket-Verbraucher wollen, und nicht nur einen Fehler, kompliziert dies das Bild, das ich male. In diesem Fall müsste die Affe-Patch-Lösung einfach das Verhalten entfernen. Der harte Patch müsste jedoch das Verhalten für diejenigen, die es wollen, beibehalten.

Diese Analyse ignoriert alle moralischen Verpflichtungen, die Sie gegenüber den Paketbetreuern und anderen Konsumenten haben könnten.

Auch bin ich philosophisch das gesamte Konzept des Affe Patchen dagegen, aber das ist nicht relevant für diese Diskussion :-)