Tvorba webu 10 kódovacích protikladov, ktoré musíte vyhnúť

Navrhovanie architektúry webovej stránky alebo aplikácie alebo vytvorenie efektívneho kódovacieho pracovného postupu často nás vyrieši opakovanými problémami. Nemusíme nutne riešiť tieto problémy so softvérovým dizajnom od nuly, ako riešenia na architektonickej úrovni môžu byť opätovne použité rovnakým spôsobom ako fragmenty kódu na mikroúrovni.

Dizajnové vzory sú všeobecne opätovne použiteľné riešenia pre určité scenáre, ktoré môžu Pripravte sa na riešenie bežných problémov, a môže nám veľmi pomôcť optimalizovať náš kód.

Zatiaľ čo dizajnové vzory sú skvelým prostriedkom na zlepšenie nášho vývojového procesu pomocou osvedčených vzorcov, niekedy môžeme s nimi tiež pokaziť. Tieto sa nazývajú antipatterny.

Čo sú Antipatterny?

Termín “návrhový antivzor” bol vytvorený v knihe AntiPatterns v roku 1998. Odkazuje sa na to opäť použité riešenia, ktoré sa na začiatku zdajú byť užitočné, ale neskôr sa ukáže robiť viac škody ako dobrého.

Môže sa to stať z rôznych dôvodov, napríklad ak nepoužívame vzorky v správnom kontexte, nastavení alebo čase (riešenia, ktoré boli účinné v minulosti, nemusí vždy fungovať v súčasnosti), alebo v iných prípadoch celá paradigma bol od začiatku len zlý.

Antipatterny sú tiež často nazývané vzory zlyhania. Dobrou správou je, že je to je možné ich rozpoznať a vyhnúť sa.

V tomto príspevku sa budeme zaoberať 10 spoločnými kódovacími antipatternami vo vývoji webových stránok, ktoré nás môžu podviesť do myslenia, že máme dobre optimalizovaný kód. (Všimnite si, že antipatróny uvedené v tomto príspevku nie sú nevyhnutne rovnaké ako tie, ktoré nájdete vo vyššie uvedenej knihe.)

1. Predčasná optimalizácia

Dobré načasovanie je kľúčovým faktorom pri optimalizácii kódu. Môžeme ľahko reprodukovať antipattern “predčasná optimalizácia”, ak budeme venovať pozornosť malým efektívnosti a optimalizovať pre nich príliš skoro v procese vývoja, skôr ako presne vieme, čo chceme urobiť.

Podľa slávneho citátu Donalda Knutha “predčasná optimalizácia je koreňom všetkého zla“, čo môže byť prehnané, ale stále ukazuje, aké vážne problémy predčasná optimalizácia môže neskôr spôsobiť.

Ak budeme optimalizovať výkonnosť pred vytvorením efektívnej architektúry, môžeme nižšia čitateľnosť kódu, urobiť ladenie a údržbu, a pridať nadbytočné časti do nášho kódu.

Aby ste predišli predčasnej optimalizácii, je dobré dodržiavať programovací princíp YAGNI (You Do not Need It), ktorý odporúča “vždy, keď ich skutočne potrebujete, implementujte veci, nikdy keď predvídate, že ich potrebujete.”

2. Obnovenie kolesa

“opätovné objavovanie kolesa” antipattern je niekedy tiež označovaný ako “navrhovanie vo vákuu”. Stáva sa to, keď chceme robte všetko sami a napíšte všetko od začiatku, bez hľadania už existujúcich metód, API alebo knižníc.

Opätovné zavedenie kolesa nie je len vec, čo stráca čas, ale vlastné riešenia, hlavne pre základné funkcie, sú zriedka rovnako dobré ako štandardné ktoré už boli testované mnohými vývojármi a používateľmi.

3. Závislosť peklo

Opačný “opätovné objavovanie kolesa” protikladná je ďalšia spoločná protiponorková volala “závislosť peklo”.

Ak namiesto písania všetkého od začiatku používame príliš veľa knižníc tretích strán, ktoré sa spoliehajú na konkrétne verzie iných knižníc, môžeme ľahko naraziť na ťažko zvládnuteľnú situáciu, keď chceme aktualizovať, pretože tieto dcérske závislosti sú v mnohých prípadoch vzájomne nekompatibilné.

Závislosť peklo môže byť vyriešené pomocou správcov balíkov, ktoré sú schopné inteligentné aktualizovanie vzájomne závislých závislostí. Ak sme problémom príliš zahltení, refaktoring môže byť tiež dobrý nápad.

4. Kód špagiet

“Kód špagiet” je pravdepodobne najznámejší kódovací antipattern. Popisuje to aplikácia, ktorú je ťažké ladiť alebo upraviť z dôvodu nedostatku správnej architektúry.

Výsledkom zlého softvérového návrhu je veľa kódov, ktoré majú podobnú štruktúru ako miska špagiet, t. J. zamotané a spletité. Čitateľnosť kódu špagiet je veľmi nízka a zvyčajne je takmer nemožné pochopiť, ako presne funguje.

Kód špagiet obvykle pochádza z kombinácia rôznych zlých postupov kódovania, ako napríklad kód neobsahujúci riadne podmienené bloky, ktorý má veľa príkazov, výnimiek a vlákien, ktoré obsahujú časti, ktoré patria inde, má minimálne vzťahy medzi objektmi, má funkcie alebo metódy, ktoré nie je možné opätovne použiť alebo nie je správne zdokumentované vôbec.

5. Programovanie podľa permutácie

