Mam około 3 letnie doświadczenie jako dev (w różnych projektach, z różnymi technologiami i architekturami). Niedawno dołączyłem do projektu, w którym pracują też starsi devowie (po 6,7,8 lat doświadczenia).
Jednak cały system, moim zdaniem, wymaga zmian, ponieważ w chwili obecnej jest bardzo ciężko zarządzalny, z perspektywy nowej osoby, która ma kilka większych projektów opartych na mikroserwisach za sobą.
Nasz system to taki monolit, nieznający czegoś takiego jak SOLID i unit testy. Chciałbym zacząć od stworzenia nowego podejścia do nowych funkcjonalności - czyli w skrócie, nowe moduły piszemy już jako osobne mikroserwisy, wprowadzamy CQRS, DDD w fomire light (żeby nikogo nie przerazić bo się zniechęcą) no i przede wszystkim testy. Może nie potrzebujemy ekstra skalowalności, ale przede wszystkim opanowanie chaosu który wprowadza dynamika nowych funkcjonalności. Dużo się interesuje nowoczesną architekturą, pracowałem w jednym projekcie gdzie to naprawdę dobrze działało i mam pewne doświadczenie.
Niestety często spotykam się z uwagami takimi jak: "a po co to potrzebne", "zawsze tak robiliśmy i jest dobrze", "ja nie wiem czy to zadziała".
Moje pytanie brzmi: jak przekonujecie ludzi do swoich pomysłów? :)
Taaaaa, DDD fajnie brzmi, problem tylko taki ze malo kto umie, a jeszcze mniej wie o co w tym tak na prawde chodzi, ale kazdy sie chwali ze robi w DDD, smiech na sali :D trafilem na artystow co twierdzili ze robia w DDD a robili zwyklego malego cruda
Czyli rozumiem że Twoim zdaniem mikroserwisy to uniwersalne rozwiązanie? Tam gdzie spotyka się monolit w negatywnym sensie tego określenia, Ty jako naturalne rozwiązanie z automatu podajesz mikroserwisy?
Zdaję sobie sprawę z tego z jakimi problemami się zmagasz- programiści nie przykładający wagi do jakości kodu, brak testów, zapewne paranoiczne nastawienie do perspektywy większych zmian. Tyle tylko że opierając się na Twojej wypowiedzi Ty wcale nie wupadasz dużo lepiej, bo idziesz w drugą stronę skrajności.
Może nie potrzebujemy ekstra skalowalności, ale przede wszystkim opanowanie chaosu który wprowadza dynamika nowych funkcjonalności.
To da się osiągnąć bez żadnego przeinzynierowania. Skoro jak sam napisałeś skalowalnosc nie jest problemem to powiedz proszę- jakie konkretne motywy stoją za wprowadzeniem architektury opartej o mikroserwisy? A konkretnie- jakie w kontekście tego konkretnego projektu zalety przeważą nad wadami w postaci konieczności komunikacji sieciowej, de facto brak transakcyjnosci wspartej przez infrastrukturę (zakładam że skoro teraz jest monolit, to i transakcje), zapewnienie spójności danych (a konkretnie eventual consistency)?
Może najpierw wypadało by pomyśleć nad rozbiciem tego monolitu w monolit modularny- tu też będziesz mógł zastosować DDD. Oczywiście zdajesz sobie sprawę że DDD to nie tylko kod i nie tylko programiści?
Ja rozumiem że w dzisiejszych czasach ludzie jak słyszą "monolit" to dostają ataku paniki, ale to mało obeznani ludzie są.
Motywy są takie, że projekt już został dość mocno podzielony na różne zespoły deweloperskie, rozwijające różne funkcjonalności. Mikroserwisy dadzą nam spore korzyści - każdy taki zespół będzie miał większą elastyczność (osobne wdrożenie, osobne review, może nawet osobne zasoby produkcyjne w przyszłości).
No i oczywiście, zdaję sobie sprawe że DDD to nie tylko kod i programiści - dlatego też napisałem w wersji light. Chodzi mi głównie o umiejscowienie modelu domenowego w centrum systemu i nie mieszania tego z infrastrukturą + porządne testy.
@Aventus masz rację, że łatwo pójść w drugą strajność - tego nie chcę. Dlatego właśnie planuje to zrobić na spokojnie, zacząć od czegoś małego, zobaczyć jak działa i jak się przyjmie.
Do tego, myślę że CQRSy pomogą nam w zakresie podzielenia odpowiedzialności - będzie to pewne wymuszenie na programistach tworzenie interfejsów opartych na zadaniach, do tego pojedyncza odpowiedzialność w kodzie. Myślę, że pominiemy pewne elementy, nie będziemy na przykład wykorzystywać zewnętrznego systemu kolejkowego - komendy mogą być synchroniczne. Za to integracja modułów w oparciu o eventy, w kontekście dużego, podzielonego zespołu to bardzo przydatna sprawa. Zdaje też sobie sprawę z wad takich jak eventual consistency, ale w przypadku naszego systemu nie musimy się tym aż tak przejmować - nie jest to nic na tyle krytycznego.
Mikroserwisy dadzą nam spore korzyści - każdy taki zespół będzie miał większą elastyczność
(osobne wdrożenie, osobne review, może nawet osobne zasoby produkcyjne w przyszłości).
No to przy robieniu taska wdróż na próbę te mikroserwisy do tego, co robisz aktualnie. Łatwiej przekonać zespół, żeby ci pozwolili zrobić taska jak chcesz (albo postawić ich przed faktem dokonanym), niż żeby zmieniali cały projekt. A przy większym projekcie i tak ciężko wszystko przepisywać od razu. Poza tym - skąd wiesz, że w tym projekcie w ogóle będzie się dało łatwo zaimplementować i zintegrować mikroserwisy? Skąd wiesz, że w tym projekcie to będzie dobra idea? Musiałbyś to i tak sprawdzić na małą skalę, zamiast robić ryzykowne zmiany na cały projekt.
Nasz system to taki monolit, nieznający czegoś takiego jak SOLID i unit testy.
Nie system, tylko ludzie, którzy go pisali co najwyżej nie znają/nie chcą stosować SOLID ani nie piszą testów.
Co do testów, to przecież możesz przy okazji pisania nowych modułów pisać je z testami, oraz przy okazji każdego ruszenia starego modułu, dopisać do niego kawałek testu. Zasada skauta.
wprowadzamy CQRS
Tzn. w którym miejscu? To nie jest pattern, który się wrzuca wszędzie.
, DDD w fomire light
Co masz na myśli DDD w formie light? I czym to się wg ciebie różni od wersji normalnej?
no i przede wszystkim testy.
Niestety często spotykam się z uwagami takimi jak: "a po co to potrzebne", "zawsze tak robiliśmy i jest dobrze", "ja nie wiem czy to zadziała".
Moje pytanie brzmi: jak przekonujecie ludzi do swoich pomysłów? :)
Musisz mieć dobre argumenty, dlaczego w danej sytuacji jakieś rozwiązanie techniczne lepiej się sprawdzi. Jeśli sam tego nie wiesz, nie potrafisz sam wykazać takich argumentów, to może lepiej jednak nie przepisuj tego na CQRS/DDD/mikroserwisy, jeśli masz to robić dla samej nadziei, że będzie lepiej. To pachnie cargo cultem...
LagMan napisał(a):
Jednak cały system, moim zdaniem, wymaga zmian, ponieważ w chwili obecnej jest bardzo ciężko zarządzalny, z perspektywy nowej osoby, która ma kilka większych projektów opartych na mikroserwisach za sobą.
Co nazywasz "większym projektem"? Ile tych mikroserwisów miałeś?
Nasz system to taki monolit, nieznający czegoś takiego jak SOLID i unit testy.
To są jakby 2 oddzielne problemy. Monolit nie od razu musi być zły. Ile teamów iluosobowych nad tym pracuje?
Chciałbym zacząć od stworzenia nowego podejścia do nowych funkcjonalności - czyli w skrócie, nowe moduły piszemy już jako osobne mikroserwisy
A masz dobry plan jak zintegrować je z istniejącym monolitem? Jak z deploymentami?
Niestety często spotykam się z uwagami takimi jak: "a po co to potrzebne", "zawsze tak robiliśmy i jest dobrze", "ja nie wiem czy to zadziała".
Moje pytanie brzmi: jak przekonujecie ludzi do swoich pomysłów? :)
Wcale, bo to nie ma sensu. Albo ktoś od razu rozumie co się do niego mówi albo nie rozumie.
Jeśli pracujesz z ludźmi, którzy mają już kilkuletnie doświadczenie i nie stosują SOLID oraz testów jednostkowych, to wszelkie próby przekonywania ich będą dla Ciebie tylko stratą czasu i niepotrzebnym stresem.
LagMan napisał(a):
Moje pytanie brzmi: jak przekonujecie ludzi do swoich pomysłów? :)
- Prezentacja tematu X (raz na jakiś czas mamy takie sesje edukacyjne zespołu, gdzie każdy może zaprezentować interesujący go temat, produkt, technologię. Firma wspiera takie inicjatywy przez zamówienie pizzy, hamburgerów albo jakiejś innej formy obiadowej)
- Dyskusja nad tematem X
- Zastanowienie się czy X może być zastosowane w codziennej pracy
Jak mam potrzebę przekonania kogoś do czegoś, to staram się pokazać korzyści płynące z tego czegoś, a nie operować na hasłach "jest to dobre zawsze i wszędzie, bo jest nowoczesne i każdy, powtarzam, każdy tak robi".
-
Zacznij od pisania unit testów, trzymania się SOLID itp. w nowych taskach, w których robisz komuś review lub, które robisz sam.
-
Kolejny krok to rozbicie tego na mniejsze komponenty. Napisałeś "Motywy są takie, że projekt już został dość mocno podzielony na różne zespoły deweloperskie" - niech one wydzielą te grupy funkcjonalności i je rozwijają, ale idąc od razu w mikroserwisy będzie to zbyt brutalna przesiadka.
-
Polecam też ideę community w takiej sytuacji. Raz w tygodniu miejcie wspólne spotkanie (minimum 1 członek zespołu), które trwało by z godzinkę i tam ustaljcie wspólne kroki co do commonowych tematów (jakieś commonowe paczki, generyczne skrypty budujące aplikację, decyzje co do architektury, konsultacje co do generycznego systemu CI/CD, testy integracyjne itp.). Niech tam będą wszyscy - PM, developerzy, testerzy, DevOps.
-
Idź małymi kroczkami. Wydziel grupy tematów np.:
a) rozbicie monolitu na X dużych klocków
b) sposób pracy z gitem w nowym flow (git flow)
c) sposób wersjonowania
d) sposób korzystania z wspólnych rzeczy (np. macie jakiś wewnętrzny framework testowy, którego używają wszyscy - niech to będzie jakaś paczka)
e) jak testować integracyjnie aplikację (macie jakieś CI?, jak wygląda deploy?)
f) pull requesty
g) review
h) unit testy obowiązkowe
Moim zdaniem najlepiej wszystko komunikować językiem korzyści... czyli, ktoś musi wiedzieć, co z tego będzie miał... dlaczego warto popierać dany pomysł. Długa kwestia to sam sposób wprowadzania nowego podejścia - najlepiej małymi kroczkami np, na małych projektach. Są też specyficzne zespoły, które np lubią wyzwania, wtedy warto więc ująć to w kontekście wyzwania... nie wiem czy nam się to uda, ale myślę, że mamy potencjał, to trudne, ale nie z takimi rzeczami radziliśmy sobie itd.
@offtop Nie jestem przekonany czy to taki nietuzinkowy temat. Anyway....
system to taki monolit, nieznający czegoś takiego jak SOLID i unit testy.
Zmień pracę.
Mam dwa przemyślenia:
- SOLID, testy itd. - zgadzam się, to jest podstawa. Myślę, że najważniejsze to zacząć to samemu robić. Reszta zależy już od sytuacji konkretnego zespołu, choć od razu Cię uprzedzę, że proces będzie trochę trwał. Jeśli jest wsparcie menedżera, można to wykorzystać np. do zabrania się za wdrażanie nowych osób i po prostu budowania bazy ludzi. W końcu masa krytyczna zacznie przeważać. Część osób pójdzie za tym, gdy zobaczy efekty, lecz musisz też się liczyć z tym, że będą osoby, które po prostu nie będą chciały i całą energię będą poświęcały na to, żeby się wykręcić. Z nimi niestety nic nie zrobisz, trzeba czekać aż same się zmęczą i odejdą. Przestrzegam natomiast przed obrabianiem d(!)y ludziom i wszelkimi nieetycznymi działaniami w kierunku kogokolwiek. Raz, że jest to po prostu nieprofesjonalne, a dwa że może się zemścić, i dobrze zresztą. Toksyczna osoba jest mimo wszystko dużo gorsza niż osoba, która ma braki w doświadczeniu.
Z doświadczenia powiem też, że jeśli trafią się osoby, które będą chętne nauczyć się czegoś nowego, to trzeba być cierpliwym i im pomagać. To, że powiecie sobie "piszemy testy jednostkowe" nie sprawi, że takim osobom od razu zacznie to wychodzić. Zdobywanie doświadczenia to proces, który może trwać nawet latami.
Inna sprawa... jeśli ktoś ma 8 lat doświadczenia i pyta się "a po co unit testy", to hmmm...
- Mikroserwisy, DDD, CQRS - a czy system rozwiązuje problemy, do których te wzorce zostały zaprojektowane, że proponujesz ich zastosowanie?