Vad betyder redundans

Ordet redundans hörs ofta i tech-världen, och många tänker då på något slöseri eller onödigt. Men sanningen är mer nyanserad. Redundans kan både vara ett problem och en livräddare det beror helt på var du använder det. Som webbutvecklare eller designer behöver du förstå när redundans skadar och när den räddar dina system. Den här texten hjälper dig navigera mellan dessa två världar.

Redundans Det enkla förklaringen

Redundans betyder överflöd eller övertalighet. Det är när något finns i större mängd än nödvändigt eller när information upprepas utan att ge något nytt. Tänk på en tårta som är större än vad gästerna kan äta det extra är redundans.

Ordet kommer från latin och används överallt. I språk kan det vara upprepade ord som förtydligar ett budskap. I teknik är det ofta systemdelar som upprepas för säkerhet. Begreppet är helt neutralt det är inte bra eller dåligt i sig (vilket många missar). Kontexten avgör allt.

Vi behöver förstå redundans för att kunna ta bättre beslut. Ibland är den nödvändig. Ibland är den slöseri. Din uppgift blir att veta skillnaden.

Redundans i programmering och databaser

I databaser är redundans ofta motsaten till det du vill. Om samma kundinformation lagras på två ställen i tabellen och du uppdaterar den på ett ställe blir det fel på det andra. Plötsligt visar systemet två olika mailadresser för samma person.

Utvecklare använder något som heter normalisering för att slippa detta. Det betyder att du organiserar data så varje uppgift bara lagras på ett ställe. Istället för att upprepa information skapar du kopplingar mellan tabeller.

Redundant data gör också filerna större utan nytta. Det tar längre tid att söka och uppdatera. Helt enkelt ineffektivt. För det är därför vi försöker minimera redundans i databaser de sparar tid, pengar och huvudvärk.

När redundans räddar systemet

Nu kommer den andra sidan av myntet. Ibland är redundans precis vad du behöver för att systemet ska överleva en kris. Ta en dykare som har två andrasteg på luftflaskan om en fallerar kan den andra ta över omedelbar. Utan redundans sjunker dykaren.

Flygplan har dubbla system för nästan allt. Två motorsystem. Två hydrauliska system. Två navigationssystem. Om den ena fallerar tar den andra över. Passagerarna märker ofta ingenting. Det är redundans som gör att planet är säkert.

Samma princip gäller webbapplikationer. Du behöver backupservrar som kan ta över om huvudservern havererar. Du behöver dubblad databas så ingen data försvinner. Du behöver redundanta nätverk-vägar. Här är redundans en feature, inte en bug. Den är skillnaden mellan "webbsidan är nere" och "webbsidan körde på sin backupserver och du märkte ingenting".

Redundans i design och användarupplevelse

Även i design kan redundans vara smart. En viktig knapp kanske behöver synas på två ställen i gränssnittet längst upp och längst ner. Det är överflöd, men användaren hittar den lättare.

Bekräftelsedialogs är redundans. En popup som frågar "Är du säker?" innan du raderar något. Det tar längre tid men det förhindrar misstag. Många användare uppskattar det extra steget när det gäller viktiga åtgärder.

Upprepade navigationsmenyer är också redundans. En meny längst upp, en i sidofältet, kanske en i footern. Användaren kan nå samma ställe från flera håll. Det gör gränssnittet tydligare utan att kännas rörigt. Balansen är att inte gå för långt för mycket repetition blir bara irriterande och fyller skärmen med clutter.

Hur du balanserar redundans rätt

Här är en enkel metod för att bestämma om redundans är smart eller slöseri. Ställ dig dessa frågor i ordning:

• Är detta kritiskt för säkerheten? Då behövs redundans. Backupsystem, dubbla databasserver, strömövervakning.
• Skulle ett fel här kosta pengar eller användare? Då är redundans värt kostningen.
• Gör redundansen upplevelsen bättre? Bekräftelsedialogs och upprepade knappar kan göra det. Använd din egen granskning.
• Är det bara överflöd utan syfte? Då kan du ta bort det.

Praktiska tips: Använd verktyg som kontrollerar databaser på duplicerad data. Granska dina backupstrategier två gånger per år. Be användarna testa ditt gränssnitt om de hittar vad de letar efter utan att fråga dig är balansen rätt.

Vanliga misstag med redundans

Det första misstaget är att fylla databasen med redundant data för att de är enkelt att programmera. Du sparar samma kundadress på tio ställen för att du är trött. Ett år senare behöver du uppdatera den och glömmer ett av de tio ställena. Kaos.

Det andra misstaget är att spara för lite redundans i säkerhetssystem. En server, en databas, en nätväglinje. Allt är bra tills dagen det inte är det. Då är webbsidan helt offline och kunderna är arga.

Det tredje misstaget är redundans på fel plats. En backupdatabas på samma fysiska server som huvuddatabasen. Om servern brinner brinner allt (och då hjälper redundansen ingenting). Eller en navigationsmeny som upprepar sig så många gånger att gränssnittet blir oöverskådligt.

Varningsignaler: Om uppdateringar tar alltför länge. Om användarnas feedback säger att gränssnittet är förvirrande. Om du inte säkert vet var din data faktiskt ligger eller om den säkerhetskopierats. Det är dags att granska din redundans.

Framåt Det är dags att granska

Redundans är ett verktyg. Någon gång smärtar det, någon gång räddas du av det. Din uppgift är att veta vilken tid det är.

Börja nu. Vilket är det första redundanta systemet i ditt projekt som du bör granska? Din databas? Din backupstrategi? Din webbapplikations navigation? Gå igenom metoden vi gick igenom. Ställ frågorna. Ta besluten.

Redundans är inte en motsägelse mellan säkerhet och effektivitet det är en balansgång där båda sidor vinner på tydlighet.