niedziela, 19 października 2008

Szkielety, zręby, rusztowania, ruiny

Zbieram sobie spokojnie materiały do prezentacji o Inversion of Control w Springu (w sumie to raczej o Springu:) na potrzeby naszego JUG. Aż tu nagle... prowokujący post Piotrka.

Jako wstęp do pracy nad prezentacją o Springu, dziś będzie o frameworkach w ogóle.

Najpierw należy odróżnić framework od biblioteki. Biblioteka to będzie chyba zbiór reużywalnych i sprawdzonych kawałków kodu skupionych wokół jakiegoś problemu. Nie będę tutaj silił się na definicję, wiadomo o co chodzi (jeżeli ktoś się chce do niej przyczepić to proszę bardzo;P). Ogólnie sytuacja jest taka: masz zestaw klas czy procedur (w wersji oldskulowej) i radź sobie. Składaj je w coś większego.
Natomiast framework ma już swą formę. Jest rozwiązaniem ogólnym, w którym brakuje jedynie szczegółów, które to musimy właśnie zdefiniować. Coś jak wypełnianie szkieletu mięsem. Zazwyczaj zajmuje się powtarzalnymi szczegółami technicznymi - dla nas zostaje biznes. Przynajmniej takie są założenia;)
Jeszcze jedna kategoria: zaznaczam, że nie chcę wyjść na zarozumiałego dupka, który lepiej od twórców Springa wie czym jest Spring, ale wydaje mi się, że jest on biblioteką frameworków a nie frameworkiem.


Komentując posta podlinkowanego przez Piotrka... Rzeczywiście jest tak, że jakaś część programistów podchodzi do frameworków z oporem. Dziwne, bo wydaje mi się, że prędzej czy później każdy jakieś swoje nano-frameworki tworzy. Jest to chyba immanentna cecha programistów, którzy uchwycili w pewnym momencie Object Oriented. Najpierw zaczynasz od uogólnień i abstrakcji. Projekt cieszy swą elegancją i prostotą - cieszy to niestety tylko Ciebie i ew. paru kolegów. Później w razie potrzeby refaktoryzacja do paru wzorców projektowych oraz wyciągnięcie konfiguracji na zewnątrz kodu. Okazuje się, ze konfiguracji jest zbyt wiele (koszmar XML), więc idąc z duchem czasu stawiamy na Convention Over Configuration. I quasi-framework gotowy. Heh hiestety zazwyczaj jego życie trwa jeden projekt bo do innych się nie nadaje... jest zbyt mało ogólny - ale to szczegół.

Z drugiej strony... frameworki budzą niechęć. Z obserwacji wydaje mi się, że przyczyny mogą być różne:

ignorancja - w przypadku niektórych frameworków bez biegłości w OO i wzorcach projektowych może być niestety ciężko połapać się o co chodzi w danym frameworku. Przytłacza on swą pozorną (bo wynikającą z niewiedzy) złożonością. Patrząc bardziej ogólnie problem może polegać na niechęci do zmian i poznawania nowych rzeczy.

pycha - jest jakaś część programistów, która nie wyrosła jeszcze ze śpioszków i twierdzą, że każdą kupę potrafią zrobić sami. Więc radośnie wynajdują np ORM na nowo. Tworzą coś co już zostało napisane zamiast skupić się na rozwiązaniu problemu klienta (biznesowego problemu). Bo ja sam UMIE i nie potrzebuje tutaj niczyjej pomocy a wzorce są dla cieniasów - Nie no fajnie, ale to do cholery kosztuje! Oczywiście niektórzy z czasem dochodzą do poziomu na którym ich rozwiązania są reużywalne - powstają wówczas chałupnicze nano-frameworki domowej roboty. Pycha każe im sądzić, że są one lepsze i mają mniej bugów niż coś co powstało w silnym community. Patrząc bardziej ogólnie: pyszne Zosie Samosie gardzą nie tylko frameworkami ale i oldskulowymi bibliotekami - po prostu wszystkim czego same radośnie nie spłodziły.

