Czasami Sylius wyznacza nowe kierunki w świecie open source – i wygląda na to, że mamy do czynienia z jednym z takich momentów.
Pamiętasz czasy, gdy Domain-driven Design (DDD) było na ustach całej branży IT? Sylius sięgnął po tę ideę i zaadaptował ją, tworząc własne podejście: Documentation-driven Development. To podejście zmienia sposób myślenia o budowaniu funkcjonalności w eCommerce, stawiając dokumentację w centrum procesu tworzenia.
Co było wyzwaniem?
Wraz z rozwojem Syliusa pojawia się dobrze znane wyzwanie: dług technologiczny, który może narastać z każdą kolejną linią kodu. Więcej funkcji oznacza większą złożoność, więcej elementów do utrzymania i więcej testów do napisania.
Jeszcze trudniejsze okazało się jednak coś innego – różnorodność oczekiwań użytkowników. Jedni chcą korzystać z Syliusa w scenariuszu A, inni w scenariuszu B, a czasami te potrzeby wzajemnie się wykluczają.
Weźmy przykład międzynarodowych struktur URL. Część sklepów preferuje jedną domenę z kodami krajów, np. store.com/pl, podczas gdy inne chcą oddzielnych domen, takich jak store.com, store.de, store.pl. Obsługa obu podejść wymagałaby skomplikowanej logiki routingu, dużej ilości dodatkowego kodu i stałej konserwacji.
Kiedy jednak zespół Sylius zapytał użytkowników, ilu z nich faktycznie potrzebuje pełnej elastyczności w tym zakresie, wielu odpowiedziało, że domyślne rozwiązanie z kodami krajów w zupełności im wystarcza. Mimo to pozostawała istotna grupa, która chciała mieć możliwość dostosowania struktury URL.
Zamiast więc rozbudowywać panel administracyjny o kolejną funkcję, która pochłonęłaby czas i zwiększyła dług technologiczny, zdecydowano się przygotować dokumentację. Ponieważ użytkownikami Syliusa są deweloperzy, a sama platforma jest open-source, mają oni kompetencje, by samodzielnie wprowadzić takie modyfikacje w kodzie.
Jeśli wystarczy kilka prostych kroków i fragment kodu, aby zmienić sposób działania struktur URL, to lepszym rozwiązaniem jest dokumentacja niż dodatkowa funkcja w panelu. Zainteresowani mogą krok po kroku dowiedzieć się, jak to zrobić.
W Syliusie istnieje wiele podobnych przypadków – dlatego zespół zobowiązał się do tworzenia dokumentacji dla rozwiązań, które nie trafiają do rdzenia platformy, ale wciąż mogą być kluczowe dla części użytkowników.
https://bitbag.io/pl/blog/jak-uniknac-dlugu-technologicznego-w-syliusie
Problem „Frankensteina"
Zamiast angażować się w niekończące się cykle patchy i nowych wydań, tracąc czas na pozornie proste funkcje, Sylius obrał inne podejście. Dodawanie do rdzenia zbyt wielu przypadków brzegowych szybko zmieniłoby platformę w „Frankensteina” – obciążonego nadmierną złożonością i spowolnioną wydajnością.
Te problemy znikają, gdy użytkownikom daje się proste instrukcje, jak samodzielnie zaimplementować lub zmodyfikować potrzebny element.
Przykład? Sylius musiał obsłużyć duże zamówienia, w których klienci kupowali tysiące produktów jednocześnie. Powodowało to spadki wydajności podczas finalizacji zakupów. Zamiast tworzyć nową funkcję przełączającą koszyk w tryb wysokiej wydajności, zespół przygotował krótki fragment kodu modyfikujący jeden plik i dodający prostą regułę. Efekt? 90% poprawy wydajności koszyka – bez nowych wydań, bez dodatkowego kodu w rdzeniu, bez konieczności pisania testów i z pełną możliwością cofnięcia zmian w każdej chwili.
Dlatego w Syliusie warto szukać miejsc, które można usprawnić – nie przez dodawanie kolejnych funkcji, lecz przez analizę działania aplikacji, identyfikowanie punktów do poprawy i dokumentowanie rozwiązań w formie krótkich przewodników „how-to”. Użytkownicy Syliusa nie zawsze oczekują, że wszystko znajdzie się w panelu administracyjnym. Często wystarczy im jasna instrukcja, jak coś zrobić samodzielnie.
<div class="rtb-text-box is-blue-100">Pomyśl o tym jak o klockach LEGO – z tego samego zestawu można zbudować niezliczone, równie ciekawe konstrukcje.</div>
Jak działa Documentation-driven Development?
Koncepcja Documentation-driven Development idealnie wpisuje się w fakt, jak wiele nowej treści zespół Syliusa wprowadził ostatnio do dokumentacji. Zarówno ilość, jak i jakość materiałów znacząco wzrosły w ostatnich miesiącach – a to dopiero początek.
Proces ten przypomina podejście Test-driven Development, z tą różnicą, że punktem wyjścia jest dokumentacja. Sylius zaczyna od jej napisania, co natychmiast weryfikuje, czy odpowiedni kod istnieje i znajduje się we właściwym miejscu. Z drugiej strony, jeśli przygotowanie pierwszych stron dokumentacji okazuje się trudne, to często sygnał, że gdzieś popełniono błąd lub że sama koncepcja wymaga uproszczenia.
Niedawno zespół miał dokładnie taką sytuację. Podczas pisania dokumentacji pojawiło się pytanie: „Skoro chodzi o prostą funkcję, dlaczego wymaga aż tylu modyfikacji?”. To skłoniło ich do znalezienia prostszego rozwiązania – w efekcie finalna dokumentacja zamknęła się na jednej stronie.
Ten proces działa więc jak swoisty kompas: pozwala szybko ocenić, czy kierunek rozwoju jest właściwy, czy też dane podejście wymaga korekty.
Liczby nie kłamią
Według statycznej analizy kodu Sylius ma około 12 razy mniej linii niż Magento. Dzięki temu deweloperom łatwiej jest zrozumieć strukturę projektu, poruszać się po nim i uczyć się, jak działa całość – zwłaszcza że kod jest pisany w sposób czysty i uporządkowany. Dodawanie tysięcy nowych linii niepotrzebnie zwiększałoby złożoność i ryzyko narastania długu technologicznego.
Zespół dostrzega potencjał takiego podejścia i coraz mocniej zakorzenia je w swojej pracy. To nie tylko poprawia dokumentację, ale też zmienia sposób działania całego zespołu. Zanim nowa funkcja zostanie dodana, najpierw powstaje jej dokumentacja. Następnie zespół zastanawia się, czy wymaga ona usprawnień, czy lepiej zrealizować ją jako wtyczkę, a jeśli rozwiązuje problem o charakterze uniwersalnym – czy powinna trafić do rdzenia Syliusa.
Dzięki temu procesowi każda funkcja przechodzi wielokrotne testy i weryfikacje, co gwarantuje, że finalne rozwiązanie charakteryzuje się najwyższą jakością.
https://bitbag.io/pl/blog/standardy-kodowania-najlepsze-praktyki
Lepsza kontrola nad rozwojem
Oprócz tego, Sylius zyskuje lepszą ilościową kontrolę nad wszystkim. Jeśli piszą dokumentację, mogą zobaczyć, ile osób ją odwiedziło. Jeśli wydają wtyczkę, mogą sprawdzić, jak często jest pobierana lub instalowana. To oznacza, że nic nie trafia do rdzenia Syliusa przypadkowo.
Wierzą, że zwiększanie ilości i jakości dokumentacji pomoże też trenować rozwiązania AI, które następnie mogą wspierać wielu deweloperów pracujących z Syliusem. Im bardziej kompletna staje się ich dokumentacja, tym lepiej działają z nią modele językowe, czyniąc narzędzia jak GitHub Copilot znacznie bardziej efektywnymi dla rozwoju Syliusa.
{{cta-technology-sylius="/pl/comp/cta"}}
Przyszłość Syliusa: mniej kodu, więcej możliwości
Oto założenie Syliusa do budowania przyszłości wysoce elastycznych platform eCommerce: Lekki, elastyczny rdzeń > Dokumentacja > Nadmiar funkcji.
Czy to oznacza rezygnację z nowych funkcjonalności? Wręcz przeciwnie – będą dodawane częściej niż kiedykolwiek, ale w sposób przemyślany. Każdy element, który trafi do rdzenia Syliusa, musi najpierw udowodnić swoją realną wartość.
Takie podejście pozwala utrzymać Syliusa w lekkiej, zwinnej formie, a jednocześnie czyni go niezwykle potężnym dla tych, którzy potrzebują konkretnych rozwiązań. Chodzi nie o narzucanie gotowych schematów, lecz o dostarczanie deweloperom narzędzi i wiedzy, które umożliwiają im tworzenie własnych, dopasowanych rozwiązań.
Model oparty na dokumentacji zmienia nie tylko sposób, w jaki rozwijany jest Sylius – redefiniuje także myślenie o tym, czym powinny być platformy open source. Bo czasami najlepsza funkcjonalność to ta, która pokazuje ci, jak samemu zbudować dokładnie to, czego potrzebujesz.
<div class="rtb-text-box is-blue-50">👉 Dokumentacja Syliusa </div>
