Duże systemy to zazwyczaj problemy wynikające z samej skali. Odoo radzi sobie z tym dobrze, ale i tutaj potrzebna jest duża doza uwagi w wielu kwestiach. Każde zaniedbanie w opracowaniu przepływu pracy lub technicznego rozwiązania modułu odkłada się w postaci długu technologicznego. I rośnie. Obiecujemy sobie, że poprawimy to następnym razem, ale to nieprawda. W tym wpisie skupię się akurat na modułach customowych - bo tam ten mechanizm widać najwyraźniej.
Rozwój modułów Odoo - ile modułów to za dużo?
Problem skali występuje wszędzie. Również w rozwoju oprogramowania Odoo - tak zwanych modułów customowych. Standardowe funkcje Odoo - mimo że pozwalają na bardzo dużo - szybko przestają wystarczać (albo ktoś nie wiedział o standardowej funkcjonalności i dopisał kod... o zgrozo!) - i wtedy baza kodu źródłowego nam rośnie. I to zazwyczaj rośnie szybko. I tutaj pojawia się pytanie - jak najlepiej podejść do pisania modułów customowych. Nie piszę tutaj o modułach sprzedawanych na apps.odoo.com, a o modułach dedykowanych. Jak to ogarnąć?
Problem
Jeżeli wyznajemy podejście, że lepiej jest tworzyć wiele modułów, powiązania między nimi staną się szybko tak zagmatwane, że szczęścia życzę osobie, która to potem będzie upgradować do następnej wersji. Jeden duży moduł to znów problem ze zrównolegleniem pracy. Złoty środek musi leżeć gdzieś pośrodku. Wydaje mi się, że trzeba wyczucia, by określić co i kiedy warto rozdzielić, a co zostawić razem.
Miałem taką sytuację, że jeden z modułów odpowiadał za kilka różnych funkcjonalności:
- Rozszerzał moduł sprzedażowy w Odoo
- Rozszerzał tworzenie Manufacturing Order na podstawie Sales Order
- Definiował nowy model odpowiedzialny za wrzucanie plików na S3
O ile pierwsze dwa punkty można było nazwać komplementarnymi, o tyle ten trzeci to zupełnie osobna funkcjonalność. Była jednak dość sztywno powiązana z resztą kodu w module, bo tak było łatwiej. Po około roku przyszedł taki moment, że moduł odpowiedzialny za komunikację z S3 trzeba było wydzielić. Inny, nowo powstający moduł również miał korzystać z S3.
Wydzielenie modułu S3 nie było ultra-ciężkie, ale w systemie ERP, który odpowiada za działanie całej firmy, to niebezpieczne - coś może pójść nie tak. Sumaryczna ilość czasu, który został wykorzystany na implementację plus wydzielenie, jest większa, niż gdyby ktoś od razu to wydzielił. Oczywiście nie zawsze wszystko można przewidzieć, choć w tym akurat przypadku - wydaje mi się, że tak.
Jakie są najczęstsze "bugi" które widzę?
- Brak zależności w manifeście
- Jedna funkcjonalność rozbita na kilka modułów - a tak naprawdę żaden z nich nie działa osobno
- W jednym module jest kilka różnych funkcjonalności
- Nowy moduł, który warunkowo zmienia zachowanie, nie bierze pod uwagę wszystkich scenariuszy
Dlaczego tak się dzieje
A przypadki są różne i nigdy nie zakładam, że wiem, dlaczego ktoś zrobił tak, a nie inaczej. Patrząc na kod, nigdy nie zakładam, że jakiś bug czy problem wynika z nieudolności programisty. Raczej skłaniam się ku temu, że kod był tworzony w pośpiechu, bo trzeba było szybko dostarczyć funkcjonalność. Czasem dorzuca się do tego jeszcze AI - potrafi coś popsuć, albo wręcz przeciwnie, dopisać za dużo niepotrzebnego kodu, ale to już temat na osobny wpis. Warto jednak spędzić kilka chwil, żeby zastanowić się, jak nasze decyzje o kodzie wpłyną na możliwe ścieżki rozwoju modułów.
I bardzo ważne - jeśli nie spędzimy nad kodem kilku godzin więcej teraz, te "oszczędności" i tak zaprocentują w przyszłości. Tyle że na naszą niekorzyść.
Jeśli macie podobne doświadczenia z modułami Odoo, albo nie zgadzacie się z tym podejściem - odezwijcie się, chętnie podyskutuję.