lenistwo - lepiej samemu coś napisać niż wertować strony dokumentacji istniejącego frameworka. Do tego jeszcze tony konfiguracji (niestety nasz własny framework jeżeli ma być frameworkiem też będzie musiał być jakoś konfigurowalny:P). Oczywiście na krótką metę lub w małych projektach pisanie z palca może być bardziej opłacalne. Patrząc bardziej ogólnie: co z samorozwojem? Przyjrzenie się architekturze sprawdzonego rozwiązania zazwyczaj otwiera nowe furtki w mózgu - pewne konstrukcje projektowe mogą być na prawdę inspirujące.

Kwestia najważniejsza: tytułowe ruiny. Frameworki (nawet te poważne i "oficjalne") nie zawsze muszą być arcydziełem. Nie koniecznie muszą rzeczywiście wspierać nas w rozwiązaniu problemu. W praktyce mogą przeszkadzać i irytować. Np taki JSF - wydaje się być zaprojektowany przez doskonałych inżynierów oprogramowania, którzy jednak niestety chyba nigdy w życiu nie popełnili żadnej aplikacji webowej (choćby w php).

//===================
Dobry framework powinien być tak zaprojektowany aby można było wymienić w nim nie tylko "mięcho" ale również część niego samego, czyli "szkieletu". Stąd chyba w Springu tyle interfejsów w bardziej jak i mniej newralgicznych miejscach:)

4 komentarze:

Koziołek pisze...

Czasami jest też tak, że widząc framework staramy się go uprościć. W takich przypadkach piękny łabędź zmienia się w brzydkie kaczątko.

Sławek Sobótka pisze...

Tak, znam to...
Może to polegać na przykryciu frameoworka fasadą i strywializowaniu jego konstruktów do paczek procedur.

//===============
A jako uzupełnienie posta dodam jeszcze aspekt, o którym zapomniałem napisać. Frameworki pozwalają odnaleźć się w projekcie. Nie oszukujmy się... firmy stosujące metodyki chałupniczo garażowe nie dbają o analizę, architekturę ani projekt. Dokumentacja to niepotrzebne koszty. Rotacja studentów jest kolejnym problemem. W projektach opartych na polucjach pyszałków nowi członkowie stają przed zadaniem praktycznie niemożliwym - zrozumieć o co chodzi.

Frameworki (o ile dobrze zrozumiane) mogą być jakimś skrawkiem znajomego lądu, od którego można zacząć eksplorację nieznanej dżungli systemu. Są wspólną płaszczyzną porozumienia pomiędzy nowymi skazańcami na Shawshank a ich poprzednikami. Skoro nie ma dokumentacji to można przynajmniej szukać elementów charakterystycznych dla danego frameworka.

Piotr Paradzinski pisze...

Dzięki za bardzo ciekawą odpowiedź.

Są frameworki które mniej zachwycają. To może być jednak ocena subiektywna (np złe doświadczenia w projekcie do którego framework się nie nadawał). Ba ocena może być zależna od wersji! Posiąść dostatecznie dobrą wiedzę i aktualizować ją - to wyzwanie.

Jedynym sposobem na poznanie frameworków jest ich używanie. Trochę mija zanim nauczymy się machać cepem, a to i owo można sobie zmiażdżyć po drodze. Zatem frameworkami można się cieszyć (mądrze wybierać i sprawnie się posługiwać) dopiero po osiągnięciu pewnego stopnia zaawansowania. Wcześniej trzeba przejść fazę potu i łez lub jak kto woli przekleństw i popełniania "prowokujących postów" :D

Pozdr. od leniwego ignoranta ;)

Sławek Sobótka pisze...

Piotrek - o to właśnie chodzi... próbować, smakować i obiektywnie oceniać - ale nie pochopnie.

Natomiast to co wypisuje Benji Smith rozsierdziło mnie jak rzadko kiedy. No i jeszcze na dodatek to jego resume... cóż za narcystyczne indywiduum;)