Vývoj webu 10 kódování Antipatterns musíte vyhnout

Návrh architektury webové stránky nebo aplikace nebo nastavení efektivního pracovního postupu kódování často způsobují, že se zabýváme opakujícími se problémy. Nemusíme nutně řešit tyto problémy s návrhem softwaru od nuly řešení na architektonické úrovni stejným způsobem jako kódu na mikroúrovni.

Designové vzory jsou obecně řešení pro některé scénáře to může hodit se k řešení běžně se vyskytujících problémů, a může nám pomoci optimalizovat náš kód.

Zatímco návrhové vzory jsou skvělým prostředkem ke zlepšení našeho vývojového procesu pomocí osvědčených vzorců, někdy se s nimi také můžeme pokazit. Tito jsou voláni antipatterns.

Co jsou Antipatternty?

Termín “antipattern” byl vytvořen v knize nazvané AntiPatterns v roce 1998. To se odkazuje na řešení, která se zpočátku jeví jako užitečná, ale později se ukáže udělat více škody než užitku.

To se může stát z různých důvodů, například pokud nepoužijeme vzorce ve správném kontextu, nastavení nebo čase (řešení, která byla účinná v minulosti, nemusí vždy fungovat v současnosti), nebo v jiných případech celé paradigma bylo od začátku jen špatné.

Antipatternty jsou také často nazývány selhání. Dobrou zprávou je, že je to rozpoznat a vyhnout se jim.

V tomto příspěvku se podíváme na 10 společných kódovacích antipatternů ve vývoji webu, které nás mohou klamat v tom, že máme dobře optimalizovaný kód. (Všimněte si, že antipatternty uvedené v tomto příspěvku nejsou nutně stejné jako ty, které najdete v knize uvedené výše.)

1. Předčasná optimalizace

Dobré načasování je klíčovým faktorem při optimalizaci kódu. Můžeme snadno reprodukovat antipattern “předčasná optimalizace”, pokud věnujeme pozornost malým efektivnostem a optimalizujeme pro ně příliš brzy v procesu vývoje, než budeme přesně vědět, co chceme dělat.

Podle slavné citace Donalda Knutha “předčasná optimalizace je kořenem všeho zla“, což může být přehnané, ale stále ukazuje, jak závažné problémy mohou předčasná optimalizace způsobit později.

Pokud budeme optimalizovat výkon před nastavením efektivní architektury, můžeme nižší čitelnost kódu, udělat ladění a údržba těžší, a přidejte zbytečné části na náš kód.

Aby se předešlo předčasné optimalizaci, je dobré se řídit principem programování YAGNI (You Arven Gonna Need It). “vždy realizujte věci, když je skutečně potřebujete, nikdy, když jen předvídáte, že je potřebujete.”

2. Znovuobjevení kola

“Objevit Ameriku” antipattern je někdy také odkazoval se na jak “projektování ve vakuu”. Stává se to, když chceme dělat všechno sami a psát všechno od nuly, bez hledání již existujících metod, rozhraní API nebo knihoven.

Znovuobjevení kola není jen časově zbytečná věc, ale zákaznická řešení, zejména pro základní funkce, jsou zřídka stejně dobrá jako standardní které již byly testovány mnoha vývojáři a uživateli.

3. Závislost pekla

Opak opaku “Objevit Ameriku” antipattern je další obyčejná antipattern volal “závislost peklo”.

Pokud místo toho, abychom psali všechno od nuly, používáme příliš mnoho knihoven třetích stran, které se spoléhají na specifické verze jiných knihoven, Můžeme snadno narazit na těžko zvládnutelnou situaci, kdy chceme aktualizovat, protože tyto vedlejší závislosti jsou v mnoha případech nekompatibilní.

Závislost pekla lze vyřešit pomocí správců balíčků, kteří jsou schopni inteligentně aktualizovat závislé závislosti. Pokud jsme problémem příliš zahlceni, může být také dobrý nápad.

4. Kodex špaget

“Kód špagety” je pravděpodobně nejznámější kódovací antipattern. Popisuje to aplikace, která je těžko laditelná nebo upravovaná z důvodu nedostatku správné architektury.

Výsledkem špatného návrhu softwaru je banda kódu, který je ve struktuře podobný struktuře mísy špaget, tzn. spletitý a spletitý. Čitelnost kódu špaget je velmi nízká a je to obvykle téměř nemožné poslání pochopit, jak to přesně funguje.

Kód špagety obvykle pochází z kombinace různých špatných postupů kódování, například kód, který neobsahuje správné podmíněné bloky, obsahuje mnoho příkazů goto, výjimky a podprocesy, které obsahují části, které patří jinam, má minimální vztahy mezi objekty, má funkce nebo metody, které nelze znovu použít, nebo není řádně zdokumentováno nebo vůbec.

