Frameworky vs DevStacky
Jaké jsou klady a zápory v tom, že použijete framework vs. to, že si nakombinujete dohromady několik knihoven?
Článek původně vyšel na autorově blogu.
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, i když 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.
Zrychlete svůj vývoj! Vyvíjejte rychleji, kvalitněji a mějte spokojenější zákazníky. Získejte Školení Scrumu.
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, i když 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í/šablonami/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.
Jiří Knesl
Jiří Knesl se zabývá hlavně Scrumem a správným vývojem software (prevence chyb, vyšší produktivita).
Framework je v první řadě sada názorů, myšlenek a vzorů, jak věci uspořádat, aby podle těch myšlenek fungovaly. Jestli obsahuje nějaké knihovny, nebo jiné nástroje, je až druhořadé.
DevStack je sada nástrojů, které používáme k vývoji.
Co je u obou důležité, že odráží nějakou potřebu/názor, jak by se věci měly dělat a ten potom replikuje i na případy, na které to vhodné není. Každý projekt má jinou sadu požadavků/omezení, na které je třeba pružně reagovat. Oba mohou sloužit jako inspirace, ale nepokoušejte se o cargo-cult, ke kterému to celé svádí.
Ano, je pravda, že framework je v první řadě ucelený přístup. „Zachycený způsob práce“, kdy se často používané knihovny vytknou před závorku, ale framework jen ty knihovny přesahuje. Ale to i v článku tvrdím.
Pěkně vystihnuté v článku. Přidám osobní zkušenost s konkrétním devstackem – Este.js.
Máme ho v produkci, na několika projektech, jednu ze starších verzí. Tisíce hodin frontend vývojářů. Aplikace je poměrně robustní. Je to i rychlé. Problém, s kterým se od počátku vývoje setkáváme je, že je prakticky nemožné updatovat na novější verzi. Každý měsíc se „tady něco přidá, tady něco odebere“. Chápu, je to jeho devstack, může si s ním dělat co chce. Když se rozhodne, že každý den tam přidá novou technologii která zrovna letí, tak si ji tam může dát a já můžu akorát držet hubu.
Ponaučení?
Pokud se rozhodnete použít něcí devstack, zamyslete se nad tím, jak ho chcete používat. Projdětě si commity a zjistětě si jak často se něco mění a zvažte, jestli vám případné BC nebudou dělat potíže.
My už si změny z upstreamu bohužel nikdy nepullneme… Je to škoda. Celkově se mi (i ostatním v teamu) Este zamlouvalo. Bohužel je to tak nekonzistentní, že už ho asi nikdy přímo nepoužijeme.
Peace.
Nevím nevím, přijde mi ten článek chaotický a doporučení zavádějící. Pokud chci stabilitu vyberu si stabilní verzi a na té projekt realizuju, ne? A nemám polovinu problémů, kterými se článek zabývá.
Problém je v tom, že i ty stabilní verze knihoven, z kterých je devstack složen, mají Nkrát větší šanci, že dojde k změně v major verzi, která bývá nekompatibilní (N je počet použitých knihoven).
Ano, to platilo o starém Este.js a štvalo mne to taky. Staré Este.js byl dev stack + framework. Nové Este už je pouze dev stack. Už tam není můj kód (krom pár řádku), ale patterny, praktiky, a doporučené knihovny.
Zajimalo by me, jakym zpusobem by vlastne takove pullnuti dev stacku melo fungovat? Z podstaty veci to neni jedna knihovna, ktera se verzuje a kterou si clovek hodi nekam do package.json a ocekava zpetnou kompatibilitu.
Dev stack je dobre si prostudovat a vyzobat si z neho knihovny/postupy, ktere se mi hodi. A tenhle proces opakovat treba jednou za ctvrt roku. Mrknout se, co je noveho, zda to potrebuji a zda to lze snadno nasadit. Co se tyce toho prostudovani, tak pulka se da v pripade JS dev stacku zvladnout pouze otevrenim package.json.