Blog | Frameworky vs DevStacky

Frameworky vs DevStacky

Jaké jsou klady a zápory v tom, že použijete framework vs to, že si nakombinujete dohromady několik knihoven?

Nejdřív si odlišme, co je framework a co je devstack.

Framework je skupina knihoven, které dohromady dávají ucelený přístup k řešení nějaké problematiky. Může se jednat o vývoj na frontendu, backendu, testování. Důležité je, že autor frameworku, ikdyž mohl použít pár existujících knihoven, si dal tu práci, aby sladil všechny knihovny dohromady tak, aby spolu fungovaly a navazovaly.

DevStack je skupina knihoven, které mohou pokrývat také celou problematiku. Autor devstacku často kombinuje i knihovny, které sám nevyvinul. Příslibem je, že vybrané knihovny kombinují to nejlepší, co se dá použít. Náklady na vývoj devstacku jsou nižší, neboť není nutné tolik vyvíjet ani dokumentovat. Někdy devstack obsahuje i třeba balíčkovací a buildovací nástroje, není ale žádné pravidlo, které by frameworku zakazovalo obsahovat totéž.

Dříve byla doba frameworků. Několik z nich uspělo a dodnes se rozšířily a používají je miliony vývojářů (např. .NET). Co se ukázalo, je, že framework je dost velká věc a vyvíjet svůj framework málokdy zvládne jednotlivec (David Grudl je unikát a na 1 Nette najdete nejspíš 100 neúspěchů).

Dnes je doba devstacků. Postavit si svůj devstack může člověk mnohem levněji (pokud ale chce vyvinout vše na míru, vznikne mu framework, takže kontrola je menší).

Obojí je/byl buzzword, ve kterém se lidé nechávají ovládat módou. Jak frameworky, tak devstacky mají své situace, kdy je vhodné je použít. Tento článek shrnuje klady a zápory obou přístupů.

Nevýhody devstacků

Aplikaci postavenou na devstacku musíte mnohem častěji předělávat. Totiž autoři frameworků se v každé major verzi snaží být kompatibilní.

Takže když chcete přejít z frameworku řady 1.X na 2.X, musíte předělávat. Ale z 1.3 na 1.4 obvykle ne.

I autoři knihoven, z kterých je devstack postaven, chtějí občas udělat nekompatibilní změnu a nechávají si to na major verze. Takže autor knihovny je nekompatibilní při přechodu z verze 1.X na 2.X, ale je kompatibilní při přechodu z 1.3 na 1.4.

Tyto vydání nekompatibilních verzí se dějí s nějakou frekvencí.

Když budete mít 1 framework, obvykle vydržíte třeba 2 roky bez nutnosti přepisu.

Když použijete devstack složený z 6 knihoven a nekompatibilní verze knihovny vyjde cca co stejné 2 roky, musíte svou aplikaci předělávat každé 4 měsíce.

Devstack znamená vyšší náklady na údržbu, než framework. A u netriviálních aplikací je mnohdy téměř nemožné dokončit aplikaci za současného použití nejnovějších verzí všech knihoven.

Výhody devstacků

Výhodou devstacku je to, že použijete právě to, co vám vyhovuje. Že si nakombinujete knihovny tak, aby vyhovovaly vaším potřebám. Ať už v případě, že chcete bleeding edge, nebo použijete stabilnější knihovny.

Pokud neexistuje žádný framework, který by uměl právě to, co potřebujete, nebo pokud jsou existující frameworky příliš těžkopádné, může pro vás být devstack řešením.

V posledním informačním systému, který jsem vyvinul, jsem použil devstack složený z Ringu, Hiccupu, Timbre, Kormy, Envirou, Route Once, Midje a několika dalších knihoven. Pravda je, že už teď jsem o několik verzí pozadu. Některé věci půjdou aktualizovat snadno, u jiných… nevím.

Nevýhody frameworků

Součástí frameworku je i pevně daný styl vývoje. Autor, kromě toho, že něco vyvíjí, i předpokládá určitý způsob použití. Tohle patří do controllerů a tohle zase do modelů a když to uděláte jinak, dřív nebo později na své nestandardní použití frameworku narazíte.

Nelze psát Nette stylem v Zendu. Nejde psát Zendím stylem v Code Igniteru atd. A mnohdy musíte použít to, co ve frameworku je, ikdyž je ten koncept dávno překonaný a zbytek frameworku je zároveň v pořádku.

Například ActiveRecord v Rails. AR je koncept, který opouštějí skoro všechny frameworky směrem k Data Mapperu. I pro Rails vznikl DM, jenže se nerozšířil. Není divu, když všechny knihovny a rozšíření pracující s databází pro Rails, na ActiveRecordu závisí.

Ber vše, nebo nech být.

Výhody frameworků

Framework je jistota v tom, že bude fungovat pohromadě. Že nebude duplikovat funkcionalitu. Že datové struktury jedné knihovny půjdou použít v další. Že je konzistentně zdokumentovaný.

Jakmile použijete framework, o který se někdo stará, nestane se, že vám z něj nějakou knihovnu přestanou podporovat, protože… se dostal zrovna do módy trochu jiný způsob toho, jak pracovat s databází/ša­blonami/testy.

Závěr

Pokud chcete vyvíjet menší věci, chcete bleeding edge, nenašli jste vyhovující framework, použijte devstack. Pokud na vaši problematiku existuje framework, je podporovaný, rozvíjí se a není zastaralý, použijte framework.

Programování

Předejte zkušenosti i dalším a sdílejte tento článek!



Jiří Knesl
Business & IT konzultant

Jiří Knesl poprvé začal programovat v roce 1993. Od té doby, díky skvělým učitelům a později zákazníkům, měl možnost neustále růst v oboru vývoje webových aplikací a informačních systémů. v roce 2002 se přidal zájem o ekonomii a v roce 2006 o organizaci práce. Vším tím se konstantně profesně zabývá jak ve svém podnikání, tak i u zákazníků. Za posledních 5 let vydal na tato témata přes 400 článků.

Prohlédněte si moje reference

Mám zkušenosti z rozsáhlých projektů pro korporace, velké podniky, střední i malé firmy, ale i pro startupy v cloudu. Zvyšoval jsem jejich know-how, pomáhal nastavovat jejich organizační strukturu, byl lektorem a mentorem v náročných situacích. Podívejte se, jak vidí můj přínos samotní klienti.

Sledujte mé postřehy na sociálních sítích