Antimønstre

Introduktion til anti-mønstre

Anti-mønstre er det stik modsatte af mønstre. Husk at designmønstre er eksempler på god programmeringspraksis, det vil sige mønstre til løsning af bestemte problemer. Men anti-mønstre er deres fuldstændige modsætning, det vil sige mønstre af fejl, der begås, når man løser forskellige problemer.

En del af god programmeringspraksis er netop at undgå anti-mønstre. Tro ikke, at dette er sådan et uforståeligt teoretisk skrald - det er specifikke problemer, som næsten alle udviklere er stødt på. Hvem ved, han er bevæbnet!

Lad os se på et par anti-mønstre, der er almindelige blandt begyndere:

• Magiske tal og strenge
• gud klasse
• For tidlig optimering
• opfindelsen af ​​cyklen
• Opfindelsen af ​​ethjulet cykel

Magiske tal og strenge

Et magisk tal er en konstant, der bruges i kode for noget (oftest dataidentifikation), hvis nummer i sig selv ikke giver nogen mening uden en tilsvarende kommentar. Tal bærer absolut ingen semantik.

Når tal begynder at dukke op i koden for dit projekt, hvis betydning ikke er indlysende, er det meget dårligt. En programmør, der ikke er forfatter til en sådan kode, vil have svært ved at forklare, hvordan den virker. Over tid vil selv forfatteren af ​​koden med magiske tal ikke være i stand til at forklare det.

Tal gør kode svær at forstå og refaktorisere. Hovedårsagerne til denne fejl er hastværket i udviklingen og manglen på programmeringspraksis. Dette anti-mønster bør nippes i opløbet ved at fastlægge brugen af ​​numeriske konstanter, før udviklingen påbegyndes.

For at løse dette problem skal du oprette en variabel, hvis navn forklarer formålet med den numeriske konstant, og tildele den den ønskede værdi.

gud klasse

Det guddommelige objekt er et anti-mønster, der er ret almindeligt blandt OOP-udviklere. Et sådant objekt påtager sig for mange funktioner og/eller gemmer næsten alle data. Som følge heraf har vi en ikke-bærbar kode, som i øvrigt er svær at forstå.

Derudover er en sådan kode ret vanskelig at vedligeholde, da hele systemet næsten udelukkende afhænger af det. Årsager til denne fejl: udvikler inkompetence, én udvikler påtager sig en stor del af arbejdet (især når mængden af ​​arbejde overstiger den pågældende udviklers erfaringsniveau).

Det er nødvendigt at håndtere denne tilgang ved at opdele opgaver i underopgaver, som forskellige udviklere kan håndtere.

For tidlig optimering

For tidlig optimering er optimering, der udføres, før programmøren har al den information, der er nødvendig for at træffe informerede beslutninger om, hvor og hvordan det skal gøres.

I praksis er det svært at forudsige, hvor en flaskehals vil opstå. Forsøg på at optimere før opnåelse af empiriske resultater vil føre til kodekompleksitet og forekomst af fejl, men vil ikke give nogen fordele.

Hvordan undgår man? Først skal du skrive ren, læsbar, fungerende kode ved hjælp af velkendte og gennemprøvede algoritmer og værktøjer. Brug eventuelt profileringsværktøjer til at finde flaskehalse. Stol på målinger, ikke gæt og antagelser.

Eksempler og funktioner

Caching før profilering. Brug af komplekse og ubeviste heuristika i stedet for matematisk korrekte algoritmer. Et udvalg af nye, utestede rammer, der kan opføre sig forkert under belastning.

Hvad er vanskeligheden

Det er ikke nemt at afgøre, hvornår optimering er for tidligt. Det er vigtigt at give plads til vækst på forhånd. Du skal vælge løsninger og platforme, der giver dig mulighed for nemt at optimere og vokse. Også nogle gange bruges for tidlig optimering som en undskyldning for dårlig kode. For eksempel tager de kun en O(n2)-algoritme, fordi algoritmen ville være O(n) vanskeligere.

opfindelsen af ​​cyklen

Betydningen af ​​dette anti-mønster er, at programmøren udvikler sin egen løsning på et problem, som der allerede findes løsninger på, og ofte meget mere vellykkede.

Udvikleren betragter sig selv som klogere, så han forsøger at komme med sin egen løsning til hver opgave på trods af sine forgængeres erfaringer. Oftest fører dette kun til et tab af tid og et fald i programmørens effektivitet. Løsningen er trods alt sandsynligvis suboptimal, hvis den overhovedet findes.

Selvfølgelig kan du ikke helt forkaste muligheden for en uafhængig løsning, da dette vil føre til copy-paste programmering på en direkte måde. Udvikleren skal navigere i de opgaver, der kan dukke op foran ham for at kunne løse dem kompetent ved at bruge færdige løsninger eller opfinde sine egne.

Meget ofte er årsagen til dette anti-mønster en simpel mangel på tid. Og tid er penge.

Opfindelsen af ​​den firkantede cykel

Dette anti-mønster er meget tæt forbundet med blot at genopfinde hjulet - at skabe din egen dårlige løsning, når der findes en bedre løsning.

Dette antimønster tager det dobbelte af tiden: For det første bruges tid på at opfinde og implementere din egen løsning, og derefter på at omstrukturere eller udskifte den.

Programmøren skal være opmærksom på eksistensen af ​​forskellige løsninger til bestemte rækker af opgaver, være styret af deres fordele og ulemper.

Alle de problemer, du vil møde som programmør, kan opdeles i to dele:

• kloge mennesker løste dette problem for 30 år siden
• kloge mennesker løste dette problem for 50 år siden

De fleste programmeringsproblemer er blevet løst, før du overhovedet blev født . Ingen grund til at opfinde noget - bare studer andre menneskers erfaringer (det er hvad bøger er skrevet til).

I 2022 kan vi fejre følgende fødselsdage:

• Programmeringssprog
  • C-sprog fylder 50 år (1972)
  • Java-sproget blev 27 år (1995)
  • Python fylder 31 år (1991)
• Forbindelse
  • Internettet blev 39 år (1983)
  • Mobiltelefonen blev 49 år (1973)
  • Den første SMS blev sendt for 30 år siden (1992)
• Mønstre
  • MVC-mønsteret blev 44 år (1978)
  • SQL blev opfundet for 48 år siden (1974)
  • Java bønner blev opfundet for 26 år siden (1996)
• Biblioteker
  • Hibernate blev opfundet for 21 år siden (2001)
  • Foråret blev opfundet for 20 år siden (2002)
  • Tomcat udgivet for 23 år siden (1999)
• OS
  • Unix blev udgivet for 51 år siden (1971)
  • Vinduer så dagens lys for 37 år siden (1985)
  • Mac OS udgivet for 21 år siden (2001)

Og alle disse ting blev ikke bare opfundet, de blev udviklet som løsninger på problemer, der var meget almindelige og relevante på det tidspunkt.