it-swarm-eu.dev

Kdy NEPOUŽÍVAT rámec

Dnes můžeme najít rámec pro téměř jakýkoli jazyk, aby vyhovoval téměř každému projektu. Většina moderních rámců je dosti robustní (obecně řečeno), s testováním každou hodinu, recenzovaným kódem a velkou rozšiřitelností.

Domnívám se však, že existuje nevýhoda jakéhokoli rámce v tom, že se programátoři, jako komunita, mohou stát tak závislými na svých zvolených rámcích, že již nerozumí základním činnostem, nebo v případě novějších programátorů, se nikdy základním činnostem nenaučí začít s. Je snadné se specializovat do té míry, že již nejste „programátorem PHP“ (například), ale „programátorem Drupalu“, s vyloučením všeho jiného.

Koho to zajímá, že? Máme rámec! Nepotřebujeme vědět, jak to „udělat ručně“! Že jo?

Výsledkem této ztráty základních dovedností (někdy do té míry, že programátoři, kteří nepoužívají používají rámce, jsou považováni za „zastaralé“) je, že se stává běžnou praxí používat rámec, kde to není vyžadováno. nebo vhodné. Rámec funkce usnadňuje ukončení zmatení s tím, co je základní jazyk schopen. Vývojáři začínají používat rámce pro splnění i těch nejzákladnějších úkolů, takže to, co bylo kdysi považováno za základní proces, nyní zahrnuje velké knihovny s jejich vlastními výstřednostmi, chybami a závislostmi. To, co bylo kdysi provedeno ve 20 řádcích, je nyní dosaženo zahrnutím rámce 20 000 řádků a zápisem 20 řádků pro použití rámce.

Naopak, jeden nechce znovu vynalézat kolo. Pokud píšu kód, abych splnil nějaký základní, obyčejný malý úkol, mohl bych se cítit, že ztrácím čas, když vím, že rámec XYZ nabízí všechny funkce, po kterých jsem, a mnohem víc. Část „mnohem víc“ mě stále znepokojuje, ale nezdá se, že by ji mnozí dokonce považovali.

Musí existovat dobrá metrika k určení, kdy je vhodné použít rámec. Co považujete za práh, jak se vy rozhodnete, kdy použít rámec, nebo kdy ne.

38
Chris

„Musí existovat dobrá metrika, aby bylo možné určit, kdy je vhodné použít rámec.“

Spíš ne. Kdyby existovaly dobré metriky pro určení vhodného použití jakékoli technologie, neviděli byste svaté války v jazyce, editoru a metodice.

Skupiny, se kterými jsem spolupracoval, dělají totéž - odhadněte si náklady a přínosy, zvolte nejproduktivnější cestu a doufejte, že mají pravdu. Není to strašně vědecké - jedna část intuice, tři části zkušenosti, jedna část náchylnost k marketingu, jedna část mazaný a pět částí hodnotí názor.

27
Corbin March

Rámce jsou jen nástroje. Nemyslím si, že je to chyba rámce, pokud je nadužívaná, spíše chyba osoby, která ji zneužívá. Staré přísloví „pokud máte kladivo, všechno vypadá jako hřebík“, ukazuje, že tento způsob myšlení existuje již dříve, než dokonce počítače.

Být příliš specializovaný se může v dlouhodobém horizontu skutečně stát problémem - pro vývojáře i pro biologické druhy. Pro dlouhodobé přežití je třeba pečlivě vyvážit úsilí o rozvoj jeho dovedností ve více oblastech.

Abych odpověděl na vaši konkrétní otázku, nemyslím si, že pro to existuje metrika. Dávám přednost použití rámce, když to zjednodušuje řešení problémů. Pokud mi použití rámce pomůže vyřešit problém se 2 řádky kódu namísto 20, zřejmě ho použiji. Ale i když je jeho 20 řádků proti 20, mohl bych se rozhodnout použít rámec, pokud mi poskytne lepší abstrakce, blíže k problémové doméně, což usnadní pochopení a údržbu kódu.

14
Péter Török

Myslím, že rámce mohou být v některých kontextech nadměrně využívány, ano. Rámec je jen nástroj, ano. Rámec umožňuje, aby se něco běželo velmi rychle, a jako takový je vynikajícím prototypovým nástrojem.

Zdá se mi, že někde v řadě, když vaše aplikace dosáhne určité úrovně složitosti, omezení vyplývající z rámce začínají potlačovat další růst. Trik spočívá v rozpoznání, kdy jste se setkali s takovým bodem zlomu, a pak se rozhodněte, co s tím uděláte.

6
leed25d

Většinou pracuji s webovými aplikacemi ai když se snažím být obecný, moje odpověď nemusí platit ve vaší oblasti programování.

Budu také používat „framework“ synonymický s „library“.


Před implementací rámce je třeba zvážit několik věcí, zde je několik obecných příkladů.

# 1. Ušetří rámec rámec a úsilí?

Odpověď na tuto otázku je téměř vždy ano . Rámce bývají stavěny k řešení specifických problémů a jejich řešení velmi dobře. Například rámce jako EntityFramework vám mohou ušetřit zcela z psaní kódu SQL. Což může být fantastické, pokud váš programovací tým neovládá plynule SQL.

Rámce jsou vytvořeny tak, že a) přidají programově příjemné rozhraní k jinak složitým komponentám, nebo b) přidají abstrakci již známým (nebo zavedeným) komponentám.

Posledně jmenovaný (nebo dokonce bývalý v některých případech) se může ve skutečnosti dostat do cesty vývoje. To platí , zvláště , když vy nebo váš programovací tým hodláte implementovat nový rámec, ve kterém nikdy předtím nepracovali.

Mohlo by to potenciálně zpomalit váš vývojový proces, což by mohlo být nákladné.

