W ci\u0105gu ostatnich pi\u0119ciu lat obserwuj\u0119 niepokoj\u0105cy trend w polskich firmach technologicznych: fetyszyzacj\u0119 framework\u00f3w. React, Vue, Angular, Next.js \u2013 sta\u0142y si\u0119 nie tylko narz\u0119dziami, ale wr\u0119cz religiami. Zespo\u0142y developerskie wybieraj\u0105 jeden framework i trzymaj\u0105 si\u0119 go jak przys\u0142owiowej deski ratunku, nawet gdy projekt ewoluuje w kierunku, dla kt\u00f3rego to narz\u0119dzie nie by\u0142o projektowane.<\/p>\n
Problem nie le\u017cy w samych frameworkach \u2013 s\u0105 one genialnymi narz\u0119dziami, kt\u00f3re znacz\u0105co przyspieszaj\u0105 rozw\u00f3j. Problem zaczyna si\u0119 w momencie, gdy standaryzacja staje si\u0119 celem samym w sobie, a nie \u015brodkiem do celu. Widz\u0119 to w trzech powtarzaj\u0105cych si\u0119 scenariuszach, kt\u00f3re kosztuj\u0105 firmy nie tylko pieni\u0105dze, ale przede wszystkim \u2013 innowacyjno\u015b\u0107.<\/p>\n
Przypadek z rynku: \u015bredniej wielko\u015bci e-commerce, kt\u00f3ry w 2018 roku postawi\u0142 na React z Redux. Przez trzy lata zesp\u00f3\u0142 zbudowa\u0142 na tym stacku ca\u0142\u0105 platform\u0119. Gdy w 2022 roku pojawi\u0142a si\u0119 potrzeba wdro\u017cenia rozbudowanej funkcjonalno\u015bci real-time (chat z konsultantem, aktualizacje stan\u00f3w magazynowych na \u017cywo), okaza\u0142o si\u0119, \u017ce architektura oparta o Redux jest jak pr\u00f3ba w\u0142o\u017cenia kwadratowego klocka w okr\u0105g\u0142y otw\u00f3r.<\/p>\n
Zesp\u00f3\u0142 przez miesi\u0105ce pr\u00f3bowa\u0142 \u201ena si\u0142\u0119\u201d dopasowa\u0107 rozwi\u0105zanie do istniej\u0105cego stacku, zamiast rozwa\u017cy\u0107 bardziej odpowiednie narz\u0119dzia (np. Socket.io z prostym stanem lokalnym). Efekt? Projekt op\u00f3\u017aniony o 4 miesi\u0105ce, koszty przekroczone o 60%, a finalne rozwi\u0105zanie i tak dzia\u0142a\u0142o z op\u00f3\u017anieniem 2-3 sekund.<\/p>\n
Dlaczego to si\u0119 dzieje?<\/strong> Deweloperzy, kt\u00f3rzy sp\u0119dzili lata specjalizuj\u0105c si\u0119 w jednym frameworku, cz\u0119sto trac\u0105 zdolno\u015b\u0107 my\u015blenia architektonicznego w oderwaniu od tego narz\u0119dzia. Framework przestaje by\u0107 \u015brodkiem transportu, a staje si\u0119 celem podr\u00f3\u017cy.<\/p>\n W jednej z warszawskich software house’\u00f3w wprowadzono polityk\u0119 \u201e100% React dla frontendu\u201d. Ka\u017cdy projekt, niezale\u017cnie od specyfiki, musia\u0142 by\u0107 realizowany w React. Pocz\u0105tkowo przynios\u0142o to korzy\u015bci: \u0142atwe rotacje mi\u0119dzy projektami, wsp\u00f3lna baza wiedzy, przyspieszone onboardowanie.<\/p>\n Problem ujawni\u0142 si\u0119 przy projekcie dashboardu analitycznego z setkami wykres\u00f3w aktualizowanych w czasie rzeczywistym. React z Virtual DOM okaza\u0142 si\u0119 tu nieoptymalny \u2013 ka\u017cda aktualizacja powodowa\u0142a kosztowne re-rendery. Prosty eksperyment z Svelte (kt\u00f3ry kompiluje do vanilla JS) pokaza\u0142 40% lepsz\u0105 wydajno\u015b\u0107, ale zosta\u0142 odrzucony z powodu \u201eodst\u0119pstwa od standardu\u201d.<\/p>\n Koszty ukryte:<\/strong> firma nie tylko dostarczy\u0142a wolniejszy produkt, ale przede wszystkim straci\u0142a szans\u0119 na zdobycie kompetencji w nowej technologii. Gdy rok p\u00f3\u017aniej pojawi\u0142 si\u0119 podobny projekt od klienta, musieli go odrzuci\u0107 \u2013 nie mieli do\u015bwiadczenia w bardziej odpowiednich narz\u0119dziach.<\/p>\n Najbardziej niebezpieczny scenariusz to ten, w kt\u00f3rym dyskusja technologiczna zaczyna si\u0119 od \u201ejak to zrobi\u0107 w React\/Vue\/Angular\u201d, zamiast od \u201ejaki problem rozwi\u0105zujemy i jakie s\u0105 jego wymagania\u201d.<\/p>\n Przyk\u0142ad z platformy SaaS do zarz\u0105dzania projektami: zesp\u00f3\u0142 przez 2 miesi\u0105ce implementowa\u0142 edytor tekstu w React, korzystaj\u0105c z kilku bibliotek i pisz\u0105c setki linii kodu do zarz\u0105dzania stanem. Tymczasem prosty edytor oparty o ContentEditable z vanilla JavaScript i MutationObserver zrobi\u0142by to samo z 10-krotnie mniejszym bundle size i lepsz\u0105 responsywno\u015bci\u0105.<\/p>\n Obserwacja z rynku:<\/strong> firmy, kt\u00f3re najszybciej adaptuj\u0105 nowe technologie, nie maj\u0105 jednego \u015bwi\u0119tego frameworku. Maj\u0105 natomiast kultur\u0119 wyboru narz\u0119dzi pod problem, a nie problemu pod narz\u0119dzia.<\/p>\n Standaryzacja ma ogromne zalety \u2013 redukuje koszty szkole\u0144, u\u0142atwia wsp\u00f3\u0142prac\u0119 mi\u0119dzy zespo\u0142ami, pozwala budowa\u0107 wsp\u00f3lne biblioteki komponent\u00f3w. Ale musi by\u0107 m\u0105dra:<\/p>\n Standardy technologiczne, a nie frameworkowe<\/strong> \u2013 zamiast \u201eu\u017cywamy React\u201d, lepiej \u201eu\u017cywamy komponentowego podej\u015bcia z jednokierunkowym przep\u0142ywem danych\u201d. To pozostawia przestrze\u0144 na zmian\u0119 narz\u0119dzia, gdy pojawi si\u0119 lepsze rozwi\u0105zanie.<\/p>\n<\/li>\n 20% czasu na eksperymenty<\/strong> \u2013 niekt\u00f3re firmy (np. Spotify, Netflix) formalnie rezerwuj\u0105 cz\u0119\u015b\u0107 czasu developerskiego na testowanie nowych technologii. To nie jest czas stracony \u2013 to inwestycja w przysz\u0142\u0105 elastyczno\u015b\u0107.<\/p>\n<\/li>\n Proof of Concept jako obowi\u0105zek<\/strong> \u2013 dla ka\u017cdej nowej, znacz\u0105cej funkcjonalno\u015bci warto zrobi\u0107 PoC w 2-3 r\u00f3\u017cnych technologiach. Cz\u0119sto okazuje si\u0119, \u017ce \u201estandardowy\u201d framework wcale nie jest najlepszym wyborem.<\/p>\n<\/li>\n Architektura warstwowa<\/strong> \u2013 izoluj logik\u0119 biznesow\u0105 od frameworka. Je\u015bli ca\u0142a logika jest w Redux\/Vuex, zmiana frameworka oznacza przepisanie ca\u0142ej aplikacji. Je\u015bli logika jest w czystym JavaScripcie\/TypeScript, zmiana warstwy prezentacji to tygodnie, a nie miesi\u0105ce pracy.<\/p>\n<\/li>\n<\/ol>\n Dla founder\u00f3w i CTO: nadmierna standaryzacja framework\u00f3w to ryzyko technologicznego d\u0142ugu, kt\u00f3ry nie wida\u0107 w raportach. Zesp\u00f3\u0142 mo\u017ce dostarcza\u0107 funkcje na czas, kod mo\u017ce by\u0107 czysty, ale za 2-3 lata mo\u017ce si\u0119 okaza\u0107, \u017ce:<\/p>\n W JurskiTech.pl przy ka\u017cdym projekcie zaczynamy od pytania \u201ejaki problem biznesowy rozwi\u0105zujemy?\u201d. Dopiero potem wybieramy narz\u0119dzia. Czasem to React, czasem Vue, czasem Svelte, a czasem \u2013 co mo\u017ce zaskakiwa\u0107 \u2013 vanilla JavaScript z odrobin\u0105 Web Components. Bo framework to tylko narz\u0119dzie, a celem jest zawsze biznesowy efekt.<\/p>\n Standaryzacja w IT jest konieczna, ale musi s\u0142u\u017cy\u0107 biznesowi, a nie mu przeszkadza\u0107. Kiedy framework staje si\u0119 wa\u017cniejszy ni\u017c problem, kt\u00f3ry rozwi\u0105zuje, tracimy z oczu cel. Najlepsze zespo\u0142y developerskie to nie te, kt\u00f3re perfekcyjnie znaj\u0105 jeden framework, ale te, kt\u00f3re potrafi\u0105 wybra\u0107 najlepsze narz\u0119dzie do zadania \u2013 i maj\u0105 odwag\u0119 czasem wyj\u015b\u0107 poza \u201estandard\u201d.<\/p>\n W erze szybko zmieniaj\u0105cych si\u0119 technologii, elastyczno\u015b\u0107 technologiczna staje si\u0119 konkurencyjn\u0105 przewag\u0105. I to jest prawdziwy standard, do kt\u00f3rego warto d\u0105\u017cy\u0107.<\/p>\n","protected":false},"excerpt":{"rendered":" Jak nadmierna standaryzacja framework\u00f3w niszczy innowacje w IT: 3 przypadki W ci\u0105gu ostatnich pi\u0119ciu lat obserwuj\u0119 niepokoj\u0105cy trend w polskich firmach technologicznych: fetyszyzacj\u0119 framework\u00f3w. React, Vue, Angular, Next.js \u2013 sta\u0142y si\u0119 nie tylko narz\u0119dziami, ale wr\u0119cz religiami. Zespo\u0142y developerskie wybieraj\u0105 jeden framework i trzymaj\u0105 si\u0119 go jak przys\u0142owiowej deski ratunku, nawet gdy projekt ewoluuje w<\/p>\n","protected":false},"author":2,"featured_media":164,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[88,150,122,19,62],"class_list":["post-165","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-warto-wiedziec","tag-architektura-aplikacji","tag-frameworki","tag-innowacje","tag-web-development","tag-zespoly-developerskie"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/165","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=165"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/165\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media\/164"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=165"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=165"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=165"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}2. Standaryzacja, kt\u00f3ra zabija eksperymenty<\/h2>\n
3. Kultura \u201eframework first, problem second\u201d<\/h2>\n
Jak znale\u017a\u0107 z\u0142oty \u015brodek?<\/h2>\n
\n
Perspektywa biznesowa<\/h2>\n
\n
Podsumowanie<\/h2>\n