老韓頭的開發日常 ☞ 【好書學習】系列
背景
作為丙方，完成了甲方的二開需求。是以，在設計二開子產品的時候，考慮的是當時所列的需求清單，并整合到一個二開子產品中。完成傳遞後，客戶評價蠻好的。是以，成功的為乙方争取到了繼續合作的機會。然後，就沒我啥事了，尴尬...
再之後過了一兩個月，另一個丙方搞不定甲方的需求，是以我又被安排上線收拾殘局。而，此處接手的殘局有點坑，涉及多個開發的二開子產品。由于甲方的需求是分批提出，且由多個團隊完成。是以，二開子產品的間存在循環依賴的情況。在已經跑起來的庫上運作，沒有任何問題，但是，在新庫上重新安裝的時候，會發現根本安裝不上。是以，決定花一個月的時間徹底拆分已有的二開子產品。
為什麼拆
問：一般情況下，odoo上線後基本上不會出現在新庫上重新部署的情況，為什麼還要費勁去拆分二開子產品呢？
答：最核心的原因是，這可能是一個需要長期維護的項目。
問：長期維護的項目和單次分包的差別是什麼？
答：長期維護的項目，雖然在前期可能會付出更多的時間，但是可便于後期的項目管理，即便是最極端的情況發生，也可以以較快的速度恢複生産；而單次分包的項目，一般隻是為了去完成一份需求清單，而且即使設計了二開的原因，也很少會有單次分包人員會遵守，因為工作量會增加。
怎麼拆
- 針對基礎子產品的功能擴充：比如庫存、銷售、采購等，此類二開子產品需僅包含針對該單一子產品的功能擴充，且不能引用非odoo原生的子產品；
- 針對多基礎子產品的功能擴充：比如針對銷售的業務中擴充對調撥的業務處理邏輯，此類二開子產品應僅包含odoo原生的基礎子產品和1中二開子產品；
-
針對獨立業務場景的功能擴充：比如圖書館有借書還書的需求，就需要單獨根據業務場景擴充功能子產品。
以上三項是否拆分的合理的一個主要的辨別是，1、2、3中的任意子產品均可獨立安裝（2、3中在__manifest__.py中添加所需依賴）
本項目的拆分效果如下：
各二開子產品建議是甲方公司的簡稱，便于辨別。
【odoo】【知識雜談】關于odoo二開子產品規範的一點思考
結論
由于業務是不斷變化和發展的，為了讓系統真正成為助力業務發展的工具，勢必會接觸到odoo的二開市場。是以，不管是甲方還是可以長期維護的乙方，都建議在二開之初，可以參考上面提到的“怎麼拆”章節。當然，如果是單次分包，那就随意吧。
本文來自部落格園，作者：老韓頭的開發日常，轉載請注明原文連結：https://www.cnblogs.com/xushuotec/p/15758106.html