Mentionsy

Dzisiaj podzielimy się z Wami super tipem jak zwiększyć czas budowania naszego projektu z 5 minut do 2 godzin z użyciem monorepo.

Które mogą nas w tym monorepo spotkać.

Oczywiście te 2 godziny to taki najgorszy scenariusz, ale to niestety może być prawda w monorepo.

I będziemy dzisiaj mówili o 7 pułapkach monorepo.

A dzisiejszym tematem jest 7 pułapek monorepo.

Bo monorepo to nie jest róża bez kolców.

I zacznijmy w takim razie od pierwszej pułapki monorepo, czyli koszty utrzymania.

Mam na myśli, że monorepo bardzo szybko przez dodawanie tych kolejnych projektów, tak jak mówiliśmy o tym w poprzednim odcinku, bardzo szybko rośnie.

Druga pułapka przy rozwijaniu Monorepo i przy pracy z Monorepo jest to, że bardzo często psujemy Mastera, czyli Maina, czyli naszego głównego brancha i w tym momencie powoduje to utrudnienie pracy innych ludzi, którzy pracują, innych deweloperów, którzy pracują w danym Monorepo.

I tutaj bardzo ważne jest, że w przypadku monorepo to jest super istotne, żeby wrzucać do tego mastera tylko to, czego jesteśmy pewni.

Wykazaliśmy się tutaj odpowiedzialnością, czyli nie sprawdziliśmy wszystkich małych fragmentów kodu i aplikacji i po prostu coś gdzieś się zepsuło i teraz ktoś inny po prostu ma zepsuty kod, a my tego nawet nie wiemy, bo ktoś korzystał z naszego kodu, ale my o tym nie wiemy, bo wrzucamy wszystko do tego naszego monorepo, ktoś z tego korzysta.

Trzecią pułapką jest to, że w monorepo wszyscy są odpowiedzialni za kod monorepo.

Nie ma monorepo takich fragmentów kodu, gdzie możemy powiedzieć, że to nie jest nasze.

Nie, nie, właśnie w Monorepo jest tak, że wszystkie zmiany, które my wprowadzamy i od tych zmian ktoś inny, czyli jakiś inny fragment aplikacji korzysta, to w Monorepo musimy zadbać o to, żeby te zmiany dalej były dobrze wprowadzone, czyli nie możemy popsuć cudzego kodu, to raz, o tym mówiliśmy wcześniej, ale to też znaczy tyle, że nie możemy powiedzieć w Monorepo, że

Nie, tutaj bardzo ważna w Monorepo jest odpowiedzialność za kod i o to, że musimy się dogadywać.

To dobrze byłoby się jednak dogadać z innymi programistami, którzy pracują nad tym monorepo i wspólnie razem uradzić coś, co będzie dobre dla wszystkich, a nie, że każdy po prostu sobie coś tam wrzuci i w sumie nikt za to nie jest odpowiedzialny.

Jakością kodu lub dostępami do różnych zakątków monorepo.

Tak czyli mamy akurat mówimy teraz o frontendowym monorepo czyli mamy nasz pakiet JSON gdzie mamy listę zależności.

Musimy o tym cały czas pamiętać, cały czas mieć to z tyłu głowy, że w Monorepo mamy bardzo dużo takich rzeczy, które są na całe Monorepo i będą dotykały koniec końców wszystkich naszych programistów.

To wtedy przy takich zmianach trzeba mieć po prostu dobrego, kogoś zaufanego, kto szybko klepnie pull request, o ile oczywiście robimy pull requesty, bo jak nie robimy pull requestów i mamy monorepo, o matko.

Monorepo na pewno wtedy nie ma sensu.

W Monorepo mamy taką sytuację, że możemy sobie importować różne rzeczy z różnych rzeczy.

I takie rzeczy się czasami dzieją w monorepo.

I tutaj może być bardzo przydatna na przykład eslintowa reguła module boundaries od NX, czyli NX to jest takie narzędzie do zarządzania monorepo.

Więc te kierunki zależności to jest bardzo ważna rzecz w Monorepo, żeby nad tym panować.

Ja myślę, że to jest jedna z takich podstawowych rzeczy, które powinna być w Monorepo, bo inaczej będziemy mieć Circular Dependencies, jak powiedziałeś, czyli aplikacje.

Kolejną pułapką monorepo jest jego wpływ na wdrożenia.

Mamy takie pokrótce dwa podejścia do monorepo gdzie mamy monorepo gdzie są po prostu niezależne paczki czyli je budujemy i one po prostu są w jednym miejscu ale możemy myśleć takie podejście że wszystko jest po prostu zależne od siebie na poziomie kodu źródłowego czyli importujemy bezpośrednio z innych plików.

To znaczy tyle, że jeśli wprowadzamy nową zmianę do Monorepo i na przykład wrzucamy nasz kod już do tego naszego Main'a czy tam Master'a, no to pytanie co teraz musimy wdrożyć na produkcję?

No właśnie, to może być wszystko, ale to może też być tylko jedna aplikacja, której jesteśmy właścicielami, ale to musimy wiedzieć, czyli musimy być świadomi tego, że monorepo będzie miało wpływ na to, co wdrażamy i może to niekoniecznie znaczyć, że jesteśmy niezależni, czyli może być tak, że właśnie tak jak powiedziałeś, że wprowadzamy jakąś zmianę do naszego małego utila i nagle okazuje się, że zrobiliśmy właśnie deploy wszystkich naszych aplikacji.

I to jest bardzo ważne przy monorepo, żeby mieć tą świadomość, że pewne zmiany mogą wymusić deploy aplikacji, za których w ogóle nie odpowiadamy.

Jest to pewien negatywny aspekt monorepo, na który trzeba bardzo uważać, ale na szczęście module boundaries pozwalają nad tym ponować.

Siódma pułapka monorepo jest związana z tym, gdy zdecyduje się wyjść z monorepo tak naprawdę.

Czyli przejście z monorepo na polirepo, czyli na wiele repozytoriów może być bardzo utrudnione.

Więc trzeba uważać przy podejmowaniu decyzji, żeby iść w ogóle w monorepo.

Ja bym powiedział, że to zależy też od tego jak to monorepo prowadzimy.

Czyli właśnie czy odrobiliśmy dobrze naszą lekcję z poprzednich zagrożeń, pułapek i czy nasze monorepo jest w dobrym stanie, bo jest monorepo i jest monorepo.

Ale tak oczywiście przejście z monorepo do polirepo będzie trochę trudniejsze niż w drugą stronę, czyli dobrze to musimy przemyśleć.

Podsumowując, ja bym powiedział, że Monorepo ma trochę pułapek, w które możemy wpaść, ale jak zwrócicie uwagę, to one cały czas oscylują w sumie wokół podobnych rzeczy, czyli kierunki zależności, żeby tam nie było spaghetti code'u.

Na koniec dnia Monorepo jest bardzo, bardzo zachęca do tego, żeby taki spaghetti code wprowadzać.

Dokładnie, jeżeli ktoś nie usiądzie i tego troszeczkę nie zaplanuje, nie podzieli, nie ustali kto do czego może mieć dostęp, jakie są warstwy monorepo, jakie są zależności, kierunki zależności, jak ten cały tooling ustawić, no to możemy skończyć z bardzo ciężkim