Strona główna ProgramowanieTeoria Kiedy korzystać z frameworka?

Kiedy korzystać z frameworka?

przez Mateusz Michalski
6 komentarzy 6,8K wizyt

Na ten temat krążą już legendy. Jedni kochają frameworki, a drudzy za nimi nie przepadają. Stwierdziłem, że dołożę swoje dwa grosze do tego tematu. Podzielę się swoim doświadczeniem, opinią i drobną analizą. Kiedy i czy korzystać z frameworka? Oto jest pytanie! 🤔

Co to jest framework?

Na początek warto w ogóle się zastanowić, czym framework jest i po co się go używa? Przecież można programować i tworzyć projekty bez niego. Tylko jak to najprościej wytłumaczyć, hmm…

Pewnie nie raz w swoim życiu miałeś przyjemność korzystać z kolorowanek (takich obrazków z konturami postaci i z pustymi polami do wypełnienia). Wyobraź sobie, że w świecie programistycznym obrazek jest aplikacją, framework konturem, a kod pełni rolę wypełnienia – koloru. Wiem, że nie jest to idealne wytłumaczenie ale daje pewien pogląd i wyobrażenie.

Wracając już do naszej technicznej terminologii. Framework to pewien szkielet/wzorzec, z którego można korzystać pisząc kod w konkretnym języku programowania. Dzięki niemu istnieje możliwość korzystania z wielu gotowych rozwiązań, z którymi zmierzyli się jego twórcy, oszczędzając nam czas i wysiłek. Co najczęściej wchodzi w jego skład?

  • struktura katalogów,
  • klasy,
  • konfiguracja,
  • adnotacje,
  • routing,
  • zbiór bibliotek,
  • polecenia i komendy,
  • itd.

Czy framework jest biblioteką?

Nie, choć są w pewnym sensie podobne. W przypadku biblioteki to programista wywołuje jej API i decyduje o tym w jakim miejscu i kiedy z niej skorzystać. Natomiast framework jest mechanizmem wywołującym kod programisty, dzieje się to w pewnym stopniu poza developerem i jego decyzyjnością.

TOP 10 WEB Frameworks - analyticsindiamag.com
Lista 10 najpopularniejszych frameworków, według statystyk z: https://analyticsindiamag.com

Powyższy raport dotyczący najpopularniejszych web frameworków można znaleźć TUTAJ. Jak można zauważyć, na czele są rozwiązania z rodziny JS. Nie mniej, na liście można znaleźć przedstawicieli takich języków jak Java, PHP, Python, Ruby, czy C#. Jak widać praktycznie każdy język ma swój framework (często niejeden!). 🙂

Framework = rozwiązanie idealne?

Niestety nie… chciałbym napisać, że framework będzie lekarstwem na każdy projekt ale tak nie jest. Jak to w życiu bywa coś kosztem czegoś. Trzeba pamiętać, że pewne ułatwienie w procesie developmentu ma swoją cenę… Co przychodzi mi do głowy jako pierwsze? 🧐

1. Utrata pełnej kontroli

Wyobraź sobie scenariusz, w którym okazuje się, że framework, na którym bazuje Twój system ma lukę w bezpieczeństwie. Co musisz zrobić? Zgłosić to do firmy lub społeczności opiekującej się technologią. Co Ci pozostaje? Czekać… Czekanie na łatkę w formie aktualizacji, może być realizowane „od ręki” lub niestety dopiero po jakimś czasie.

Drugi przykład jaki widzę, to brak wpływu na aspekty związane z optymalizacją. Przed skorzystaniem z gotowego rozwiązania, warto jest zrobić analizę dla przyszłego projektu i oszacować jaka wydajność będzie konieczna. Może się okazać, że wyniki osiągane przez dany framework nie będą wystarczające, a lepiej wiedzieć o tym przed rozpoczęciem projektu, niż w jego trakcie lub tuż po uruchomieniu produkcyjnym.

Przed napisaniem pierwszej linijki kodu, oprócz oszacowania potencjalnego obciążenia systemu, warto jest przewertować dokumentację i sprawdzić czy rozwiązanie spełnia wszystkie (albo chociaż część) z potrzebnych wymagań. Dobrze jest wiedzieć, czy framework nie będzie wąskim gardłem projektu lub wręcz przeciwnie, armatą do polowania na muchy. 😉

2. Aktualizacje

Mogą wydawać się ogromnym plusem, no bo przecież aktualizacje oznaczają rozwój! Z jednej strony oczywiście, że tak. Jednak z drugiej, oznaczają też utrzymanie i dostosowanie kodu aplikacji do nowych wytycznych i wymagań. Przy dużym projekcie może to generować spore wydatki, nieplanowane prace i problemy. Nie zawsze jest czas na wyrównywanie wersji i aktualizacje, co bardzo szybko może prowadzić do powstania tzw. długu technologicznego.

3. Koniec wsparcia

