Nie da się ukryć, że obecnie programowanie jest łatwiejsze niż jeszcze kilkanaście lat temu. Przez ten czas wynaleziono wiele rozwiązań programistycznych i architektonicznych oraz powstały różnorakie wzorce i narzędzia pomagające w przygotowywaniu aplikacji. To nie oznacza, że kodowanie jest proste jak bułka z masłem - narzędzia mogą pomóc tylko przy tworzeniu konkretnych fragmentów oprogramowania, nadal wymagają wiedzy eksperckiej, a dodatkowo należy pamiętać, że znacznie zwiększyły się poziom złożoności aplikacji i oczekiwania użytkowników. Tym niemniej, jeśli jakakolwiek pomoc się przyda, to grzechem jest jej z niej nie skorzystać. Jednym z takich "kół ratunkowych" są bez wątpienia frameworki.

Są to niejako silniki do pisania aplikacji, które narzucają pewną strukturę, dostarczają przydatne biblioteki i pozwalają skupić się na implementowaniu właściwego kodu, bez tworzenia samych fundamentów np. systemu logowania, przekierowań itp. Myślę, że nie będzie przesadą, jeśli napiszę, że obecnie grubo ponad 90% aplikacji (także tych z najwyższej półki) powstały przy użyciu jednego z wielu frameworków, dzięki czemu ich tworzenie nie ciągnęło się w nieskończoność, a programiści mogli skoncentrować się na jakości dostarczanej użytkownikom. A sami użytkownicy - cieszyć się oprogramowaniem.

Istnieje jednak grupa osób, która twierdzi, że korzystanie z frameworka to niehonorowe pójście na skróty i w miarę możliwości aplikacje należy tworzyć od A do Z od podstaw (co to oznacza - dzisiaj jeszcze omówimy). Jako zawodowemu programiście zdarzało mi się spotykać (a niektóre nawet rozwijać jako legacy) duże systemy tworzone właśnie bez użycia silnika, a także widzieć różną postawę ludzi wobec nich w zależności od ich doświadczenia.

Przyjrzyjmy się zatem tematowi frameworków - czy (i kiedy) warto jest je stosować, a kiedy nie?

Czym jest biblioteka, framework, generator, CMS?

Zanim przejdziemy do właściwego tematu, warto wyjaśnić różnice pomiędzy tymi pojęciami, gdyż wcale oznaczają one tego samego.

Biblioteka to wydzielony zestaw kodu, który ułatwia realizację konkretnej czynności lub grup czynności. Przykładem może być biblioteka do obsługi danych w formacie JSON (odczyt, parsowanie, zapis, konwersja itd.), uwierzytelniania poprzez token JWT lub zestaw funkcji na łańcuchach tekstowych. Taki moduł (nie jest to precyzyjne określenie, ale na razie je przyjmijmy) jest zwykle tworzony osobno lub przy okazji tworzenia jakiegoś oprogramowania i udostępniany wewnątrz firmy bądź nawet publicznie. Pewną formą biblioteki może być wtyczka do strony (jak np. Feedybacky). Jest to zatem coś, co ułatwia nam tworzenie aplikacji (zwłaszcza, że zwykle korzystamy z wielu bibliotek naraz), ale jednocześnie nie może stanowić całego szablonu dla niej.

Takim szablonem, szkieletem czy też silnikiem dla danego języka programowania jest właśnie framework, który całkiem dobrze został opisany na polskiej Wikipedii:

Framework albo platforma programistyczna – szkielet do budowy aplikacji. Definiuje on strukturę aplikacji oraz ogólny mechanizm jej działania, a także dostarcza zestaw komponentów i bibliotek ogólnego przeznaczenia do wykonywania określonych zadań. Programista tworzy aplikację, rozbudowując i dostosowując poszczególne komponenty do wymagań realizowanego projektu, tworząc w ten sposób gotową aplikację.

O ile w jednej aplikacji możemy korzystać z wielu bibliotek, o tyle na jeden program przypada zwykle jeden framework. Tutaj jednak terminologia też nie jest ścisła - np. o Bootstrapie mówi się czasami, że jest to biblioteka, a niekiedy, że framework stylowania stron i ma to swoje uzasadnienie (wymusza konstrukcję widoków w odpowiedni sposób), więc w takim przypadku programista stosuje dwa lub więcej frameworków. Nie ma też przeszkód w tym, aby stosować różne frameworki do poszczególnych mikroserwisów lub integrujących się ze sobą fragmentów jednego systemu, choć nie należy z tym przesadzać (o czym jeszcze będzie dzisiaj mowa).

