分叉與覆蓋

Question

我正在研究軌道狂熱商務安裝上相當大且相當定製的紅寶石。我試圖決定如何最好地設計它，以便我可以繼續升級狂歡，而不用擔心它會打破我的修改。

在過去，我遵循一般的狂歡文檔，並通過使用裝飾器，覆蓋和有時覆蓋視圖完全修改。這工作正常，但有兩個問題。

1.）當通過裝飾器打開和擴展類時，可能很難推斷程序。如果你可以打開這個文件，例如Spree :: Product，然後查看代碼，然後在祖先中工作，而不是知道系統中各個部分的類正在被打開和修改，那麼它更容易。

2.）如果沿着這條路線走下去，可能很難升級Spree。如果你已經覆蓋了一個視圖，並且它在下一個版本的spree中發生了變化，你就無法知道。你所能做的只是升級，希望你的一個測試或者手動測試能夠在測試結束時提取。

上述的好處當然是它是一個非常簡單的方式來開始修改，如果你做了很少和很小的修改，那麼它可能很好。

但是，有沒有更好的選擇？我一直在考慮的一種方法是直接分叉Spree並直接在分叉的Spree代碼庫中進行更改。當我想要升級時，我可以簡單地將任何新的更改從spree中拖放到我的分叉回購中。這種方法的優點是，git會在我覆蓋的視圖發生變化時通知我。然後我可以手動合併，並忽略它或採取行動。有沒有人在這裏做過這個練習？我忽略了什麼缺點？

Answer 1

施普雷仍在快速發展。每個小版本的凹凸與以前的版本有明顯的不同。其中一些變化很糟糕，其中大部分變化都很好。例如，如果您運行的是Spree 2.0，則由於運輸檢修而升級是有益的，而且當我們接近2.2.3/2.3時，會有一些優化和重構。

使用狂歡的大多數商店往往有大的代碼庫，或依賴於大量的擴展。雖然我同意去class_eval的一切是普遍不贊成的，它比自己的瘋狂項目更好。我們有一個瘋狂的分支，我們必須爲我們的一個項目維護它，並且它通常會涉及到有時很痛苦的重新基地，以便從瘋狂中獲得好處。一般來說，我認爲編寫擴展或裝飾類是定製應用程序的最佳方式，確保在事物升級事件中斷時。考慮到你負責任地裝飾，通常需要更少的時間來修理破壞的東西，而不是維持單獨的狂歡叉。

這是你如何修改類和視圖的決定。有些方法可以減少侵入性，因此在變更時更加靈活。直接重新定義方法可以在前置過濾器執行時執行，或者在覆蓋執行時複製視圖，這些都是您在衡量執行成本時所必須做出的選擇，而不是維護您自己的自定義功能。

TL; DR除非你想改變狂歡你想送回瘋狂的pr，否則我會建議避免分散狂歡只是爲了你的目的定製它。如果您的目標是轉向更新的版本，那麼這是技術債務的一大來源。