“Programovanie pomocou permutácie” alebo “programovať náhodne” sa stane, keď sa pokúsime nájsť riešenie problému postupným experimentovaním s malými úpravami, testovaním a vyhodnocovaním po jednom a nakoniec implementovaním toho, ktorý pracuje na prvom mieste.

Programovanie pomocou permutácie môže byť jednoduché zaviesť nové chyby do nášho kódu, ešte horšie, sú to chyby, ktoré nemusíme okamžite rozpoznať. V mnohých prípadoch je tiež nemožné predvídať, či riešenie bude pracovať pre všetky možné scenáre, alebo nie.

6. Kopírovať a prilepiť programovanie

“Kopírovať a prilepiť programovanie” sa vyskytuje, keď nedodržiavame princíp kódovania Neopakujte (DRY) a namiesto vytvárania všeobecných riešení vkladáme už existujúce útržky kódu na iné miesta a neskôr ich upravíme, aby sa zmestili do daného kontextu.

Táto prax Výsledkom je vysoko opakujúci sa kód, pretože vložené časti kódu sa zvyčajne líšia len v menších rozdieloch.

Kopírovanie a vloženie programovania nie je spáchané iba nováčikmi, ale aj skúsenými programátormi, pretože mnohí z nich sú náchylní používať vlastné predpísané, dobre otestované útržky kódu pre konkrétne úlohy, čo môže ľahko viesť neúmyselné opakovania.

7. Nakladanie s programom Cargo-Cult

Meno “program nákladného kultu” pochádza zo špecifického etnografického javu nazvaného “nákladný kult”. Nákladné kulty sa objavili v južnom Tichom oceáne po druhej svetovej vojne, keď nútený kontakt s pokročilými civilizáciami viedol domorodcov, aby si mysleli, že vyrábané výrobky, ako sú Coca-Cola, televízory a chladničky prinášané nákladnými loďami na ostrovy, boli vytvorené nadprirodzeným metódy; a ak budú vykonávať magické rituály podobné zvykom západných obyvateľov, tovar naplnený tovarom príde znova.

Keď sa zaväzujeme k protipohlavnosti programovania zaobchádzania s tovarom, v podstate to robíme rovnako. Používame rámce, knižnice, riešenia, návrhové vzory atď., Ktoré fungovali dobre pre ostatných, bez toho, aby sme pochopili, prečo to robíme, alebo ako tieto technológie presne fungujú.

V mnohých prípadoch vývojári jednoducho rituálne robiť to, čo je hip v tej dobe bez akéhokoľvek skutočného účelu. Táto prax nie je len zlá, pretože robí našu aplikáciu nadmerne nafúknutou, ale môže tiež ľahko predstaviť nové chyby do nášho kódu.

8. Lava Flow

Hovoríme o tom “prietok lávovej vody” keď to potrebujeme riešiť kód, ktorý má redundantné alebo nekvalitné diely že Zdá sa, že sú integrálne k programu, ale nedokážeme úplne pochopiť, čo robí, alebo ako to ovplyvňuje celú aplikáciu. To robí to riskantné ho odstrániť.

Zvyčajne sa to deje starší kód, alebo keď kód bol napísaný niekým iným (zvyčajne bez náležitej dokumentácie), alebo keď projekt prešiel príliš rýchlo od vývoja až po výrobnú fázu.

Názov antipatrónu pochádza z jeho podoby s lávou pochádzajúcou zo sopiek, tzn. Najprv sa pohybuje rýchlo a plynulo bez toho, aby prijal príliš veľa preventívnych opatrení, ale neskôr tuhne a stáva sa ťažké odstrániť.

Teoreticky sa môžeme zbaviť prúdov lávových sond rozsiahle testovanie a refactoring, ale v praxi, implementácia je často ťažká alebo dokonca nemožná. Keďže lávové toky zvyčajne majú vysoké výkonové náklady, je lepšie im predchádzať tým, že od začiatku vytvoríte dobre navrhnutú architektúru a kvalitné pracovné postupy.

9. Hard Coding

“Tvrdé kódovanie” je známy protiklad, proti ktorému väčšina knih o vývoji webu nás varuje práve v úvode. Tvrdé kódovanie je nešťastnou praxou ukladáme konfiguračné alebo vstupné údaje, ako je cesta k súboru alebo vzdialený názov hostiteľa, v zdrojovom kóde skôr než ho získať z konfiguračného súboru, databázy, užívateľského vstupu alebo iného externého zdroja.

Hlavným problémom s pevným kódom je to funguje to správne len v určitom prostredí, a na kedykoľvek sa podmienky zmenia, musíme zmeniť zdrojový kód, zvyčajne na viacerých samostatných miestach.

10. Mäkké kódovanie

Ak sa pokúsime veľmi ťažko zabrániť tomu, aby sme zabránili tomu, aby sme tvrdé kódovanie zablokovali, môžeme ľahko naraziť na inú protiponorkovú “soft kódovanie”, čo je jeho pravý opak.

V mäkkom kódovaní, dali sme do zdrojového kódu veci do zdrojového kódu, napríklad ukladáme obchodnú logiku do databázy. Najčastejším dôvodom, prečo tak urobíme, je strach, že sa pravidlá podnikania budú v budúcnosti meniť, a preto budeme musieť prepísať kód.

V extrémnych prípadoch môže soft-kódovaný program stať sa tak abstraktným a spletitým, že je takmer nemožné ho pochopiť (najmä pre nových členov tímu) a extrémne ťažko udržiavať a ladiť.