5. Programování pomocí Permutace

“Programování permutací” nebo “programování náhodně” se stane, když se pokusíme najít řešení problému tím, že budeme postupně experimentovat s malými modifikacemi, testovat je a vyhodnocovat jeden po druhém a nakonec implementovat ten, který funguje zpočátku.

Programování pomocí permutace může snadno zavést do našeho kódu nové chyby, ještě horší, jsou chyby, které nemusíme nutně rozpoznat najednou. V mnoha případech je také nemožné předvídat, zda řešení bude fungovat pro všechny možné scénáře, či nikoliv.

6. Kopírování a vkládání programování

“Kopírování a vkládání programování” nastane, když nedodržíme princip kódování Don't Repeat Yourself (DRY) a místo vytváření obecných řešení vložíme již existující fragmenty kódu na různá místa a později je upravíme tak, aby se vešly do daného kontextu..

Tato praxe výsledkem je kód, který je vysoce opakovaný, vložené kódové části se obvykle liší pouze nepatrnými odchylkami.

Kopírování a vkládání programování není spácháno pouze začínajícími vývojáři, ale také zkušenými programátory, protože mnoho z nich je náchylných používat vlastní předpřipravené, dobře otestované úryvky kódu pro konkrétní úkoly, které mohou snadno vést neúmyslné opakování.

7. Programování nákladu-kult

Jméno “programování nákladu” pochází ze specifického etnografického fenoménu zvaného “kult kultury”. Kulty nákladu se objevily v jižním Tichomoří po druhé světové válce, když nucený kontakt s pokročilými civilizacemi vede domorodce myslet si, že vyráběné produkty, takový jako Coca-Cola, televize a ledničky přinesené nákladními loděmi k ostrovům, byl vytvořen nadpřirozeným metody; a pokud budou vykonávat magické obřady podobné zvykům Západu, znovu přijde náklad naplněný zbožím.

Když se dopustíme antipatternistického programování, v podstatě děláme totéž. Používáme rámce, knihovny, řešení, návrhové vzory atd., Které fungovaly dobře pro ostatní, bez pochopení, proč to děláme, nebo jak tyto technologie přesně fungují.

V mnoha případech jen vývojáři rituálně dělat to, co je hip v té době bez skutečného účelu. Tato praxe není jen špatná, protože dělá naši aplikaci nadbytečně nafouknutou, ale může také snadno zavést nové chyby do našeho kódu.

8. Lava Flow

Mluvíme o tom “lávový proud” antipattern, když potřebujeme s kódem, který má redundantní nebo nekvalitní díly že integrální k programu, ale zcela nerozumíme tomu, co dělá nebo jak ovlivňuje celou aplikaci. To je riskantní odstranit.

Obvykle se to děje starší kód, nebo když kód napsal někdo jiný (obvykle bez řádné dokumentace), nebo když se projekt posunul příliš rychle od vývoje do fáze výroby.

Jméno antipattern pochází z jeho vzhledu s lávou pocházející z sopek, tj. Zpočátku se pohybuje rychle a plynule, aniž by přijala příliš mnoho opatření, ale později ztuhne a stane se těžko odstranitelným..

Teoreticky se můžeme zbavit lávových proudů rozsáhlé testování a refaktorování, ale v praxi, provádění je často těžké nebo dokonce nemožné. Jelikož lávové proudy mají obvykle vysoké náklady na výkon, je lepší jim předcházet nastavením dobře navržené architektury a zvukového pracovního postupu od začátku.

9. Hard Coding

“Hard kódování” je známý antipattern, proti kterému nás v předmluvě varuje většina webových vývojářských knih. Hard kódování je nešťastná praxe, ve které ukládáme konfigurační nebo vstupní data, například cesta k souboru nebo název vzdáleného hostitele, ve zdrojovém kódu místo jeho získání z konfiguračního souboru, databáze, uživatelského vstupu nebo jiného externího zdroje.

Hlavní problém s pevným kódem je to funguje pouze v určitém prostředí, a na kdykoliv se podmínky změní, musíme změnit zdrojového kódu, obvykle na více samostatných místech.

10. Soft kódování

Pokud se velmi snažíme vyhnout nástrahám tvrdého kódování, můžeme snadno přejít do jiné antipatternové stanice “měkké kódování”, což je jeho přesný opak.

V měkkém kódování, vkládáme do externích zdrojů věci, které by měly být ve zdrojovém kódu, například ukládáme obchodní logiku do databáze. Nejčastějším důvodem, proč to děláme, je strach, že se obchodní pravidla v budoucnu změní, a proto budeme muset kód přepsat.

V extrémních případech může program s měkkým kódem být tak abstraktní a spletitý, že je téměř nemožné to pochopit (obzvláště pro nové členy týmu), a extrémně těžké udržovat a ladit.