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 av, som løsninger på arkitektonisk nivå kan gjenbrukes på samme måte som kodeutdrag på mikronivå.

Design mønstre er generelt gjenbrukbare løsninger for visse scenarier, det 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. Den refererer til gjenbrukte løsninger som i utgangspunktet virker nyttige, men viser seg senere å 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 i det siste, 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 den 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 gjengi antipattern av “for tidlig optimalisering”, hvis vi legger merke til små effektiviteter og optimaliserer for dem for tidlig i utviklingsprosessen, før vi vet nøyaktig hva vi vil gjøre.

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

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

For å forhindre for tidlig optimalisering er det en god ide å følge YAGNI (Du skal ikke trenge) 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

De “finne opp hjulet på nytt” antipattern er også noen ganger referert til som “designe i vakuum”. Det skjer når vi vil gjør alt av oss selv og skriv 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 Skreddersydde løsninger, spesielt for grunnleggende funksjoner, er sjelden så gode som standard som allerede er testet av mange utviklere og brukere.

3. Avhengighet Hell

Det motsatte av “finne opp hjulet på nytt” Antipattern er en annen vanlig antipattern kalt “avhengighet helvete”.

Hvis, i stedet for å skrive alt fra grunnen, bruker vi for mange tredjepartsbiblioteker som er avhengige av bestemte versjoner av andre biblioteker, vi kan lett løpe inn i en vanskelig håndterlig situasjon når vi vil oppdatere, da disse datterselskapene er i mange tilfeller uforenlig med hverandre.

Dependency hell kan løses ved å bruke pakkeforvaltere som er i stand til oppdatere avhengige avhengigheter smart. 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 mangel på en skikkelig arkitektur.

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

Spaghettikoden stammer vanligvis fra kombinasjon av ulike dårlige kodingspraksis, for eksempel koden som ikke inneholder riktige betingelsesblokker, 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 dokumenteres 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 jobber først.

Programmering ved permutasjon kan enkelt introdusere nye feil i vår kode, verre fortsatt, 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 gjentatt selv (DRY) kodingsprinsippet, og i stedet for å lage generiske løsninger, setter vi allerede eksisterende kodestykker til forskjellige steder, og senere redigerer dem for å passe inn i en gitt sammenheng.

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

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

7. Cargo-Cult Programmering

Navnet til “last-kult programmering” kommer fra et bestemt etnografisk fenomen som kalles “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 lastkult programmering, 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 utviklere bare Rituelt gjør det som er hip på den tiden uten noen reell hensikt. Denne praksisen er ikke bare dårlig fordi det gjør overflaten av vår søknad overflødig, men det kan også enkelt introdusere nye feil i vår kode.

8. Lava Flow

Vi snakker om “lavaflyt” antipattern når vi trenger det håndtere kode som har overflødige eller lavkvalitetsdeler at ser ut til å være integrert til 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 ble skrevet av noen andre (vanligvis uten riktig dokumentasjon), eller når prosjektet flyttet for fort fra utviklingen til produksjonsfasen.

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

I teorien kan vi bli kvitt lavastrømmer med omfattende testing og refactoring, men i praksis, gjennomføringen er ofte vanskelig eller til og med umulig. Da lavastrømmer vanligvis har høy ytelse kostnader, er det bedre å hindre dem ved å sette opp en godt designet 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 fjernt vertsnavn, i kildekoden i stedet for å skaffe den fra en konfigurasjonsfil, en database, en brukerinngang eller en annen ekstern kilde.

Hovedproblemet med hard kode er det det fungerer bare riktig i et bestemt miljø, og på når vilkårene endres, Vi må 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 som heter “myk koding”, som er dens motsatte.

I myk koding, vi legger 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.