Ka\u017cdy CTO, z kt\u00f3rym rozmawiam, ma w szufladzie wizj\u0119 idealnej architektury. Taki system, kt\u00f3ry skaluje si\u0119 bez wysi\u0142ku, ma zerowy d\u0142ug techniczny i jest tak czysty, \u017ce mo\u017cna go pokaza\u0107 na konferencji. Problem w tym, \u017ce gonitwa za tym idea\u0142em cz\u0119sto ko\u0144czy si\u0119 odwrotnym skutkiem: wolniejszym rozwojem, wy\u017cszymi kosztami i zespo\u0142em sfrustrowanym nadmiarem abstrakcji.<\/p>\n
W JurskiTech widzieli\u015bmy to wielokrotnie \u2013 zar\u00f3wno u klient\u00f3w, jak i we w\u0142asnych projektach. Postanowi\u0142em spisa\u0107 trzy najcz\u0119stsze b\u0142\u0119dy, kt\u00f3re pope\u0142niaj\u0105 CTO w pogoni za \u201earchitektur\u0105 idealn\u0105\u201d. Nie chodzi o to, by z Ni\u0105 walczy\u0107, ale by podej\u015b\u0107 pragmatycznie.<\/p>\n
To chyba najpowszechniejszy grzech. Zaczyna si\u0119 niewinnie: zamiast prostego rozwi\u0105zania, dodajemy interfejs, fabryk\u0119, adapter, bo \u201ekiedy\u015b mo\u017ce si\u0119 przyda\u0107\u201d. Ka\u017cda dodatkowa warstwa to nie tylko wi\u0119cej kodu, ale przede wszystkim wi\u0119cej kontekstu do utrzymania dla zespo\u0142u.<\/p>\n
Przyk\u0142ad z \u017cycia:<\/strong> Klient (firma e-commerce) poprosi\u0142 o prosty endpoint do wy\u015bwietlania ceny produktu. Zesp\u00f3\u0142, kieruj\u0105c si\u0119 zasadami SOLID, stworzy\u0142: kontroler, serwis, interfejs repozytorium, abstrakcyjn\u0105 fabryk\u0119, DTO i mapper. Na papierze wygl\u0105da\u0142o to pi\u0119knie update \u2013 a w praktyce zmiana jednego pola w bazie wymaga\u0142a modyfikacji 6 klas. Deweloperzy sp\u0119dzali 30% czasu na \u201eprzekopywaniu si\u0119\u201d przez w\u0142asne abstrakcje.<\/p>\n Lekcja:<\/strong> Architektura powinna rosn\u0105\u0107 wraz z potrzebami, nie wyprzedza\u0107 ich. Zanim dodasz kolejn\u0105 warstw\u0119, zadaj sobie pytanie: \u201eCzy ta abstrakcja rozwi\u0105zuje realny problem dzi\u015b, czy mo\u017ce za rok?\u201d Je\u015bli to drugie \u2013 poczekaj. Koszt refaktoryzacji prostej struktury jest cz\u0119sto mniejszy ni\u017c koszt utrzymania przedwczesnej z\u0142o\u017cono\u015bci.<\/p>\n Kolejny klasyk. Zesp\u00f3\u0142 projektuje system tak, jakby od pierwszego dnia mia\u0142 obs\u0142ugiwa\u0107 ruch na miar\u0119 Facebooka. Mikroserwisy, event sourcing, Kubernetes, osobna baza dla ka\u017cdej domeny. Tymczasem rzeczywisto\u015b\u0107 wygl\u0105da tak, \u017ce aplikacja ma 200 u\u017cytkownik\u00f3w, a deployment zajmuje 40 minut przez skomplikowany pipeline.<\/p>\n Obserwacja z rynku:<\/strong> Startupy, kt\u00f3re od razu wchodz\u0105 w mikroserwisy, cz\u0119sto sp\u0119dzaj\u0105 miesi\u0105ce na konfiguracji infrastruktury, zamiast budowa\u0107 funkcje biznesowe. A potem zmieniaj\u0105 kierunek, bo rynek zweryfikowa\u0142 pierwotne za\u0142o\u017cenia \u2013 i nagle trzeba przepisa\u0107 po\u0142ow\u0119 systemu, bo granice domen nie pasuj\u0105.<\/p>\n Lekcja:<\/strong> Zawsze projektuj dla obecnych potrzeb, z marginesem na najbli\u017csze 6-12 miesi\u0119cy. Skalowanie to proces, nie stan. Monolit z wyra\u017anymi modu\u0142ami jest cz\u0119sto szybszy w rozwoju i \u0142atwiejszy w refaktoryzacji ni\u017c \u017ale zaprojektowany zestaw mikroserwis\u00f3w. Przej\u015bcie na mikroserwisy ma sens, gdy skalowanie zespo\u0142u i wydajno\u015bci staje si\u0119 realnym problemem, a nie na dzie\u0144 dobry.<\/p>\n Kiedy ju\u017c uda si\u0119 stworzy\u0107 \u201eidealn\u0105\u201d architektur\u0119 \u2013 modularn\u0105, lu\u017ano powi\u0105zan\u0105, z czystym kodem \u2013 cz\u0119sto zapominamy o kosztach jej utrzymania w d\u0142u\u017cszej perspektywie. Ka\u017cda abstrakcja to potencjalne miejsce do debugowania, ka\u017cdy interfejs to dokumentacja do utrzymania, ka\u017cda warstwa to kolejny poziom zrozumienia dla nowego cz\u0142onka zespo\u0142u.<\/p>\n Case study z \u017cycia wzi\u0119ty:<\/strong> Firma z bran\u017cy fintech mia\u0142a system oparty na zdarzeniach z pi\u0119cioma r\u00f3\u017cnymi brokerami wiadomo\u015bci. \u201eIdealnie\u201d rozdzielone domeny. Ale gdy przyszed\u0142 audyt, okaza\u0142o si\u0119, \u017ce przep\u0142yw danych jest tak skomplikowany, \u017ce nikt nie by\u0142 w stanie przewidzie\u0107 konsekwencji zmiany jednego zdarzenia \u2013 ka\u017cda modyfikacja ko\u0144czy\u0142a si\u0119 regresj\u0105 w dw\u00f3ch innych modu\u0142ach. Zesp\u00f3\u0142 sp\u0119dza\u0142 70% czasu na testowaniu, nie na rozwoju.<\/p>\n Lekcja:<\/strong> Idealna architektura to taka, kt\u00f3r\u0105 zesp\u00f3\u0142 rozumie i potrafi bezpiecznie modyfikowa\u0107. Zanim upi\u0119kszysz struktur\u0119, zmierz, ile czasu zajmuje wprowadzenie prostej zmiany \u2013 np. dodanie pola do formularza. Je\u015bli to wi\u0119cej ni\u017c kilka godzin, by\u0107 mo\u017ce Twoja architektura jest zbyt idealna.<\/p>\n CTO cz\u0119sto myl\u0105 pi\u0119kno kodu z warto\u015bci\u0105 biznesow\u0105. Tymczasem celem architektury nie jest zachwyt na konferencji, ale umo\u017cliwienie szybkiego i bezpiecznego dostarczania funkcji. Prawdziwe mistrzostwo polega na znalezieniu r\u00f3wnowagi mi\u0119dzy czysto\u015bci\u0105 kodu a pragmatyzmem biznesowym.<\/p>\n W JurskiTech sami przeszli\u015bmy t\u0119 drog\u0119 \u2013 od przesadnego modelowania do podej\u015bcia, kt\u00f3re nazywamy \u201earchitektur\u0105 just-in-time\u201d: dodawanie z\u0142o\u017cono\u015bci tylko wtedy, gdy jest to absolutnie konieczne. Bo w biznesie liczy si\u0119 nie to, jak pi\u0119kny jest kod, ale jak szybko potrafisz dostarczy\u0107 warto\u015b\u0107 klientowi.<\/p>\n Je\u015bli czujesz, \u017ce Tw\u00f3j zesp\u00f3\u0142 utkn\u0105\u0142 w pu\u0142apce przedwczesnej optymalizacji lub przeskalowania \u2013 porozmawiajmy. Czasem wystarczy spojrze\u0107 z boku, by odkry\u0107, \u017ce mniej znaczy wi\u0119cej.<\/p>\n","protected":false},"excerpt":{"rendered":" Dlaczego CTO powinni unika\u0107 \u201earchitektury idealnej\u201d? 3 b\u0142\u0119dy Ka\u017cdy CTO, z kt\u00f3rym rozmawiam, ma w szufladzie wizj\u0119 idealnej architektury. Taki system, kt\u00f3ry skaluje si\u0119 bez wysi\u0142ku, ma zerowy d\u0142ug techniczny i jest tak czysty, \u017ce mo\u017cna go pokaza\u0107 na konferencji. Problem w tym, \u017ce gonitwa za tym idea\u0142em cz\u0119sto ko\u0144czy si\u0119 odwrotnym skutkiem: wolniejszym rozwojem,<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[34,151,475,435],"class_list":["post-2694","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-architektura-oprogramowania","tag-biznes-it","tag-cto","tag-dlug-techniczny"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2694","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/comments?post=2694"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2694\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2694"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2694"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2694"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}2. Przeskalowanie na starcie \u2013 \u201emusi dzia\u0142a\u0107 dla 10 milion\u00f3w u\u017cytkownik\u00f3w\u201d<\/h3>\n
3. Ignorowanie koszt\u00f3w utrzymania \u2013 \u201ezrobi\u0142em porz\u0105dek, teraz modu\u0142y s\u0105 niezale\u017cne\u201d<\/h3>\n
Podsumowanie<\/h3>\n