Introduktion till antimönster

Antimönster är raka motsatsen till mönster. Kom ihåg att designmönster är exempel på bra programmeringsmetoder, det vill säga mönster för att lösa vissa problem. Men antimönster är deras totala motsats, det vill säga mönster av misstag som görs när man löser olika problem.

En del av god programmeringspraxis är just att undvika antimönster. Tro inte att detta är ett så obegripligt teoretiskt skräp - det här är specifika problem som nästan alla utvecklare har stött på. Vem vet, han är beväpnad!

Låt oss titta på några antimönster som är vanliga bland nybörjare:

  • Magiska siffror och strängar
  • gud klass
  • För tidig optimering
  • cykelns uppfinning
  • Uppfinningen av enhjulingen

Magiska siffror och strängar

Ett magiskt tal är en konstant som används i kod för något (oftast dataidentifiering), vars nummer i sig inte är meningsfullt utan en motsvarande kommentar. Siffror har absolut ingen semantik.

När siffror börjar dyka upp i koden för ditt projekt, vars innebörd inte är uppenbar, är detta mycket dåligt. En programmerare som inte är författare till sådan kod kommer att ha svårt att förklara hur det fungerar. Med tiden kommer inte ens författaren till koden med magiska siffror att kunna förklara det.

Java webinar

Siffror gör kod svår att förstå och refaktorisera. De främsta orsakerna till detta fel är den hastiga utvecklingen och bristen på programmeringsövningar. Detta antimönster bör kvävas i knoppen genom att föreskriva användningen av numeriska konstanter innan utvecklingen påbörjas.

För att lösa detta problem måste du skapa en variabel vars namn förklarar syftet med den numeriska konstanten och tilldela den önskat värde.

gud klass

Det gudomliga objektet är ett antimönster som är ganska vanligt bland OOP-utvecklare. Ett sådant objekt tar på sig för många funktioner och/eller lagrar nästan all data. Som ett resultat har vi en icke-portabel kod, som dessutom är svår att förstå.

Dessutom är sådan kod ganska svår att underhålla, med tanke på att hela systemet nästan uteslutande beror på den. Orsaker till detta fel: utvecklare inkompetens, en utvecklare tar på sig en stor del av arbetet (särskilt när mängden arbete överstiger utvecklarens erfarenhetsnivå).

Det är nödvändigt att hantera detta tillvägagångssätt genom att dela upp uppgifter i deluppgifter som olika utvecklare kan hantera.

För tidig optimering

För tidig optimering är optimering som utförs innan programmeraren har all information som behövs för att fatta välgrundade beslut om var och hur det ska göras.

I praktiken är det svårt att förutse var en flaskhals kommer att uppstå. Försök att optimera innan empiriska resultat erhålls kommer att leda till kodkomplexitet och uppkomsten av fel, men kommer inte att ge några fördelar.

Hur man undviker? Skriv först ren, läsbar, fungerande kod med välkända och beprövade algoritmer och verktyg. Använd vid behov profileringsverktyg för att hitta flaskhalsar. Lita på mått, inte gissningar och antaganden.

Exempel och funktioner

Cachning före profilering. Använder komplex och oprövad heuristik istället för matematiskt korrekta algoritmer. Ett urval av nya, oprövade ramverk som kan uppträda fel under belastning.

Vad är svårigheten

Det är inte lätt att avgöra när optimering är för tidigt. Det är viktigt att lämna utrymme för tillväxt i förväg. Du måste välja lösningar och plattformar som gör att du enkelt kan optimera och växa. Ibland används också för tidig optimering som en ursäkt för dålig kod. Till exempel tar de en O(n2)-algoritm bara för att algoritmen skulle vara O(n) svårare.

cykelns uppfinning

Meningen med detta antimönster är att programmeraren utvecklar sin egen lösning på ett problem som det redan finns lösningar för, och ofta mycket mer framgångsrika.

Utvecklaren anser sig vara smartare, så han försöker komma på sin egen lösning för varje uppgift, trots erfarenheterna från sina föregångare. Oftast leder detta bara till tidsförlust och en minskning av programmerarens effektivitet. När allt kommer omkring är lösningen sannolikt suboptimal, om den överhuvudtaget hittas.

Naturligtvis kan du inte helt förkasta möjligheten till en oberoende lösning, eftersom detta kommer att leda till kopiera-klistra-programmering på ett direkt sätt. Utvecklaren måste navigera i de uppgifter som kan dyka upp framför honom för att kompetent lösa dem, använda färdiga lösningar eller uppfinna sina egna.

Mycket ofta är orsaken till detta antimönster en enkel tidsbrist. Och tid är pengar.

Uppfinningen av den fyrkantiga cykeln

Detta antimönster är mycket nära relaterat till att helt enkelt återuppfinna hjulet - skapa din egen dåliga lösning när en bättre lösning finns.

Detta antimönster tar dubbelt så lång tid: först läggs tid på att uppfinna och implementera din egen lösning, och sedan på att omstrukturera eller ersätta den.

Programmeraren måste vara medveten om förekomsten av olika lösningar för vissa områden av uppgifter, styras av deras fördelar och nackdelar.

Alla problem som du kommer att möta som programmerare kan delas upp i två delar:

  • smarta människor löste detta problem för 30 år sedan
  • smarta människor löste detta problem för 50 år sedan

De flesta programmeringsproblem har framgångsrikt lösts innan du ens föddes . Du behöver inte uppfinna någonting - bara studera andras erfarenheter (det är vad böcker är skrivna för).

Under 2022 kan vi fira följande födelsedagar:

  • Programmeringsspråk
    • C språk fyller 50 år (1972)
    • Java-språket fyllde 27 år (1995)
    • Python fyller 31 år (1991)
  • Förbindelse
    • Internet fyllde 39 år (1983)
    • Mobiltelefonen fyllde 49 år (1973)
    • Det första SMS:et skickades för 30 år sedan (1992)
  • Mönster
    • MVC-mönstret fyllde 44 år (1978)
    • SQL uppfanns för 48 år sedan (1974)
    • Javabönor uppfanns för 26 år sedan (1996)
  • Bibliotek
    • Hibernate uppfanns för 21 år sedan (2001)
    • Våren uppfanns för 20 år sedan (2002)
    • Tomcat släpptes för 23 år sedan (1999)
  • OS
    • Unix släpptes för 51 år sedan (1971)
    • Fönster såg dagens ljus för 37 år sedan (1985)
    • Mac OS släpptes för 21 år sedan (2001)

Och alla dessa saker uppfanns inte bara, de utvecklades som lösningar på problem som var mycket vanliga och relevanta på den tiden.