Felsökning är höjdpunkten av mänsklig intellektuell aktivitet

Felsökning är höjdpunkten av mänsklig intellektuell aktivitet

Alla tekniska och naturvetenskapliga arbete kan delas ungefär i tre oberoende huvudaktivitet: analys, syntes och felsökning. I denna uppsats definierar jag dessa begrep, deras skillnader och likheter. Jag ska även försöka visa att det ofta gäller inte bara tekniska utan också de flesta humanistiska sysselsättningar.

Var och en får komma ihåg stunder i livet när man behövde antingen

  • studera hur något funkar eller består av;
  • skapa en ny sak av en eller fler befintliga komponenter;
  • utreda varför någonting inte funkar som det borde.

Ofta alterneras denna aktivitet men man alltid kan skilja de tre faserna.

Analys

Att analysera något är att förstå hur det fungerar eller av vilka delar det består samt vilka egenskaper det har.

Ett säkert kännetecken att någon verksamhet är analys är följande: man börjar arbeta med ett befintligt ting och vid slutet har man flera andra ting.

Resultatet beror avsevärt på redskap och metoder som tillämpas. Deras val lär bli helt slumpmässigt, till exempel ett barn prövar nya saker genom att känna dem, gripa dem, slå dem, stoppa dem i munnen och tugga dem, med mera. Dess agerande styrs av ren nyfikenhet och fantasi. Alternativt kan metoder baseras på tidigare erfarenhet och olika hypoteser som gäller det analyserande objektet. Fantasi spelar fortfarande en stor roll.

Det är värt att märka att resultatet på en ren analysprocess beror endast på den naturen av analyserande saken eller ibland på verktyg som användas vid processen. Med andra ord skulle det inte bero på människas egenskaper. Om två annorlunda forskare utför analys på samma objekt oberoende av varandra bör deras slutsatser bli likadana. Det vill säga resultat skulle spegla objekts egenskaper eller innehåll, inte subjekts metoder, anlag eller vilja.

Analys tillämpas i alla slags människors verksamhet, både tekniska och humanistiska, i konst och i vetenskap.

Syntes

Ofta uppstår en nödvändighet att ha ett objekt med vissa egenskaper som inte funnits före.

Syntes ser ut motsatt till analys: man börjar med flera befintliga saker och syftar på att skapa en ny sak till som uppfyller krav.

Den största skillnaden från analys är att samma resultat kan nås med olika approacher i syntesens fall. Annat kännetecken är att inte alla delar måste användas för att nå resultatet under förutsättning att samma mål presteras.

Mycket mer beror på formgivarens val. Ett av de framträdande exemplen är hur någonting kan flyga. Fåglarna har fjädrar på vingar, reptilerna och fladdermössen har flexibelt skinn på dem istället, och människor använder stela material i flygens vingar.

Felsökning

Det tredje verksamhetsalternativet uppstår när det redan finns ett system som avses att utföra någon funktion med inte uppfyller det, eller gör det på felaktigt sätt.

Felsökning tar olika former och namn i människors verksamhet. Läkare upptäcker sjukdom av dess symptom, detektiver utreder mord, programmerare söker efter en bugg osv.

Ett enklare alternativ till felsökning är ibland att slänga det felaktiga systemet och använda något annat som är i bättre skick. Till exempel består fordon av flera enskilda delsystem, och om det är känt att visst delsystem har gått sönder då byter man delen utan att utreda vad det var för felfunktionsorsak.

Men det går inte alltid att bara ta något bort och byta med en ny sak. Tänk om att systemet kan råka vara ens kropp eller till och med hela samhället. Då kan man helt enkelt inte utbyta systemet till något som är felfritt. Istället går man djupare för att ta reda på vad det är som gått fel och hur man kan rätta orsaken.

Det riktiga felsöknings kännetecken är att man tränger sig fram från symptomen till orsaken. Det här är det viktigaste skillnaden mot både syntes och analys.

Analysen har en orsak från början och producerar “symptomen” det vill säga egenskaper. Syntesen ger frihet att välja orsaker (det vill säga komponenter) för att nå syftet vilket är “symptomen”. Under felsökning är orsak okänd, och symptom får inte ändras alls av utredaren.

