Webutvikling: De 10 kodende antipatternene du må unngå

Å designe arkitekturen til et nettsted eller et program, eller sette opp en effektiv kodende arbeidsflyt, gjør oss ofte til å ta vare på gjentatte problemer. Vi trenger ikke nødvendigvis å løse disse programvarenes designproblemer fra grunnen, da løsninger på arkitektonisk nivå kan gjenbrukes på samme måte som kodestykker på mikronivå .

Designmønstre er generelt gjenbrukbare løsninger for bestemte scenarier, som kan komme til nytte for å løse vanlige problemer, og kan enormt hjelpe oss med å optimalisere koden vår.

Mens designmønstre er gode måter å forbedre utviklingsprosessen ved å bruke velprøvde formler, noen ganger kan vi også gå galt med dem. Disse kalles antipatterner.

Hva er antipatterner?

Begrepet "antipattern" ble laget i en bok som heter AntiPatterns i 1998. Det refererer til gjenbrukte løsninger som i utgangspunktet virker nyttige, men senere viser seg å gjøre mer skade enn godt.

Dette kan skje av ulike grunner, for eksempel hvis vi ikke bruker mønstrene i riktig sammenheng, innstilling eller tid (løsninger som var effektive tidligere, kan ikke alltid fungere i nåtiden) eller i andre tilfeller hele paradigmet var bare dårlig fra starten.

Antipatterner kalles også ofte feilmønstre. Den gode nyheten er at det er mulig å gjenkjenne og unngå dem .

I dette innlegget vil vi se på 10 vanlige kodende antipatterner i webutvikling som kan skjule oss til å tro at vi har godt optimalisert kode. (Merk at antipatternene som er oppført i dette innlegget ikke nødvendigvis er det samme som det du finner i boken som er nevnt ovenfor.)

1. For tidlig optimalisering

God timing er en avgjørende faktor i kodeoptimalisering. Vi kan enkelt reprodusere antipatternen for "for tidlig optimalisering", hvis vi legger merke til små effektiviteter og optimaliserer for dem for tidlig i utviklingsprosessen, før vi akkurat vet hva vi vil gjøre.

Ifølge Donald Knuths berømte sitat er "for tidlig optimalisering roten til alt ondt", noe som kan være en overdrivelse, men viser fortsatt hvor alvorlige problemer tidlig optimering senere kan forårsake.

Hvis vi optimaliserer for ytelse før du oppretter en effektiv arkitektur, kan vi redusere kodelesbarhet, gjøre feilsøking og vedlikehold vanskeligere, og legg til overflødige deler til koden vår.

For å forhindre for tidlig optimalisering er det en god ide å følge YAGNI (You Do not Gonna Need It) programmeringsprinsippet, som anbefaler å "alltid implementere ting når du faktisk trenger dem, aldri når du bare forutser at du trenger dem."

2. Å gjenoppfinne hjulet

Antipatternet "gjenoppfinning av hjulet" kalles noen ganger også som "designe i vakuum" . Det skjer når vi vil gjøre alt av oss selv og skrive alt fra grunnen av, uten å lete etter allerede eksisterende metoder, APIer eller biblioteker.

Å gjenoppfinne hjulet er ikke bare en tidsløs ting å gjøre, men tilpassede løsninger, spesielt for grunnleggende funksjoner, er sjelden så gode som de standardene som allerede er testet av mange utviklere og brukere.

3. Avhengighet Hell

Det motsatte av "reinventing the wheel" antipattern er en annen vanlig antipattern kalt "dependence hell" .

Hvis vi, i stedet for å skrive alt fra grunnen, bruker for mange tredjepartsbiblioteker som er avhengige av spesifikke versjoner av andre biblioteker, kan vi lett komme inn i en vanskelig håndterbar situasjon når vi vil oppdatere, da disse datterselskapene i mange tilfeller er uforenlige med hverandre .

Dependency hell kan løses ved hjelp av pakkeforvaltere som er i stand til å oppdatere gjensidig avhengighet . Hvis vi blir overveldet for mye av problemet, kan refactoring også være en god ide.

4. Spaghetti kode

"Spaghetti kode" er trolig den mest kjente kodende antipattern. Det beskriver et program som er vanskelig å feilsøke eller modifisere på grunn av mangelen på en skikkelig arkitektur .

Resultatet av dårlig programvare design er en haug med kode som er lik struktur i en bolle med spaghetti, det vil si sammenflettet og innviklet . Lesbarhet av spaghetti kode er svært lav, og det er vanligvis et nesten umulig oppdrag å forstå hvordan det fungerer akkurat.

Spagetti-koden stammer vanligvis fra kombinasjonen av ulike dårlige kodingspraksis, for eksempel koden som ikke inneholder riktige blokkeringer, har mange goto-setninger, unntak og tråder som inneholder deler som hører til et annet sted, har minimal sammenheng mellom objekter, funksjoner eller metoder som ikke kan gjenbrukes, eller ikke er dokumentert riktig eller i det hele tatt.