Taki szkielet nadal wymaga jednak programowania i osoba niebędąca specjalistą będzie miała problem z jego prawidłowym zastosowaniem. Czy istnieje zatem rozwiązanie pozwalające osobom mniej technicznym na samodzielne przygotowanie strony lub nawet uprzyjemniające programistom pracę w przypadku bardzo prostych mechanicznie aplikacji webowych? Owszem - jest to CMS, czyli Content Management System, pozwalający wyklikać i uzupełnić wszystko za pomocą panelu administratora. W tej klasie rozwiązań zdecydowany prym wiedzie znany wszystkim Wordpress, ale nie należy również zapominać o Drupalu czy CMS-ach poświęconych konkretnym zagadnieniom, jak np. e-commerce. Istnieje też koncepcja Headless CMS (przykładem jest Strapi), która umożliwia wyklikanie API i jest pewnym połączeniem generowania oraz programowania, gdyż w tym przypadku produktem wynikowym nie jest strona wraz z treścią, ale gotowy szkielet aplikacji, który należy uzupełnić.

Co to znaczy "od podstaw"?

To dobre pytanie i w zależności od kontekstu odpowiedź może być inna. Dla mnie "od podstaw" podczas rozważania problemu z/bez frameworka, polega na tym, że zaczynamy od samego języka programowania, jego biblioteki standardowej i ew. później dodajemy biblioteki zewnętrzne w miarę potrzeb (w końcu frameworki też często są dostarczane z polecanymi bibliotekami). Nie mamy zatem gotowych mechanizmów związanych np. z routingiem żądań HTTP, generowaniem widoków HTML czy uwierzytelnianiem i kontrolą uprawnień. Wszystko piszemy i projektujemy sami, co najwyżej inspirując się uznanymi rozwiązaniami. Wymaga to nie tylko dużej wiedzy o szczegółach języka, w którym się pisze kod, ale też mocy cierpliwości, gdyż nawet projektując tylko niezbędne nam mechanizmy, zajmie to więcej czasu niż skorzystanie z gotowego frameworka.

Ktoś inny mógłby powiedzieć, że dla niego pisanie od podstaw oznacza... właśnie użycie frameworka. Brzmi dziwnie, ale jeśli ktoś jest przyzwyczajony np. do tworzenia stron za pomocą Wordpressa, w którym posługuje się głównie konfigurowalnymi modułami czy widgetami, to tworzenie witryny poprzez programowanie wokół silnika może właśnie być "cofnięciem się do fundamentów". Jednak w dalszej części tekstu przyjmiemy definicję z poprzedniego akapitu.

Dlaczego frameworki mogą być dobre?

W świecie tworzenia gier pojawia się często podobny problem u amatorów, którzy rozważają pisanie własnego silnika. Dostają wówczas jasną odpowiedź: "jeśli chcesz pisać grę, wybierasz gotowy silnik. Jeśli chcesz pisać silnik, piszesz silnik przez wiele lat.". Można to dość prosto przełożyć na aplikacje webowe - jeśli nie masz naprawdę dużego doświadczenia i licznego zespołu, a musisz zrobić aplikację realizującą konkretne zadania (już nie mówiąc o czasie i budżecie przeznaczonym na jego realizację), to praktycznie zawsze powinieneś wybrać gotowe rozwiązanie, na którym budujesz właściwe oprogramowanie.

Jest to jednocześnie możliwość zapoznania się z naprawdę porządnym kawałkiem kodu i architektury oprogramowania - zauważmy, że frameworki są tworzone i rozwijane latami, często przy wsparciu wielu osób, które nawzajem się wspierają, kultywują dobre praktyki oraz recenzują swoje pomysły. Można zatem się spodziewać, że przynajmniej większość mechanizmów dostępnych w takich silnikach będzie naprawdę przemyślana i warto je podglądnąć oraz zrozumieć. Dodatkowo, im framework jest popularniejszy, tym zwykle też bardziej uniwersalny i zapewnia większość rzeczy potrzebnych do tworzenia aplikacji. Wisienką na torcie w przypadku aktywnych silników są społeczność, rozbudowana baza wiedzy (choćby w postaci zgłoszeń na Stack Overflow) oraz świadomość, że istnieją ludzie dbający o rozwój narzędzia, z którego korzystamy.

Użycie gotowego frameworka oznacza też, oczywiście, oszczędność czasu, który normalnie musielibyśmy poświęcić na pisanie wielu standardowych funkcji. Tym samym ta "droga na skróty" przekłada się na większą korzyść biznesową. Nie jest to też powód do wstydu. Przeciwnie - tak, jak pisałem, można się z takiego kodu wielu rzeczy nauczyć, także na przyszłość, gdybyśmy chcieli pisać własne narzędzie. Dodatkowo, niektórzy klienci mogą zapytać o to, czego używamy do programowania i wymienienie nazwy uznanego frameworka może dać nam dodatkowy plus w negocjacjach.

