Redundans är information som upprepar redan etablerad information utan att tillföra någon ny. Redundant information är därför överskottsinformation. Sådan information spelar dock en viktig roll i den förklarande halvan (The Explaining Half). Den förtydligar eller säkrar information. Men det kan också ta onödig plats eller bidra till oönskad upprepning.
Maximal redundans innebär total avsaknad av nytt. Allt det som finns i en förklaring kan härledas på annat vis. Det bidrar inte till att förklara lösningen.
Minimal redundans inträffar när allt i en förklaring är ny information. Inget i en förklaring bekräftar det som redan var känt.
Lajos har skrivit metoden printBL:
void printBL () {
System.out.println ("Employee: " + name);
String temp = "";
for (Employee boss = this.boss; null != boss; boss = boss.boss) {
temp += boss.name + " ";
}
System.out.println ("Bosses: { " + temp + "}");
}
Anico tycker att förklaringen inte är tillräckligt uppenbar. Hon vill att läsaren ska förstå den även med en mycket liten ansträngning. Därför ändar hon namnet på metoden till printBossList och byter också namnet den lokala variabeln temp mot bossList.
void printBossList () {
System.out.println ("Employee: " + name);
String bossList = "";
for (Employee boss = this.boss; null != boss; boss = boss.boss) {
bossList += boss.name + " ";
}
System.out.println ("Bosses: { " + bossList + "}");
}
Har Anico tillfört ny information? Genom att analysera Lajos implementation av metoden så hade en normalbegåvad programmerare kunnat dra den säkra slutsatsen att metoden skriver ut en lista med chefer och att den lokala variabeln är den sträng med chefsnamn som ska skrivas ut.
Anicos ändringar tillför redundans i syfte att förtydliga information. Även den som bara tittar hastigt på metoden blir övertygad om förklaringen.
Det finns en mänsklig instinkt att strukturera ny information med hjälp av redan förankrad kunskap. Vi vill tolka det okända med hjälp av det redan kända, få det som vi anar bekräftat. Ett visst mått av redundans krävs för att kunna utvinna kunskap ur information.
Antag att Anico hade vägrat att använda radbrytningar när hon skrev metoden:
void printBossList(){System.out.println ("Employee: "+name);String
bossList="";for(Employee
boss=this.boss;null!=boss;boss=boss.boss){bossList+=boss.name+"
";}System.out.println("Bosses: { "+bossList+"}");}
Den kompakta versionen är både svårare att läsa och förstå. Men den innehåller samma information om lösningen. Blocket är fortfarande ett block även om det skrivs kompakt.
Anicos ursprungliga version hade två egenskaper som signalerade att det var ett block. Dels började och slutade blocket med måsvinge. Dels var blocket formaterat efter teamets kodkonventioner för block, med måsvingarna på varsin rad och indenterad kod däremellan. Två egenskaper som ger samma information betyder redundans. En redundans som i det här fallet gör det svårare att missförstå Annicos förklaring av lösningen.
Brusig och riskfylld redundans
All redundans förtydligar inte. Etele lägger till en kodkommentar till den tredje raden:
String bossList = ""; // initializing to empty string
Kodkommentaren är så redundant att den ökar bruset. Det är inte troligt att någon som inte ser koden till vänster skulle läsa kommentaren till höger och först då förstå.
När redundansen gör att det krävs mindre ansträngning för att förstå förklaringen och när den minskar sannolikheten för missförstånd, då förtydligar den. Det kan t ex vara:
- strukturell enkelhet
- regelbundenhet
- namngivna designmönster
- symmetri mellan kommunicerande moduler
- namn strukturerade som i problemdomänen
- begränsning av antal metaforer
- kodkonventioner
Etele får i uppgift att ändra programmet så att listan med chefer indenteras ett tabulatorsteg:
String bossList = "\t"; // initializing to empty string
Det som en gång var redundans har nu blivit en motsägelse. Kodkommentaren säger att strängen är tom. Koden säger att den innehåller ett tabulatortecken. Redundans i ett program som förändras är ofta en risk. Det är inte tillräckligt skäl för att inte använda redundans, bara en faktor för att balansera den.
Redundans som checksumma
Ibland finns det ett annat syfte med redundans än att förtydliga. Det är när man vill säkra information. Någonting förklaras på två sätt med uttrycklig avsikt att det ska gå fel om de två förklaringarna blir motstridiga. Programmeraren använder redundansen för att väcka uppmärksamhet när något är ologiskt. Anico skriver en metod:
void setBoss (Employee boss) {
if (equals (boss)) {
throw new IllegalArgumentException (name + " can't self boss");
}
this.boss = boss;
}
Metoden heter setBoss vilket övertygar läsaren om att den formella parametern är ett objekt med information om den anställdes chef. Den börjar sedan med ett test för att se om chefen och den anställda är samma person. Det ska det ju naturligtvis inte vara, i så fall hade metoden hetat något annat.
Om testet går fel så kommer programmet att krascha. Testet tillför ingen ny information som inte framgår av metodnamnet. Den säkrar informationen i en checksumma, redundans för att uppmärksamma ett ologiskt förhållande.
Exformation – det välkända som explicit exkluderas
Den danska fysikern Tor Nørretranders myntade uttrycket exformation - en förkortning för “explicitly discarded information”. I den förklarande halvan är exformationen all den relevanta information som programmeraren avsiktligt inte har med, men som krävs för att förstå förklaringen. Han har tagit bort exformationen eftersom han anser att det är kunskap som han delar med den som ska underhålla programmet. Den finns i huvudet på både den som skriver programmet och den som underhåller det.
Lajos skriver en klass för att hantera information om anställda:
class Employee {
String name;
int monthlySallary;
Date employmentDate;
Employee boss;
}
Ett av fälten heter monthlySallary. Ingen valuta är angiven. För den anställde är det naturligtvis väsentligt ifall han får sin månadslön som 7 000 dollar eller som 7 000 euro.
Eftersom kunden är ett företag i Finland utan anställda utomlands, så vet alla i teamet att det är euro som avses. Valutan är exformation i Lajos förklaring. Det minskar redundansen i förklaringen och gör den mer effektiv.
För att exformationen inte ska leda till missförstånd så måste läsaren ha en tillräckligt stark repertoar (Repertoir). Alfred blir medlem i samma team som Lajos. Han har inte samma problemdomänkunskap som Lajos. T ex så känner han inte till att kunden är från Finland och kan därför omöjligt veta att valutan är euro. Fortfarande är det dock exformation eftersom Lajos avsiktligt har valt bort den informationen.
Program skrivna i dynamiskt typade språk har mer exformation är program skrivna i statiskt typade språk. Alfred skriver om klassen i Ruby:
class Employee
attr_accessor :name, :monthlySallary, :employmentDate, :boss
end
Att namnet är en sträng, att monthlySallary är ett heltal, att employmentDate är ett datum och att boss en anställd framgår inte längre av förklaringen. Det har blivit exformation. Om man bara läser Ruby-programmet så är det lika sannolikt att boss är en sträng med ett namn som att det är ett objekt av typen Employee. Därför kan man heller inte veta vilka meddelanden som boss-objektet kan acceptera. Men så länge som hela teamet vet att boss är en Employee så är det exformation som effektiviserar förklaringen.
Transparens kontra abstraktion
Abstrahera är tekniken att förkorta. Onödig redundans tas bort, andelen information ökar.
Etele extraherar koden som skapar listan med chefer. Hon gör den till en egen metod som heter createBossList:
void printBossList () {
System.out.println ("Employee: " + name);
String bossList = createBossList ();
System.out.println ("Bosses: { " + bossList + "}");
}
private String createBossList () {
String bossList = "";
for (Employee boss = this.boss; null != boss; boss = boss.boss) {
bossList += boss.name + " ";
}
return bossList;
}
För den som inte vill veta exakt hur listan med chefer skapas så är det nu mindre redundans i printBossList. Det framgår fortfarande att listan skapas och tilldelas till variabeln bossList.
Med abduktivt resonerande väljer man den hypotes som, om den är sann, bäst förklarar de fakta man har. En bra abstraktion gör att abduktivt resonemang alltid leder rätt. Det räcker med att se anropet till en metod som heter createBossList för att abduktivt dra slutsatsen att det skapar en lista med chefer och inte t ex en lista med namn på georgiska jordbruksmaskiner. Man behöver inte se algoritmen.
Det är inte alltid som det går att skapa abstraktioner med självklara betydelser. Om två eller flera förklaringar är lika sannolika så är förklaringen entropisk. Det är ett tillstånd där det inte går att förutsäga vad som ska hända. Läsaren vill då kunna falla tillbaka på ett deduktivt resonemang istället – en situation där kända fakta leder till nödvändiga slutsatser. För att uppnå det behövs transparens som komplement till abstraktion.
Transparens är egenskapen att det syns hur något fungerar. När en mekanism som har abstraherats inte fungerar så som önskat, då måste det finnas transparens för att kunna förändra den.
Anico får i uppgift att införa kommatecken mellan chefernas namn. Det framgår inte av anropet i printBossList huruvida det redan är kommatecken mellan namnen. Och det går absolut inte att förändra den egenskapen i den abstraherade metoden printBossList. Istället så behöver Anico navigera sig ner till metoden createBossList och där göra förändringen:
private String createBossList () {
String bossList = "";
for (Employee boss = this.boss; null != boss; boss = boss.boss) {
bossList += boss.name + (null != boss.boss ? ", " : " ");
}
return bossList;
}
Redundansbehovet beror inte bara på läsarens repertoar utan även på hur detaljerad förklaring hon behöver. Helst ska förklaringen ha en dynamisk redundansfaktor. Den som vill veta det övergripande ska kunna göra det utan att lägga ner mycket tid och utan att behöva en stark repertoar. Men den som måste veta detaljer ska också kunna nå dem på ett smidigt sätt. För att lyckas med det krävs enkel navigering i kombination med balans mellan abstraktion och transparens.
Abstraktion minskar mängden detaljer som man måste kunna för att kunna förstå eller tillämpa något. Transparens gör att programmerarna kan förstå och lösa detaljerade problem. Abstraktionen gör förklaringen lättöverskådlig. Transparensen skapar fullständig ordning i förklaringen, entropin är låg. I en perfekt balans så är abstraktionen alltid det första man ser medan transparensen är lätt att hitta via navigering.
Arousal – hur eggande är en förklaring?
En viktig faktor vid inlärning är arousalen. Det är ett begrepp som är relaterat till tristess, uppmärksamhet, stress och oro. Arousalen är den energipotential som en person har vid ett givet tillfälle, den psykologiska beredskapen för aktivitet. Den påverkas av saker som händer runt personen och den påverkar personens möjlighet att prestera.
En lösning med en förklaring som har för mycket redundans upplevs av läsaren som tjatig och långtråkig. Det påverkar arousalen negativt. Samma saker återkommer om och om igen och dessutom är kanske exformationen mindre än vad den borde vara.
En förklaring med minimal redundans är å andra sidan obegriplig och även den en arosalsänkare. Om läsaren har en svag repertoar inom området så finns heller ingen möjlighet att dra fördel av exformation. Läsaren kan inte skapa sig en mental struktur från förklaringen. Han läser en chiffrerad text utan tillgång till nyckeln.
För att maximera arousalen ska förklaringen ha tillräckligt med ny information för att ta läsaren vidare till nästa kunskapsnivå, men samtidigt ha lämpligt med redundans för att ge läsaren struktur och sammanhang.
Arousalen är inte ett mått på hur lämplig läsaren är att ta emot budskapet, utan på hur entusiastisk han är för att få ta del av förklaringen. Yerkes-Dodsons lag visar ett empiriskt förhållande mellan arousal och förmågan att prestera.
Det är sannolikt att olika typer av uppgifter har olika arousala optimum. Svåra eller intellektuellt utmanande problem kan kräva en lägre arousal för att uppnå koncentration, medan uppdrag där uthållighet är en viktig förmåga kräver högre arousal för att öka motivationen.