5. Programmering ved permutasjon

"Programmering ved permutasjon" eller "programmering ved et uhell" skjer når vi prøver å finne en løsning på et problem ved å eksperimentere med små modifikasjoner, teste og vurdere dem en etter en, og til slutt implementere den som først fungerer.

Programmering ved permutasjon kan enkelt introdusere nye feil i vår kode, enda verre, de er feil vi ikke nødvendigvis gjenkjenner på en gang. I mange tilfeller er det også umulig å forutse om løsningen vil fungere for alle mulige scenarier, eller ikke.

6. Kopier og lim inn programmering

"Kopier og lim inn programmering" oppstår når vi ikke følger gjenkjenningsprøven, ikke gjentatt selv (DRY), og i stedet for å lage generiske løsninger, setter vi allerede eksisterende kodestykker til forskjellige steder, og endrer dem senere for å passe inn i gitt sammenheng.

Denne øvelsen resulterer i en kode som er svært repeterende, da de kodede delene vanligvis bare avviger bare i mindre uoverensstemmelser.

Kopier og lim inn programmering er ikke bare begått av nybegynnerutviklere, men erfarne programmører også, da mange av dem er tilbøyelige til å bruke sine egne forhåndskrevne, velprøvde kodestykker for bestemte oppgaver, noe som lett kan føre til utilsiktede gjentakelser .

7. Cargo-Cult Programmering

Navnet på "cargo-kult programmering" kommer fra et spesifikt etnografisk fenomen kalt "lastkult". Lastkultene dukket opp i Sør-Stillehavet etter andre verdenskrig, da den tvunget kontakt med avanserte sivilisasjoner førte innfødte til å tro at produserte produkter, som Coca-Cola, TV og kjøleskap levert av lastskip til øyene, ble skapt av overnaturlige fremgangsmåter; og hvis de utfører magiske ritualer som ligner på vestenes vesener, vil lasten fylt med varer komme igjen.

Når vi forplikter antipatternen til lastkultprogrammering, gjør vi i utgangspunktet det samme. Vi bruker rammer, biblioteker, løsninger, designmønstre, etc. som fungerte bra for andre, uten å forstå hvorfor vi gjør det, eller hvordan nevnte teknologier fungerer nøyaktig.

I mange tilfeller gjør utviklere bare ritual det som er hip på den tiden uten noen reell hensikt . Denne praksisen er ikke bare dårlig fordi det gjør overflaten vår overflødig oppsvulmet, men det kan også enkelt introdusere nye feil i vår kode.

8. Lava Flow

Vi snakker om "lavastrøm" antipattern når vi må håndtere kode som har overflødige eller lavkvalitetsdeler som ser ut til å være integrert i programmet, men vi forstår ikke helt hva det gjør eller hvordan det påvirker hele applikasjonen . Dette gjør det risikabelt å fjerne det.

Det skjer vanligvis med arvskode, eller når koden er skrevet av noen andre (vanligvis uten riktig dokumentasjon), eller når prosjektet flyttet for fort fra utviklingen til produksjonsfasen.

Navnet på antipattern kommer fra dens hengivenhet med lava som kommer fra vulkaner, det vil i første omgang bevege seg raskt og flytende uten å ta for mange forholdsregler, men det strammer senere og blir vanskelig å fjerne.

I teorien kan vi kvitte seg med lavastrømmer med omfattende testing og refactoring, men i praksis er implementeringen ofte vanskelig eller umulig . Da lavastrømmer vanligvis har høy ytelseskost, er det bedre å hindre dem ved å sette opp en velfungerende arkitektur og en god arbeidsflyt fra starten.

9. Hard koding

"Hard koding" er en kjent antipattern mot hvilken de fleste webutviklingsbøker advarer oss rett i forordet. Hard koding er den uheldig praksis der vi lagrer konfigurasjons- eller inngangsdata, for eksempel en filbane eller et eksternt vertsnavn, i kildekoden i stedet for å skaffe det fra en konfigurasjonsfil, en database, en brukerinngang eller en annen ekstern kilde .

Hovedproblemet med hard kode er at den bare fungerer riktig i et bestemt miljø, og når som helst endres forholdene, må vi endre kildekoden, vanligvis på flere separate steder.

10. Myk koding

Hvis vi prøver veldig hardt for å unngå fallgruvene med hard koding, kan vi lett løpe inn i en annen antipattern kalt "myk koding", som er dens motsatte.

Ved myk koding setter vi ting som skal være i kildekoden til eksterne kilder, for eksempel lagrer vi forretningslogikk i databasen. Den vanligste grunnen til at vi gjør det, er frykten for at forretningsreglene vil endre seg i fremtiden, derfor må vi omskrive koden.

I ekstreme tilfeller kan et mykt kodet program bli så abstrakt og innviklet at det er nesten umulig å forstå det (spesielt for nye lagmedlemmer), og ekstremt vanskelig å vedlikeholde og feilsøke .