Dlaczego autorskie systemy mogą być dobre?

Czasami software house zajmuje się projektami dość małymi, realizowanymi z myślą o wyspecjalizowanych zadaniach i czasami użycie zwyczajowego dla nas frameworka może być nadmiarowe (mówimy czasami, że jest to "overkill" lub "strzelanie z armaty do mrówki"). W takich wypadkach albo zmienia się framework na mniejszy, albo... pisze się kod od podstaw.

W momencie, kiedy mamy naprawdę specyficzne wymagania, zależy nam bardzo na wydajności lub chcemy po prostu być pewni tego, co znajduje się w kodzie, możemy pokusić się o pisanie własnego silnika bądź przynajmniej jego części. Jest to wspaniała nauka (nawet dla doświadczonych programistów danego języka) i zapewnia dużo frajdy. Można też traktować taki projekt jako wstęp do rozwijania autorskiego narzędzia, które później jesteśmy w stanie skomercjalizować i się nim pochwalić. Mniej więcej w taki sposób światu ukazał się React od Facebooka.

Różnica pomiędzy amatorami a profesjonalistami

Wbrew pozorom jest to dość ważna kwestia, gdyż właśnie pomiędzy amatorami a profesjonalistami widać dużą różnicę w podejściu do korzystania z frameworków. W przypadku tych pierwszych czasami obserwuje się większą chęć pisania własnych narzędzi. Można to tłumaczyć zarówno młodzieńczą fantazją, dużą ilością wolnego czasu, jak i też niechęcią lub brakiem zaufania do gotowych narzędzi. O ile z dwoma pierwszymi powodami trudno dyskutować, o tyle ten ostatni jest niesłuszny - to właśnie początkujący powinni jak najszybciej uczyć się programować w gotowych szablonach, dzięki którym poznają i utrwalają sobie dobre praktyki. W taki sposób "rodzą się" profesjonaliści, którzy patrzą na wybór technologii stricte biznesowo - jeśli trzeba dostarczyć klientowi rozwiązanie w odpowiednim czasie i rywalizować przy tym z innymi wykonawcami, to siłą rzeczy frameworki będą preferowane, gdyż stanowią często niezbędną bazę do tego, aby zmieścić się w budżecie i skupić na samych wymaganiach.

Warto też wspomnieć o tym, że nie należy zamykać się na dane języki czy frameworki, co również niekiedy odróżnia amatorów od profesjonalistów. Prawdą jest, że im programista ma większe doświadczenie, tym mniejszą wagę przykłada do własnych preferencji technologicznych, a większą do tego, aby użyte narzędzie było najlepsze do danego zadania. Z tego powodu warto znać (lub przynajmniej kojarzyć) wiele frameworków i starać się je odpowiednio dobierać. Pomagają w tym mniejsze i mniej zyskowne projekty, w których można trochę poeksperymentować i odkryć coś nowego. Widać to często w architekturze mikroserwisowej, gdzie siłą rzeczy tworzymy osobne aplikacje do różnych zadań i nie ma obowiązku używania wszędzie jednego narzędzia. Z drugiej strony, profesjonalista też zdaje sobie sprawę z tego, że nadmierne mieszanie silnikami i korzystanie z różnych frameworków "dla sztuki" może zabrać nam czas, jakość i później spowodować problemy z rozwojem aplikacji, gdyż np. nie każdy programista w zespole będzie równie kompetentny w każdym fragmencie systemu.

Werdykt

Czy zatem warto korzystać z gotowych frameworków? Powiem tak - warto, a często nawet trzeba. Rekomenduję to podejście mniej doświadczonym, którzy dopiero stawiają pierwsze kroki w projektowaniu odpowiedniej architektury oprogramowania i potrzebują dobrych wzorców. Jednak polecam też bardziej doświadczonym, którzy często mierzą się z deadline'ami i muszą mieć narzędzie zapewniające solidne podstawy - wówczas odpowiedni framework jest jak znalazł. Tym niemniej, są sytuacje, w których autorski silnik może być dobrym pomysłem, choć należy wziąć pod uwagę, że w świecie profesjonalnym nie ma takich okazji zbyt wiele. Stąd wiele gotowych rozwiązań narodziło się z pracy po godzinach dla przyjemności nad autorskimi projektami różnych programistów.

Pozdrawiam i dziękuję - Jakub Rojek.