Spletni razvoj 10 kodirnih antipatterns morate preprečiti
Oblikovanje arhitekture spletne strani ali aplikacije ali vzpostavitev učinkovitega delovnega poteka kodiranja nas pogosto motijo pri ponavljajočih se težavah. Ni nujno, da rešujemo te težave pri načrtovanju programske opreme iz nič, kot rešitve na arhitekturni ravni se lahko ponovno uporabijo enako kot odrezke kode na mikro ravni.
Oblikovni vzorci so na splošno rešitve za večkratno uporabo za nekatere scenarije koristno rešiti pogosto nastale težave, in nam lahko zelo pomagajo pri optimizaciji naše kode.
Čeprav so vzorci oblikovanja odlična sredstva za izboljšanje našega razvojnega procesa z dobro preizkušenimi formulami, včasih lahko tudi z njimi greva narobe. To se imenuje antipatterns.
Kaj so Antipatterns?
Izraz “antipattern” je bil skovan v knjigi AntiPatterns leta 1998. Nanaša se na ponovno uporabljene rešitve, ki se na začetku zdijo koristne, kasneje pa se izkaže narediti več škode kot koristi.
To se lahko zgodi iz različnih razlogov, na primer, če ne uporabljamo vzorcev v pravem kontekstu, okolju ali času (rešitve, ki so bile v preteklosti učinkovite, ne delujejo vedno v sedanjosti) ali v drugih primerih celotna paradigma od začetka je bilo slabo.
Pogosto se imenujejo tudi antipatterns vzorci neuspeha. Dobra novica je, da je jih je mogoče prepoznati in se jim izogniti.
V tem delu bomo imeli pogled na 10 običajnih kodirnih antipattern v razvoju spletnih strani, ki nas lahko zavedajo, da imamo dobro optimizirano kodo. (Upoštevajte, da antipatterns, ki so navedeni v tej objavi, niso nujno enaki tistim, ki jih najdete v zgoraj navedeni knjigi.)
1. Prezgodnja optimizacija
Dober čas je ključni dejavnik pri optimizaciji kode. Z lahkoto lahko reproduciramo antipattern “prezgodnja optimizacija”, če smo pozorni na majhno učinkovitost in jih čim prej optimiziramo v razvojnem procesu, preden natančno vemo, kaj želimo.
Glede na slavni citat Donalda Knutha “prezgodnja optimizacija je koren vsega zla“, kar je lahko pretiravanje, vendar še vedno kaže, kako lahko pozneje povzroči resna vprašanja.
Če optimiziramo učinkovitost pred vzpostavitvijo učinkovite arhitekture, lahko nižja berljivost kode, make odpravljanje napak in vzdrževanje, in dodamo odvečne dele v našo kodo.
Da bi preprečili prezgodnjo optimizacijo, je dobro upoštevati načelo programiranja YAGNI (ne potrebujete ga), ki svetuje “vedno izvajati stvari, ko jih dejansko potrebujete, nikoli, ko samo predvidevate, da jih potrebujete.”
2. Ponovno odkrivanje kolesa
The “ponovno odkrivanje kolesa” antipattern se včasih imenuje tudi kot “oblikovanje v vakuumu”. To se zgodi, ko želimo naredite vse sami in napišite vse od začetka, brez iskanja obstoječih metod, API-jev ali knjižnic.
Ponovno odkrivanje kolesa ni samo izguba časa, ampak prilagojene rešitve, zlasti za osnovne funkcionalnosti, so le redko tako dobre kot standardne ki so jih že testirali mnogi razvijalci in uporabniki.
3. Odvisnost Hell
Nasprotno od. \ T “ponovno odkrivanje kolesa” antipattern je še en skupni antipattern, imenovan “odvisnost od pekla”.
Če namesto pisanja vse od začetka uporabljamo preveč knjižnic tretjih oseb, ki se zanašajo na določene različice drugih knjižnic, ko želimo posodobiti, lahko zlahka naletimo na težko obvladljivo situacijo, saj so te odvisne odvisnosti v mnogih primerih nezdružljivi.
Odvisnost pekel je mogoče rešiti z uporabo paketnih upravljavcev, ki so sposobni pametno posodabljate soodvisne odvisnosti. Če nas problem preveč obremenjuje, je lahko tudi refactoring dobra ideja.
4. Koda špagetov
“Šifra špagetov” je verjetno najbolj znan antipattern. Opisuje aplikacijo, ki jo je težko odpraviti ali spremeniti zaradi pomanjkanja ustrezne arhitekture.
Posledica slabe zasnove programske opreme je vrsta kode, ki je po strukturi podobna skledi špagetov, tj. zapleten in zapleten. Bralnost špageti kode je zelo nizka in ponavadi je skoraj nemogoče razumeti, kako točno deluje.
Špageti običajno izvirajo iz kombinacija različnih praks slabega kodiranja, kot na primer koda, ki ne vsebuje blokov pravilnih pogojev, ki imajo veliko stavkov goto, izjeme in niti, ki vsebujejo dele, ki pripadajo nekje drugje, ima minimalna razmerja med objekti, ima funkcije ali metode, ki jih ni mogoče ponovno uporabiti, ali ni pravilno dokumentirana ali nasploh.
5. Programiranje s permutacijo
“Programiranje s permutacijo” ali “naključno programiranje” se zgodi, ko poskušamo najti rešitev za problem, tako da zaporedno eksperimentiramo z majhnimi modifikacijami, jih preskusimo in ocenimo enega za drugim in končno uresničimo tisto, ki deluje na prvi.
Programiranje s permutacijo je enostavno uvajate nove napake v našo kodo, Še huje, so hrošči, ki jih ne prepoznamo takoj. V mnogih primerih je tudi nemogoče predvideti, ali bo rešitev delovala za vse možne scenarije ali ne.
6. Programiranje kopiranja in lepljenja
“Programiranje za kopiranje in lepljenje” se zgodi, ko ne sledimo načelu kodiranja Ne ponovi sami (DRY), in namesto ustvarjanja generičnih rešitev vstavimo že obstoječe odrezke kode na različna mesta in jih pozneje uredimo, da se prilegajo danemu kontekstu.
Ta praksa rezultat je zelo ponavljajoča se koda, vstavljeni deli kode se običajno razlikujejo le v manjših odstopanjih.
Programiranje kopiranja in lepljenja ne opravljajo le razvijalci začetnikov, temveč tudi izkušeni programerji, saj so mnogi od njih nagnjeni k temu uporabite lastne vnaprej napisane, dobro preizkušene odrezke kode za določene naloge, do katerih lahko pride nenamerno ponavljanje.
7. Programiranje tovora s kljukami
Ime “programiranje v zvezi s tovorom” izhaja iz specifičnega etnografskega fenomena, imenovanega “tovorni kult”. Tovarniški kulti so se pojavili v južnem Pacifiku po drugi svetovni vojni, ko je prisilni stik z naprednimi civilizacijami vodil domorodce, da mislijo, da so izdelane izdelke, kot so Coca-Cola, televizorji in hladilniki, ki jih prinašajo tovorne ladje na otoke, ustvaril nadnaravni metode; in če opravljajo čarobne obrede, podobne običajem zahodnjakov, bo tovor, napolnjen z blagom, spet prišel.
Ko zavežemo antipattern za programiranje v kulturi tovora, v bistvu delamo enako. Uporabljamo okvire, knjižnice, rešitve, vzorce oblikovanja itd., Ki so dobro delovali za druge, ne razumem, zakaj to počnemo, ali kako tehnologije delujejo.
V mnogih primerih so razvijalci samo Ritualno delati tisto, kar je v tistem času hip, brez pravega namena. Ta praksa ni samo slaba, ker naredi našo aplikacijo nepotrebno napihnjeno, ampak lahko tudi preprosto vnaša nove napake v našo kodo.
8. Lava Flow
Govorimo o “pretok lave” antipattern, ko moramo obravnava kodo, ki ima odvečne ali nizke kakovosti dele to zdi se, da je sestavni del kljub temu ne razumemo, kaj počne ali kako vpliva na celotno aplikacijo. Zaradi tega je tvegano odstraniti.
Ponavadi se zgodi z obstoječe kode, ali ko. \ t kodo je napisal nekdo drug (običajno brez ustrezne dokumentacije) ali ko se je projekt prehitro preselil iz razvoja v fazo proizvodnje.
Ime antipattern izhaja iz njegove zvestobe z lavo, ki prihaja iz vulkanov, tj. Najprej se premika hitro in tekoče, ne da bi vzeli preveč previdnostnih ukrepov, kasneje pa se strdi in postane težko odstraniti..
V teoriji se lahko znebimo tokov lave obsežno testiranje in refactoring, vendar v praksi, izvajanje je pogosto težko ali celo nemogoče. Ker imajo pretoki lave običajno visoke stroške delovanja, jih je bolje preprečiti tako, da od začetka nastavite dobro zasnovano arhitekturo in dober potek dela..
9. Trdno kodiranje
“Trdno kodiranje” je dobro znana antipattern, proti kateri nas opozarja večina spletnih razvojnih knjig prav v predgovoru. Težko kodiranje je nesrečna praksa, v kateri shranjujemo konfiguracijske ali vhodne podatke, kot je pot datoteke ali ime oddaljenega gostitelja, v izvorni kodi namesto pridobivanja iz konfiguracijske datoteke, baze podatkov, uporabniškega vnosa ali drugega zunanjega vira.
Glavni problem s trdimi kodami je ta deluje samo v določenem okolju, in na kadar koli se pogoji spremenijo, moramo spremeniti izvorno kodo, običajno na več ločenih mestih.
10. Soft Coding
Če se zelo trudimo, da bi se izognili pasti trdega kodiranja, lahko zlahka naletimo na drugo antipattern imenovano “mehko kodiranje”, kar je ravno nasprotno.
V mehkem kodiranju, stvari, ki bi morale biti v izvorni kodi, postavimo v zunanje vire, poslovno logiko shranjujemo v podatkovno bazo. Najpogostejši razlog za to je strah, da se bodo poslovna pravila v prihodnosti spremenila, zato bomo morali kodo ponovno napisati..
V skrajnih primerih lahko program z mehkim kodiranjem postali tako abstraktni in zapleteni, da ga je skoraj nemogoče razumeti (predvsem za nove člane ekipe) in izjemno težko vzdrževati in odpravljati napake.
