Kjenner du loven om minst forbauselse? Jeg er ikke sikker på sin opprinnelse, men jeg lærte det først fra den eksepsjonelle “Tao av programmering.” Enkelt sagt, det er prinsippet at programvaren alltid må svare på brukerne på en måte som minst forbauser dem. Med andre ord, Skriver ut et papir, bør ikke slette det fra filsystemet ditt.
Etter loven med minst forbauselse, hva må et program gjøre når det treffer en hard feil? Du kan si at det må la brukeren vite. Dessverre børster mange systemer bare under teppet i disse dager.
Jeg tror det startet med Windows. Eller kanskje Mac. Tanken går at sluttbrukerne er for dumme eller for frykt for feilkoder eller dybdegående meldinger, slik at vi bare forlater dem. Saks i punkt: Min kone iPhone ville ikke publisere bilder. Jeg er ingen ekspert med tanke på at jeg bærer en Android-enhet, men jeg ble enige om å se på den. Uansett hva jeg prøvde, fikk jeg den samme ubrukelige meldingen: “Kan ikke publisere bilder som er ideelle nå. Prøv igjen senere.” Ikke bare er dette ikke veldig informativt, men det innebærer også at problemet er i noe som kan fikse seg senere som nettverket.
Den virkelige skyldige? De iCloud vilkårene for bruk hadde endret seg, og hun hadde ikke akseptert den nye kontrakten. Jeg har en følelse, det kan ha dukket opp og spør henne om å gjøre det på et tidspunkt, men uansett grunn savnet hun det. Inntil du gravd inn i innstillingene og sjekket boksen for å godta disse vilkårene, “senere” skulle aldri skje.
Men det er ikke bare iPhones. Windows er full av ting som det, og du håper bare det vil være en logg inn hendelsen kunden med mange flere detaljer. Jeg ser også mye mer av det nå på Linux, selv om det vanligvis er en loggfil et sted hvis du vet hvordan du finner det. Mens jeg får det til at programmene har feil, risikerer risikoen for forbausende brukeren, er det enda mye mer forbløffende hvis det ikke er noen forklaring på hva som er galt. Tenk deg om banken din sendte deg et notat: Det er et problem med kontoen din. Så du svarer: “Har jeg overdraw?” De svarer, “Nei” hva nå? Det er delstaten av mange programvarefeil i dag.
Det er egentlig ingen unnskyldning på skrivebordssystemer eller nettsteder. Du vil imidlertid kanskje tilgi små innebygde systemer. Ikke! Jeg har nylig portet 3D-skriverens firmware Marlin til en ANET A8-bord – en 8-biters prosessor med lite minne – som hadde vært på repetier firmware for mange år. Første gang jeg prøvde å gjøre en autolevel-sonde, fikk jeg meldingen: Probing mislyktes. Det er det.
Jeg gir deg, at du kan slå på Autolevel-feilsøking for å få mye mer informasjon, men jeg er allerede på 98% blitsutnyttelse, så det ville kreve midlertidig å fjerne en haug med funksjoner og gjenoppbygge koden. Men hvorfor ikke liker at vi ville gjøre i gamle dager:
enhet global_error = 0;
void do_something (void) {
global_error = 1;
hvis (prosess1 () == mislykkes) retur;
global_error ++;
hvis (prosess2 () == mislykkes) retur;
. . .
global_error = 0;
komme tilbake;
}
Dette tar ikke mye plass. Nå kan du rapportere noe som probing mislyktes (8), og jeg kan i det minste gå til koden og finne ut hva det 8. trinnet var som mislyktes. Jeg er sikker på at noen vil til og med legge inn en liste over koder og hva de indikerte i et tilfelle som det.
For mye overhead? Fortell meg programtelleren der feilen skjedde. Som pleide å være en ganske vanlig praksis. Gitt, det krever at du har en minnekartfil og vet hvordan du leser det, men det er fortsatt bedre enn ingenting.
Vi bruker mye tid på å tenke hvordan prosjekter og programvare må arbeide. men vi må bruke tid på å tenke også, om hva som skjer når de ikke fungerer. Det er greit at vi kan gjøre i kretsen debugging eller hekte på en logikk analysator, men det vil ikke hjelpe våre brukere. selv om det er bare for deg, hvorfor ikke gjøre det litt enklere for deg selv?
Som vi har sagt før: “Det finnes ikke noe slikt som for mye informasjon.” I tillegg til å beskytte mot systemfeil, kan du også hjelpe brukerne til ikke å overraske seg selv.
Bilde Credit: [Elisa Ventur] ved hjelp av Unsplash.com