Jämförelse

Låt oss jämföra de tre aktiviteten.

Analys får inte bero på utförare, och resultat, dock okänd i början, bör reproduceras av andra.

Syntes måste nå bestämt syfte men i processen får man välja komponenter själv.

Vid felsökning kan man inte ändra systemet betydligt, därför att det då blir ett annat system. Man får inte justera symptom heller, eftersom man utgår från dem.

Det som framträder i fallet av felsökningsarbete är att utredningsväg från symptomen till skälet, från dådet till mord riktas mot vanlig rörelse.

Jag finner det konstigt att trots att man kan lära sig i skolan eller universitetet hur man utför både syntes och analys, finns det nämligen inte så många platser eller kurser där man kan lära sig felsökning. Det undervisas främst som ett slags hantverk utan någon fast teori. Men det är inte sant att man inte kan lära sig felsökning på ett regelbundet sätt.

Dock är felsökning på grund av sin natur svårare än andra aktiviteten, det finns egentligen regler som är omdiskuterade nedanför.

Felsökningsregler

Det bästa råd hittar man i boken [1]. Vidare upprepar jag de nio oumbärliga reglerna. Ibland verkar de vara något uppenbara, men man måste ha självdisciplin och man får inte strunta i att tillämpa dem. Då garanterar de snabbaste lösning vid felsökning. Annars vilseleder man själv ofta när man går efter några snabba eller enkla lösningar som blir i verkligheten inte effektiva alls.

Det tar tid och ansträngning att vänja sig vid rätta felsökningstekniker men det lönar sig på långt sikt.

1. Förstå det system som felsökes

Som sagt låter det kanske självklart, men det första steget är verkligen att bestämma gränser och ta reda på strukturen på det som man undersöker under felsökning.

Det skiljer sig avsevärt från vanliga skoluppgifter där man redan är given med ett problem och gränser i vilka problemet skulle lösas. Det händer aldrig med uppgifterna från verkligheten där allt är vagt i början.

Ibland efter att man fattat systemet upptäcks det att problemet inte är sådant alls eller att det kommer ifrån någon annanstans än anges inledningsvis.

2. Tvinga det misslyckas

De krångligaste problemen är nog så kallade indeterministiska, det vill säga de uppstår och försvinner i ett system utan något tydligt mönster. Att felsöka dem är hemskt obekvämt.

Därför är det viktigt att försöka ändra systemets parametrar lite så att problemet börjar uppstå i 100% fall. Efter det blir utredningen alltid enklare.

Det må strida mot människas första önska att “reparera” systemet så att problemet sker mindre ofta. Men utan en riktig förståelse om vad som orsakar det felaktiga beteendet gör sådan reparation ännu sämre — nu göms orsaken under extra skick av “reparation”. Däremot bör man se till att problemet kommer till dagsljuset där det är enklare att undersöka det.

3. Sluta tänka, titta istället

Detta råd handlar också om människas felaktiga beteende när något oväntade sker i ett system under felsökning. Då håller man på att inbilla sig olika sannolika anledningar till vad som kunde orsaka det.

Problemet är, det finns ofta oändligt antal ömsesidigt oberoende orsakar till samma konsekvens. Således kan det ta lång tid att pröva alla möjligheter på så vis.

Ibland råkar det slumpvis att någon av tidiga hypoteser blir korrekt. Men efter omkring 30 minuter tomt gissande, tillämpa den tredje regeln.

Man bör inte tänka på några hypoteser som helst förrän man har iakttagit noga systemets beteende. Man förtrycker alla försök att förklara vad som sker men bara tittar på det som körs. Att skriva sina iakttagelser är bra.

Sedan tittar man på alla fakta som samlades. Betydligt mindre vilseledande hypoteser överlever stor sådant antal fakta för att de sedan måste stämma med dem. Då återvänder man sig igen till regeln nummer ett: “förstå systemet”.

Den svåraste saken är visst att tvinga sig sluta analysera jämt och bara titta.

4. Söndra och erövra (dela och besegra)

Den här principen är urgammal men den gäller fortfarande: om något är för stor och komplex för att arbeta med, dela det till mindre delar och bearbeta dem.