Gorszym momentem od kolejnej aktualizacji jest komunikat o nadchodzącym końcu wsparcia! Zdarzają się sytuacje, w których zespoły coraz rzadziej wydają aktualizacje lub co gorsza… kończą prace nad rozwojem. Może się tak zdarzać kiedy są to inicjatywy niekomercyjne lub kończy się finansowanie oraz budżet. Widzisz publikację oświadczenia kilka miesięcy przed ostatnią aktualizacją i co dalej? Zostajesz przy tym rozwiązaniu czy zmieniasz? Zmiana technologii pochłonie budżet i czas, którymi firmy nie zawsze dysponują…

Jest aż tak źle? 😱

Oczywiście, że nie! Frameworki mają swoje ogromne plusy i warto, a nawet trzeba o nich mówić. To jest idealny przykład dwóch stron medalu… mniej optymistyczną stronę już opisałem, a jaka jest ta lepsza?

1. Przyspieszony development

Nie ma co ukrywać, frameworki przyspieszają pracę i jest to niezaprzeczalne. Dają możliwość zaoszczędzenia sporej ilości czasu, co może mieć ogromne znaczenia zarówno dla małych i dużych firm. Często zdarza się, że zespoły pracują nad MVP (ang. Minimum viable product) produktu, który musi mieć swoją działającą formę w krótkim czasie. W takim przypadku, każde rozwiązanie ułatwiające development jest na wagę złota i czasem może decydować o być albo nie być firmy na rynku.

Rzecz jasna nie tylko projekty MVP są dobre na tego typu rozwiązania. Jeżeli przeanalizuje się wiele zmiennych i parametrów jakie powinny towarzyszyć przy planowaniu prac nad projektem i w ich wyniku uda się określić, że taki czy inny framework spełnia potrzeby, warto z niego korzystać! 🙂

2. Utrzymanie kodu i jakości przez innych

Co z jednej strony jest minusem, ma też swoje zalety. Pisałem o tym w punkcie o utracie do pewnego stopnia kontroli w projekcie. Warto pamiętać, że w takiej sytuacji zespół zostaje odciążony od utrzymania części oprogramowania, a odpowiedzialna za to jest niezależna firma. To w jej obowiązku powinno być chociażby przygotowanie dokumentacji, dzięki której można ponownie zaoszczędzić czas. Wdrożenie nowych osób do projektu zawsze trwa… a z gotową dokumentacją można to zoptymalizować. Próg wejścia w projekt jest znacznie mniejszy, a technologie podczas rekrutacji mogą być jasno i klarownie sprecyzowane.

Rozwiązania bez dokumentacji, community i oficjalnej linii wsparcie radziłbym omijać szerokim łukiem

3. Community i podobne problemy

O tym trzeba wspomnieć! Rozbudowane community to bardzo dobry znak. Dlaczego? Po pierwsze daje do wiadomości, że framework jest często używany i ma swoich zwolenników. Po drugie, społeczność może być bardzo przydatna w problemowych momentach. Jeżeli napotkamy jakiś problem, jest bardzo duże prawdopodobieństwo, że ktoś inny również się z nim zmierzył i możliwe, że opisał to w Internecie, np. na StackOverflow. 🙂

Podsumowanie

Trochę analizy za nami, to można się zastanowić, korzystać czy nie? Moim zdaniem ogromny wpływ na decyzję ma skład osobowy zespołu, który dany projekt ma realizować. Dlaczego? Nie każdy team ma ludzi z odpowiednim poziomem wiedzy i doświadczenia do budowania własnego rozwiązania. Tam na prawdę potrzebny jest kunszt, który często jest wynikiem błędów i problemów z wielu lat pracy. Własny szkielet wymaga szerokiej wiedzy na temat bezpieczeństwa, architektury, czystości kodu i sporej wiedzy z danego języka.

Oprócz tego należy mieć na uwadze, że zespoły się zmieniają. Ludzie przychodzą i odchodzą, a system trzeba rozwijać. Własny szkielet i rozwiązanie znacznie zwiększa próg wejścia w projekt, a nie zawsze wszystko jest udokumentowane. Są sekrety, o których wiedzą tylko autorzy…

Daj lajka i czytaj dalej 😉

Jeżeli chcesz być na bieżąco z artykułami i jesteś ciekawy co będzie dalej, daj lajka na naszym profilu FB, a przede wszystkim zapisz się do newslettera! Spodobał Ci się artykuł? Może zaciekawią Cię inne wpisy na naszym blogu.

Dzięki za Twój czas, widzimy się niebawem! 😉

4 28 votes
Oceny

Powiązane wpisy

Subscribe
Powiadom o
guest
6 komentarzy
Inline Feedbacks
View all comments

Strona wykorzystuje cookies i przetwarza dane zgodnie z zasadami opublikowanymi w Polityce Prywatności. Jeżeli nie wyrażasz zgody na przetwarzanie danych, zmień ustawienia swojej przeglądarki. Wybierając "OK", zgadzasz się na warunki przetwarzania. OK Więcej