Žiniatinklio kūrimas 10 kodavimo antpatternų, kurių reikia vengti

Svetainės ar programos architektūros projektavimas arba efektyvaus kodavimo darbo eigos nustatymas dažnai verčia mus spręsti pasikartojančias problemas. Mes nebūtinai turime išspręsti šias programinės įrangos projektavimo problemas nuo nulio, kaip sprendimai architektūros lygmeniu gali būti pakartotinai naudojami taip pat kaip ir kodo fragmentai mikro lygiu.

Dizaino modeliai paprastai yra daugkartinio naudojimo sprendimai tam tikrų scenarijų atveju patogu išspręsti dažniausiai pasitaikančias problemas, ir gali labai padėti mums optimizuoti savo kodą.

Nors dizaino modeliai yra puiki priemonė tobulinti mūsų vystymo procesą, naudojant gerai išbandytas formules, kartais taip pat galime su jais atsitikti. Tai vadinama antipatternais.

Kas yra antipatternai?

Terminas “antipattern” 1998 m. buvo sukurta knygoje „AntiPatterns“ pakartotinai naudojami sprendimai, kurie iš pradžių atrodo naudingi, bet vėliau paaiškėja daryti daugiau žalos nei naudos.

Tai gali atsitikti dėl įvairių priežasčių, pvz., Jei nenaudojame modelių teisingame kontekste, aplinkoje ar laikmečiu (sprendimai, kurie buvo veiksmingi praeityje, ne visada gali veikti dabar), arba kitais atvejais visa paradigma buvo tik blogai nuo pat pradžių.

Antipatternai taip pat dažnai vadinami nesėkmės modeliai. Geros naujienos yra tai, kad tai galima jas atpažinti ir išvengti.

Šiame pranešime mes pažvelgsime į 10 bendrų kodavimo antipatternų žiniatinklio kūrime, kurie gali mus apgaudyti mąstydami, kad turime gerai optimizuotą kodą. (Atkreipkite dėmesį, kad šiame pranešime išvardyti antipatternai nebūtinai yra tokie patys, kaip ir pirmiau minėtoje knygoje.)

1. Priešlaikinis optimizavimas

Geras laikas yra lemiamas veiksnys optimizuojant kodą. Mes galime lengvai atkurti antipatterną “ankstyvas optimizavimas”, jei mes atkreipiame dėmesį į mažą efektyvumą ir optimizuojame juos per anksti vystymosi procese, prieš tiksliai žinodami, ką norime padaryti.

Pagal garsųjį Donaldo Knuto citatą “ankstyvas optimizavimas yra visų blogio šaknis“, kuris gali būti perdėtas, tačiau vis dar rodo, kaip rimtos problemos gali atsirasti dėl ankstyvo optimizavimo.

Jei optimizuojame našumą prieš įdiegdami efektyvią architektūrą, mes galime mažesnis kodo skaitomumas, padaryti derinti ir prižiūrėti sunkiau, ir pridėti nereikalingas dalis prie mūsų kodo.

Siekiant užkirsti kelią ankstyvam optimizavimui, verta vadovautis programavimo principu „YAGNI“ („Jums nereikia“), kuri rekomenduoja “visada įgyvendinkite dalykus, kai juos iš tikrųjų reikia, niekada, kai tik tikitės, kad juos reikia.”

2. Rato išradimas

The “išradinėti ratą” antipatternas kartais vadinamas “projektavimas vakuume”. Tai atsitinka, kai norime viską daryti patys ir rašykite viską nuo nulio, ieškodami jau esamų metodų, API ar bibliotekų.

Rato išradimas yra ne tik laiko švaistymas, bet ir nestandartiniai sprendimai, ypač pagrindinėms funkcijoms, yra retai tokie patys kaip ir standartiniai kurie jau buvo išbandyti daugelio kūrėjų ir naudotojų.

3. Priklausomybė pragaras

Priešingai “išradinėti ratą” antipatternas yra dar vienas paplitęs antipatternas “priklausomybės pragaras”.

Jei vietoj rašymo viskas nuo nulio, mes naudojame per daug trečiųjų šalių bibliotekų, kurios remiasi konkrečiomis kitų bibliotekų versijomis, mes galime lengvai patekti į sunkiai valdomą situaciją, kai norime atnaujinti, nes šios papildomos priklausomybės yra daugeliu atvejų nesuderinamos tarpusavyje.

Priklausomybės pragarą galima išspręsti naudojant paketų valdytojus, kurie gali protingai atnaujinti tarpusavyje susijusias priklausomybes. Jei pernelyg daug užkrauname problema, refaktoravimas taip pat gali būti gera idėja.

4. Spageti kodas

“Spageti kodas” tikriausiai labiausiai žinomas kodavimo antipatternas. Ji aprašo programa, kurią sunku derinti ar keisti dėl tinkamos architektūros stokos.

Prastos programinės įrangos kūrimo rezultatas yra kodo krūva, kuri struktūroje yra panaši į spageti dubenį, t. susivėlęs ir susuktas. Spageti kodo skaitymas yra labai mažas, ir paprastai tai beveik neįmanoma misija suprasti, kaip tai tiksliai veikia.

Spageti kodas paprastai kyla iš skirtingų blogų kodavimo praktikų derinys, pvz., kodas, kuriame nėra tinkamų sąlyginių blokų, turintis daugybę „goto“ pareiškimų, išimčių ir siūlų, turinčių kažkur kitur esančių dalių, turi minimalų ryšį tarp objektų, turi funkcijų ar metodų, kurių negalima pakartotinai naudoti, arba kurių dokumentai nėra tinkamai panaudoti, iš viso.

5. Programavimas perjungimu