Att ha insyn på av vilka delar systemet består hjälper självklart om man känner till systemet; se regeln nummer ett återigen.

5. Ändra en sak i taget

Varje system hat typiskt ett antal parameter eller justeringsmetoder som påverkar dess fungerande. En problemlösning består ofta av att hitta rätt inställningar.

Att försöka justera samtidigt fler än ett “vred” i taget leder dock inte till snabbare lösning. Däremot leder det till att det ursprungliga systemläget förloras. Då får man faktiskt ett nytt system som inte funkar heller, och behöver börja allt från ruta en. Det är mycket enklare hitta väg tillbaka när bara en parameter ändras oberoende av de andra. Det hjälper omättligt skriva ner vilka parameter som ändrades och i vilken ordning. Det leder oss till följande regel.

6. Håll ett revisionsspår

För det flesta fallen står problem inte just bredvid sina effekter. Ofta ligger en lång händelsekedja mellan felet och dess yttring, och deras koppling är inte uppenbar alls. Bara en sak kan man vara säker på, och det är att det tillfället med felet sker tidigare i tiden än samtliga dess följdverkningar.

Om man har ett slags “tidskrift” på alla händelser i systemet kan man gradvis tränga sig fram till symptomen bakåt dess orsak. Många tekniska system har revisionsspårsdelsystem inbyggde i dem precis av denna anledning, för att förenkla felsökning. Olika slags bokföring existerar precis av samma skäl för den förknippar orsaker och resultat även efter både de har passerat.

Detektiver i deckaren letar efter brottslings spår för att ta reda på vad som har hänt före dådet upphittats.

7. Kolla på proppen

Det händer oftast att en orsak är otänkbart uppenbar. Eftersom den är så enkel och otäck missar man den helt och letar istället efter några mer utarbetade varianter.

Det är vad man kallar “kontrollera om stickproppen sitter i uttaget” när någon elapparat inte funkar. Istället för att ta det isär för felsökning, kolla på vart dess sladd leder till. Det kostar ingenting och i de flesta fall löser det problemet av icke-fungerande system.

8. Få en fräsch synpunkt

En annan sida av människas psykologi är att vi är benägna att fastna oss i sina åsikter och antaganden och sedan ser vi inte väggen vidare. Då hjälper det oftast att be någon annan (en kollega, en vän, till och med en främling) att titta på problemet. De ser nämligen de möjligheter som slipper ens sikt eftersom de andra är fria av ens upplevelser och ens misslyckade lösningsförsök. Samtidigt andra människor har sina unika erfarenheter vilka de också får tillämpa.

Det hjälper mirakulöst även att förklara problem mot icke-levande varelser såsom en docka. Knepet är att när man förklarar något bekymmer till någon annan, annorlunda hjärndelar deltar i processen jämfört med när man tänker tigande på lösning själv. Det spelar ingen roll om lyssnaren verkligen lyssnar på vad som sägs, för att det är talaren som plötslig får nya idéer medan den förklarar. Därför finns en regel för studenter i visst universitet: innan de är tillåtna att bekymra antingen laboratorieassistent eller professor är de skyldiga att förklara sina strul till en assistentbjörn — en docka som sitter bredvid klassrummets entré. Oftast efter det behöver en student inte vidare anlita lärare.

9. Det är inte fixat om du inte fixat det

När ett sannolikt skäl till problemet uppfinnas är det lätt att bli upphetsad, åtgärda mot skälet och sedan inbilla sig att problemet nu är löst. Men vi vet nu att samma symptom kan framkallas av olika skäl. Vi har nämligen inte fått något säkert bevis att den valde lösningen positivt påverkar symptomen. Man måste testa systemet igen och kontrollera att det gamla problemet har försvunnit och några nya problem inte har uppstått.

Om det finns en misstanke att problemet har varit indeterministiskt, behöver man testa systemet flera gånger för att försäkra att den tillämpade lösningen har trätt i kraft.

Källor

  1. David J Agans. Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems, 2002. http://debuggingrules.com/

Written by Grigory Rechistov in Uncategorized on 10.04.2018. Tags: debugging, övning,


Copyright © 2018 Grigory Rechistov