Związani Z Frameworkiem[2]

Frameworki to potężne narzędzia. Bez nich bylibyśmy zgubieni. Ale istnieje koszt używania frameworków.

---

---

Pomyśl o Rails, czy Springu, czy JSF czy Hibernate. Pomyśl o tym, jak pisałbyś systemy webowe bez pomocy tych frameworków. To wyobrażenie jest przygnębiające. Byłoby wtedy za dużo małych, upierdliwych szczegółów, z którymi musiałbyś sobie radzić. To byłoby jak zbudowanie obwodu pamięci mnemonicznej przy użyciu kamiennych noży i niedźwiedziej skóry[1].

A więc radośnie łączymy nasz kod ściśle z frameworkami w oczekiwaniu tych wszystkich obiecanych zysków. Popełniamy przy tym błąd, który popełniło już tak wielu programistów przed nami. Związujemy się z frameworkiem.

Użycie frameworku wymaga znaczącego zaangażowania. Akceptując framework w swoim kodzie, tracisz kontrolę nad szczegółami, którymi zarządza framework. Oczywiście wydaje się to być dobre; i zwykle jest. Jednakże pułapka czyha tuż za rogiem; i jest ciężko spostrzec ją w porę. Zanim się zorientujesz, jesteś zaangażowany we wszelkiego rodzaju nienaturalne działania, dziedzicząc z klas bazowych frameworku, rezygnując z coraz większej ilości kontroli przepływu sterowania, kłaniając się coraz głębiej konwencjom frameworku, jego dziwactwom i ekscentryzmom.

I pomimo Twojego ogromnego zaangażowania zrobionego w kierunku frameworku, framework nie odwzajemnił Ci się żadnym zaangażowaniem w Twoim kierunku. Framework łatwo ewoluuje w każdym kierunku, jaki tylko zadowala jego autora. A kiedy to robi, zdajesz sobie sprawę, iż będziesz musiał podążać za nim grzecznie, jak wierny szczeniak.

Przywiązywanie się do frameworku zachodzi zbyt często wśród członków zespołów programistycznych. Zaczynają z dzikim entuzjazmem i chętnie wiążą swój kod z frameworkiem, tylko po to, żeby dużo później, wraz z rozwojem projektu, przekonać się, iż framework staje im na drodze.

To nie powinno być zaskakujące. Frameworki są pisane przez ludzi do rozwiązania konkretnych problemów, które tylko ci ludzie mają. Te problemy mogą być Twoje, ale one nie są Twoje. Ty masz inne problemy. W momencie, gdy Twoje problemy pokrywają się, framework może być niesamowicie pomocny. W momencie, gdy Twoje problemy są inne, framework może być ogromnym utrudnieniem.

TANSTAAFL!

Frameworki są pisane przez ludzi, a ludzie mają swoje własne motywy. Jednym z takich motywów może być sprawienie, abyś używał ich frameworku. Jako autor frameworków w przeszłości, mogę Ci powiedzieć, iż im więcej ludzi używa twoich frameworków, tym masz o sobie lepsze mniemanie. Duża część mojego dowartościowania samego siebie była związana z akceptacją moich frameworków przez innych ludzi.

Tutaj nie chcę wchodzić zbyt głęboko w psychoanalizę autorów frameworków. Autorzy frameworków nie są złymi ludźmi. W rzeczywistości, w przeważającej części, są bohaterami. Wielu bezinteresownie wypuszcza swój kod dla społeczności open source. Gdyby nie ci ludzie, nasze programistyczne żywota byłyby znacznie mniej przyjemne i produktywne.

Przedstawiłem tę kwestię autorów, ponieważ pomaga mi ona zrozumieć pewną mechanikę zależności pomiędzy autorami a użytkownikami frameworków.

Autorzy frameworków pokonają znaczne odległości, żeby tylko udało im się zagonić Cię do ich zagrody. Będą pisać artykuły i przemawiać na konferencjach. Dostarczą przykłady pokazujące, w jaki sposób możesz połączyć się ściśle, bardzo ściśle z ich kodem. Pokażą wszystkie korzyści, jakie ma takie ścisłe połączenie. Oni są przekonani, iż ich kod pomoże Ci, i będą ciężko pracować, żeby Cię o tym przekonać.

To jest zupełnie normalne i w żaden sposób nie jest niehonorowe. Po prostu chcą Cię mieć w swojej zagrodzie.

Jednakże, kiedy już będziesz w ich zagrodzie, ich zainteresowanie Tobą zmienia się w pewien sposób. To jest zdjęcie jednego z popularnych autorów frameworków mówiącego jego użytkownikom, co myśli o niektórych ich obawach. (Tylko dla dorosłych)

Przez te wszystkie lata, nabyłem zdrowego sceptyzmu dotyczącego frameworków. Mimo iż przyznaję, iż mogą być ekstremalnie użyteczne i zaoszczędzić ogrom czasu; również zdaję sobie sprawę, iż to kosztuje. Czasami te koszty rzeczywiście mogą być bardzo wysokie.

Więc, moją strategią jest trzymać frameworki takie, jak Spring, Hibernate, czy Rails na odległość wyciągniętych ramion; za granicami architektonicznymi. Najwięcej korzyści mam z nich korzystając z nich w taki sposób; i dzięki temu mam nad nimi bezlitosną przewagę.


Ale nie pozwalam tym frameworkom podchodzić zbyt blisko. Nie oddaję im mojej niezależności. I pozwalam mackom ich kodu grzebać w wysokopoziomowych zasadach moich systemów. Mogą dotykać moich drugoplanowych podsystemów; ale trzymam je z dala od kluczowej logiki biznesowej. Wysokopoziomowe zasady moich systemów nigdy nie powinny być dotykane przez frameworki.

[1] Star Trek: The City on the Edge of Forever, Harlan Ellison, 1967
[2] Przeprosiny

---

---