“Programavimas pagal permutaciją” arba “atsitiktinai” atsitinka, kai stengiamės rasti problemos sprendimą, eksperimentuodami nuosekliai su mažais pakeitimais, išbandydami ir vertindami juos po vieną ir pagaliau įgyvendindami tą, kuris veikia iš pradžių.

Programavimas permutacijomis gali būti lengvai atliekamas įvesti naujus klaidas į mūsų kodą, dar blogiau, jie yra klaidos, kurių mes nebūtinai neatpažįstame iš karto. Daugeliu atvejų neįmanoma numatyti, ar sprendimas veiks visiems galimiems scenarijams, ar ne.

6. Kopijuoti ir įklijuoti programavimą

“Kopijuoti ir įklijuoti programavimą” įvyksta, kai nesilaikome kodavimo principo „Neperžiūrėti sau (DRY)“, o vietoj bendrų sprendimų, į skirtingas vietas įtraukiame jau esamus kodo fragmentus ir vėliau juos redaguojame, kad jie atitiktų pateiktą kontekstą.

Ši praktika kodą, kuris yra labai pasikartojantis, kadangi įdėtos kodo dalys paprastai skiriasi tik nedideliais neatitikimais.

Nukopijuokite ir įklijuokite programavimą ne tik pradedantiesiems kūrėjams, bet ir patyrusiems programuotojams, nes daugelis jų yra linkę naudokite savo iš anksto parašytus, gerai išbandytus kodo fragmentus tam tikroms užduotims atlikti, kurios gali lengvai sukelti nenumatyti pakartojimai.

7. Krovinių ir kultūrų programavimas

Vardas “krovinių ir kultų programavimas” kilęs iš specifinio etnografinio reiškinio “krovinių kultas”. Po antrojo pasaulinio karo pietinėje Ramiojo vandenyno dalyje atsirado krovinių kultai, kai priverstinis ryšys su pažangiomis civilizacijomis paskatino vietinius žmones manyti, kad pagaminti produktai, tokie kaip Coca-Cola, televizoriai ir šaldytuvai, kuriuos krovinių laivai atnešė į salas, buvo sukurti antgamtiniais metodai; ir jei jie atliks stebuklingus apeigas, panašias į vakariečių papročius, krovinys, pripildytas prekėmis, vėl ateis.

Kai prisiimame krovinių-kultų programavimo antipatternaciją, mes iš esmės tai darome. Naudojame sistemas, bibliotekas, sprendimus, dizaino modelius ir kt., Kurie gerai veikė ir kitiems, nesuprasdami, kodėl tai darome, arba kaip šios technologijos tiksliai veikia.

Daugeliu atvejų kūrėjai tiesiog Ritoniškai tai, kas tuo metu yra klubo, be jokio realaus tikslo. Ši praktika yra ne tik bloga, nes dėl to mūsų paraiška yra pernelyg padidėjusi, tačiau ji taip pat gali lengvai įvesti naujas klaidas į mūsų kodą.

8. Lavos srautas

Mes kalbame apie “lavos srautas” antipattern, kai mums reikia elgtis su kodu, turinčiu nereikalingų ar žemos kokybės dalių kad atrodo neatskiriama į programą, tačiau mes visiškai nesuprantame, ką jis daro arba kaip jis daro poveikį visai programai. Dėl to yra rizikinga jį pašalinti.

Paprastai tai vyksta paliktas kodas, arba kai kodą parašė kažkas (paprastai be tinkamos dokumentacijos), arba kai projektas pernelyg greitai persikėlė nuo kūrimo iki gamybos etapo.

Antipatternas yra kilęs iš jo ištakų su ugnikalniais, ty iš pradžių jis greitai ir sklandžiai juda, neatsižvelgdamas į per daug atsargumo priemonių, bet vėliau kietėja ir tampa sunku pašalinti.

Teoriškai mes galime atsikratyti lavos srautų išsamūs bandymai ir refactoring, bet praktiškai, įgyvendinimas dažnai yra sunkus ar net neįmanomas. Kadangi lavos srautai paprastai turi didelių našumo sąnaudų, geriau juos užkirsti kelią sukuriant gerai suprojektuotą architektūrą ir patikimą darbo eigą nuo pat pradžių.

9. Kietasis kodavimas

“Kietasis kodavimas” yra gerai žinomas antipatternas, prieš kurį dauguma žiniatinklio kūrimo knygų mus įspėja iš anksto. Kietasis kodavimas yra gaila, kurioje mes saugome konfigūracijos ar įvesties duomenis, pvz., failo kelias arba nuotolinio kompiuterio pavadinimas, kodą o ne gauti jį iš konfigūracijos failo, duomenų bazės, vartotojo įvesties ar kito išorinio šaltinio.

Pagrindinė kietojo kodo problema yra ta, kad ji veikia tinkamai tam tikroje aplinkoje, ir ne bet kuriuo metu pasikeitus sąlygoms, turime pakeisti kodą, paprastai keliose skirtingose ​​vietose.

10. Minkštas kodavimas

Jei stengiamės išvengti sunkių kodų trūkumo, mes galime lengvai patekti į kitą vadinamą antipatterną “minkštas kodavimas”, tai yra visiškai priešinga.

Minkštuose kodavimuose, į išorinius šaltinius įtraukiame dalykus, kurie turėtų būti šaltinio kode, pavyzdžiui, duomenų bazėje saugome verslo logiką. Dažniausia priežastis, kodėl mes tai darome, yra baimė, kad verslo taisyklės ateityje pasikeis, todėl turėsime perrašyti kodą.

Ekstremaliais atvejais gali būti programuojama programa tapti tokie abstrakčiai ir sujaudinti, kad tai beveik neįmanoma suprasti (ypač naujiems komandos nariams) ir labai sunku išlaikyti ir derinti.