# 2 Měřítko vaší aplikace

Říká se, že „co stojí za to stojí za to přehánět“ , ale obvykle tomu tak není. Pravděpodobně neexistuje žádný dobrý důvod k implementaci super velké velikosti, pokud je cílem vaší aplikace tisknout „brambor“ .

Když vyvíjíte aplikaci (ať už je to web, desktop, mobilní nebo jakýkoli jiný myslitelný typ aplikace) - pokud máte pocit, že velikost vašeho rámce „trpaslíci“ vaši (možná budoucí) implementaci, pak to může být velká varovný signál, že váš rámec může vaši aplikaci jen nadýmat. Dobrou anekdotou by bylo, kdybyste zahrnuli jQuery, jen když do dokumentu vložíte třídu „načtenou“ do své značky těla. Pokud to uděláte jen s nativním JavaScriptem, může to být o trošku těžší , ale vaše aplikace nenabije.

Na druhé straně , pokud rámec dělá hodně špinavé práce na uvnitř (tj. databázové rámce), pak by mohlo být proveditelné jej implementovat, i když pouze používáte „částečně“ rámec. Dobrou anekdotou by bylo ne pokusit se vytvořit vlastní ovladač ADO.NET nebo MongoDB, jen proto, že nemusíte využívat celou knihovnu .

Rámce někdy přicházejí s otevřeným zdrojovým kódem (as licencemi „cokoli, co chcete“). To otevírá novou možnost, kdy se programovací tým může rozhodnout pouze pro části rámce.

To se nakonec vrací zpět k otázce 1 a 3.

Dopad # 3.

Někdy implementace rámce může přímo ovlivnit koncového uživatele. To platí zejména pro webové aplikace, protože velké rámce na straně klienta by mohly negativně ovlivnit zážitek koncového uživatele. Uživatelé s pomalejšími stroji mohou zaznamenat pomalé vykreslování, problémy s výkonem s javascriptem nebo podobné problémy způsobené pomocnými počítači. Uživatel s pomalým připojením může zaznamenat pomalé (alespoň počáteční) doby načítání.

Dokonce i v jiných typech aplikací mohou být vaši koncoví uživatelé negativně ovlivněni vašimi závislostmi na aplikacích. Rámce přinejmenším vždy zabírají nějaké místo na disku, a pokud vyvíjíte mobilní aplikaci (nebo dokonce stolní aplikaci), bude pravděpodobně nutné zabrat v úvahu.

Rámce na straně serveru (ještě více specifické pro web) pravděpodobně neovlivní vaše koncové uživatele, ale ovlivní vaši infrastrukturu . Některé rámce mají závislosti samotné , které mohou vyžadovat restartování webového serveru, buď pouze služby, nebo úplně serveru.

Některé rámce mohou být také velmi zdrojové.

To se samozřejmě váže zpět k bodům 1 a 2.


Je to všechno jen velký „okruh úvah“ a neexistuje žádná skutečná vědecká metoda pro rozhodování, zda byste měli implementovat rámec nebo ne.

Corbin March to shrnul velmi dobře:

Skupiny, se kterými jsem spolupracoval, dělají totéž - odhadněte si náklady a přínosy, zvolte nejproduktivnější cestu a doufejte, že mají pravdu. Není to strašně vědecké - jedna část intuice, tři části zkušenosti, jedna část náchylnost k marketingu, jedna část mazaný a pět částí hodnotí názor.

Je také důležité nebýt elitářem . Rámce jsou nástroje, které mají být použity. Znám lidi obou extrémů; na jedné straně máte toho chlapa, který dělá život velmi těžkým pro sebe, na druhé straně máte toho chlapa, který staví pomalé, nafouklé aplikace.

Všechny rámce mají případy použití, je to jen otázka jejich implementace pro správné účely.

6
die maus

Znají ostatní vývojáři rámec?

Pokud všichni vývojáři znají rámec X, pak vzhledem k tomu, že všechny ostatní důvody pro použití tohoto rámce jsou životaschopné, jděte na to! Podle mého názoru nemá smysl vynucovat učení konkrétního rámce, když se většina času na vývoj stráví učením složitosti rámce.

Pokud jde o vaše prohlášení o novějších programátorech, kteří neznají základy, jste mnohem soucitnější než já! Ano, je to škoda, ale budu trávit svůj čas starostí o něčí neschopnost? Nup. (Na základě předpokladu, že tito noví členové komunity s vámi nepracují okamžitě.)

4
J.K.

Rámec bych použil, pokud (a POUZE pokud) platí následující podmínky:

Zdá se, že rámec bude nějakou dobu podporován. Nechal jsem je, aby na mě skončili život, a je to opravdu otravné. Obzvláště, když jste 9 měsíců do svého projektu, a přepínání již ve skutečnosti není možnost. A pokud je rámec VŽDY již nepodporován, pak si třikrát promyslete, než napíšete něco nového pomocí tohoto rámce. Bez ohledu na to, jak dobře to už víte.

Projekt skutečně odpovídá rámci. Jako docela starý příklad, viděli jste věci, které MFC bylo vyrobeno udělat? Lidé neskončili s podivnými věcmi, aby to fungovalo pro typy aplikací, kde to prostě nedávalo smysl. Obvykle tráví více času bitím na MFC, než by strávili jen psaním aplikace, kterou chtěli rovnou.

Projektový tým je schopen pracovat v rámci. Někteří lidé nemají nebo nemohou mít čas pochopit, jak by aplikace měla být napsána v daném rámci, a místo toho píšou věci tak, jak obvykle dělají, místo toho, co rámec potřebuje. Tato nesprávná shoda mezi kódem a strukturou obvykle skončí stát každého hodně času a úsilí.

4
Michael Kohne