Introduksjon til anti-mønstre

Anti-mønstre er det stikk motsatte av mønstre. Husk at designmønstre er eksempler på god programmeringspraksis, det vil si mønstre for å løse visse problemer. Men anti-mønstre er deres fullstendige motsetning, det vil si mønstre av feil som gjøres når man løser ulike problemer.

En del av god programmeringspraksis er nettopp å unngå anti-mønstre. Ikke tro at dette er et så uforståelig teoretisk søppel - dette er spesifikke problemer som nesten alle utviklere har møtt. Hvem er klar over, han er bevæpnet!

La oss se på noen anti-mønstre som er vanlige blant nybegynnere:

  • Magiske tall og strenger
  • gud klasse
  • For tidlig optimalisering
  • oppfinnelsen av sykkelen
  • Oppfinnelsen av enhjulingen

Magiske tall og strenger

Et magisk tall er en konstant som brukes i kode for noe (oftest dataidentifikasjon), selve tallet gir ingen mening uten en tilsvarende kommentar. Tall har absolutt ingen semantikk.

Når tall begynner å vises i koden til prosjektet ditt, hvis betydning ikke er åpenbar, er dette veldig dårlig. En programmerer som ikke er forfatteren av slik kode vil ha problemer med å forklare hvordan den fungerer. Over tid vil selv forfatteren av koden med magiske tall ikke kunne forklare det.

Java webinar

Tall gjør kode vanskelig å forstå og refaktorisere. Hovedårsakene til denne feilen er hastverket i utviklingen og mangelen på programmeringspraksis. Dette anti-mønsteret bør nippes i knoppen ved å fastsette bruken av numeriske konstanter før utviklingen starter.

For å løse dette problemet må du lage en variabel hvis navn forklarer formålet med den numeriske konstanten, og tilordne den ønsket verdi.

gud klasse

Det guddommelige objektet er et antimønster som er ganske vanlig blant OOP-utviklere. Et slikt objekt tar på seg for mange funksjoner og/eller lagrer nesten alle dataene. Som et resultat har vi en ikke-bærbar kode, som dessuten er vanskelig å forstå.

I tillegg er slik kode ganske vanskelig å vedlikeholde, gitt at hele systemet nesten utelukkende avhenger av det. Årsaker til denne feilen: utviklerinkompetanse, én utvikler tar på seg en stor del av arbeidet (spesielt når mengden arbeid overstiger utviklerens erfaringsnivå).

Det er nødvendig å håndtere denne tilnærmingen ved å dele opp oppgaver i deloppgaver som ulike utviklere kan håndtere.

For tidlig optimalisering

For tidlig optimalisering er optimalisering som utføres før programmereren har all informasjonen som trengs for å ta informerte beslutninger om hvor og hvordan det skal gjøres.

I praksis er det vanskelig å forutsi hvor en flaskehals vil oppstå. Forsøk på å optimalisere før man oppnår empiriske resultater vil føre til kodekompleksitet og tilsynekomst av feil, men vil ikke gi noen fordeler.

Hvordan unngå? Først, skriv ren, lesbar, fungerende kode ved å bruke velkjente og velprøvde algoritmer og verktøy. Bruk eventuelt profileringsverktøy for å finne flaskehalser. Stol på målinger, ikke gjetninger og antakelser.

Eksempler og funksjoner

Caching før profilering. Bruk av komplekse og uprøvde heuristikk i stedet for matematisk korrekte algoritmer. Et utvalg nye, uprøvde rammeverk som kan oppføre seg feil under belastning.

Hva er vanskeligheten

Det er ikke lett å avgjøre når optimalisering er for tidlig. Det er viktig å gi rom for vekst på forhånd. Du må velge løsninger og plattformer som gjør at du enkelt kan optimalisere og vokse. Noen ganger brukes også for tidlig optimalisering som en unnskyldning for dårlig kode. For eksempel tar de en O(n2)-algoritme bare fordi algoritmen ville være O(n) vanskeligere.

oppfinnelsen av sykkelen

Meningen med dette antimønsteret er at programmereren utvikler sin egen løsning på et problem som det allerede finnes løsninger på, og ofte mye mer vellykkede.

Utvikleren anser seg selv som smartere, så han prøver å komme opp med sin egen løsning for hver oppgave, til tross for erfaringene fra forgjengerne. Oftest fører dette bare til tap av tid og en reduksjon i effektiviteten til programmereren. Tross alt vil løsningen sannsynligvis være suboptimal, hvis den i det hele tatt blir funnet.

Selvfølgelig kan du ikke helt forkaste muligheten for en uavhengig løsning, siden dette vil føre til kopier-lim-programmering på en direkte måte. Utvikleren må navigere i oppgavene som kan dukke opp foran ham for å kompetent løse dem, ved å bruke ferdige løsninger eller finne opp sine egne.

Svært ofte er årsaken til dette anti-mønsteret en enkel mangel på tid. Og tid er penger.

Oppfinnelsen av den firkantede sykkelen

Dette antimønsteret er veldig nært knyttet til å bare finne opp hjulet på nytt - å lage din egen dårlige løsning når en bedre løsning eksisterer.

Dette antimønsteret tar dobbelt så lang tid: Først brukes tid på å finne opp og implementere din egen løsning, og deretter på å omstrukturere eller erstatte den.

Programmereren må være klar over eksistensen av ulike løsninger for visse spekter av oppgaver, være styrt av deres fordeler og ulemper.

Alle problemene du vil møte som programmerer kan deles inn i to deler:

  • smarte mennesker løste dette problemet for 30 år siden
  • smarte mennesker løste dette problemet for 50 år siden

De fleste programmeringsproblemer har blitt løst før du selv ble født . Du trenger ikke å finne på noe - bare studer andre menneskers opplevelse (det er dette bøker er skrevet for).

I 2022 kan vi feire følgende bursdager:

  • Programmerings språk
    • C-språk fyller 50 år (1972)
    • Java-språket ble 27 år (1995)
    • Python fyller 31 år (1991)
  • Forbindelse
    • Internett ble 39 år (1983)
    • Mobiltelefonen ble 49 år (1973)
    • Den første SMS-en ble sendt for 30 år siden (1992)
  • Mønstre
    • MVC-mønsteret ble 44 år (1978)
    • SQL ble oppfunnet for 48 år siden (1974)
    • Java bønner ble oppfunnet for 26 år siden (1996)
  • Biblioteker
    • Hibernate ble oppfunnet for 21 år siden (2001)
    • Våren ble oppfunnet for 20 år siden (2002)
    • Tomcat utgitt for 23 år siden (1999)
  • OS
    • Unix ble utgitt for 51 år siden (1971)
    • Vinduer så dagens lys for 37 år siden (1985)
    • Mac OS utgitt for 21 år siden (2001)

Og alle disse tingene ble ikke bare oppfunnet, de ble utviklet som løsninger på problemer som var veldig vanlige og relevante på den tiden.