Hvorfor stole på at brukerne dine rapporterer feil, er det dummeste du noen gang vil gjøre

Hvis du har ulykkelige brukere, hvordan ville du vite det?

Vi elsker alle å kode.

Når vi tenker på koding, ser vi vanligvis for oss å bygge.

Bygningsfunksjoner, nye innovasjoner, ny funksjonalitet og spennende oppdateringer som brukerne vil elske. Det er det mentale bildet som får oss begeistret for de tingene vi kan bygge videre.

Men de romantiske bildene i hodene våre blir ofte ikke oversatt til virkeligheten.

Programvareutviklere bruker mesteparten av tiden sin på andre oppgaver enn å bygge. De deltar på møter, diskuterer spesifikasjoner, planlegger og rydder opp i eksisterende kode. Og selvfølgelig er deres favorittaktivitet å fikse feil.

Jeg har ennå ikke møtt en utvikler som liker å finne problemer i kodebasen. Men denne frustrasjonen stammer sannsynligvis av at det å finne og reprodusere feil tar lang tid.

Historisk har programvareutviklere måttet søke etter nålen i høystakken. De har måttet finne svarene selv, i stedet for å stole på skjermdumpene fra brukere som er lagt ut i et Microsoft Word-dokument.

Vi har alle vært der!

Hvilken nettleser og versjon bruker du? Hvilket operativsystem? Kan du fortelle meg nøyaktig hvor du klikket? Hva skjedde så? Hvilken side var du på før? Hvordan kom du til og med til denne skjermen?

Så mange spørsmål, så få (nyttige) svar.

Å feilsøke et problem kan ta evig tid!

Stoler på at brukerne rapporterer problemer

Mange programvareutviklingsteam er fortsatt avhengige av at brukerne rapporterer problemer med applikasjonene sine.

Som er ganske sprø i disse dager.

Det er akkurat som fastfood-restaurantkjeder. De setter kundene i gang for å tømme sine egne bord ved å skaffe skuffer og søppelstasjoner. Restauranten kan ha vært forferdelig. Men kunden kunne rolig tømme bordet sitt, falt av søpla og gå bort. Med mindre de tar seg tid til å klage, antar ansatte at en annen fornøyd kunde nettopp forlot restauranten.

Men de kommer aldri tilbake.

Noen utviklere forventer at brukerne skal klare seg selv når de bruker applikasjonene sine. Tross alt, hvis ingen rapporterer om problemer, har vi ikke noe, ikke sant? Det å begrense brukerne dine til å rapportere problemene de opplever. Du vil se rundt en prosent av de totale forekomstene som påvirker hele brukerbasen, og tekniske detaljer vil være tynne og inkonsekvente.

Utviklere vil bruke mer tid på å prøve å feilsøke problemet - ved å bruke små informasjonsbiter enn å fikse det. Det er hvis de i det hele tatt kan finne problemet.

Programvaren din er ikke så god som du tror den er

Jeg snakket med en venn av meg som jobber for en stor nettforhandler. Han forklarte meg hvordan de hadde funnet et stort problem i deres online bestillingssystem som ingen hadde visst om.

Etter flere dager med etterforskning kunne de ikke finne problemet. På det tidspunktet bestemte de seg for å prøve ut et dedikert verktøy for å oppdage og diagnostisere feil i applikasjonen deres.

Det de fant var alarmerende.

Verktøyet identifiserte at en av de åtte serverne gikk tom for minne og kastefeil. Dette fikk brukerens betalingsstrøm til å stoppe fullstendig.

Én av hver åtte brukersjekk-økter ble ødelagt.

Å finne og fikse dette problemet resulterte i en øyeblikkelig uptick i salg på $ 20 000 i måneden! Folk hadde ikke lenger problemer under kjøpsprosessen.

De estimerte at det hadde påvirket over 5000 brukere - men de hadde bare mottatt to supportbilletter om det.

Selv om teamet var glade for å finne problemet, var det også en knusende skuffelse. En uidentifisert feil hadde sannsynligvis resultert i over $ 100 000 i tapte inntekter.

Det er en stum idé å sende deg selv e-post når feil oppstår

Du kan sitte å se på en live strøm av problemer som skjer i kodetilleggingsloggene. Og du kan ansette en varm kropp for å gjøre det mens du sover. Eller du kan sende deg en e-post når et ubehandlet unntak inntreffer - virker som en god ide!

Inntil du gjør det.

Hvis du konfigurerer dette, kan det se slik ut:

public void TryProcessLineNumber (int lineNumber)
{
    prøve
    {
        ProcessLineNumber (lineNumber);
    }
    fangst (unntak eks)
    {
        LetMyselfKnowViaEmail ("Noe gikk galt:" + ex.Message);
    }
}

Men pass på problemene det kan skape.

Sendingsfeil kan være egnet for mindre sideprosjekter og personlige prosjekter. Men når du utvider utenom det, begynner ting å bli rotete. Veldig, veldig rotete:

  • Diagnostiske detaljer er begrenset
  • Det er vanskelig å sette opp varslingsregler, og ting begynner å bli støyende
  • Et unntak fanget i en uendelig loop kan sende 50 000 e-postmeldinger til innboksen din over natten
  • Feil har ikke noe prioritert nivå eller påvirkningssynlighet, og alle virker like
  • Etter at du har mottatt mer enn hundre e-poster, gir du opp å lese dem

Ikke lenge etter at du begynner å sende deg feil, begynner du å ignorere dem. Eller du filtrerer dem inn i en mappe fordi det bare er så mye støy og ingen signal.

Du har igjen å tråle gjennom tusenvis av e-postmeldinger på jakt etter den rette feilforekomsten.

Vi trenger noe smartere.

ELMAH - loggfør unntakene dine

ELMAH (Error Logging Modules and Handlers) er et applikasjonsomfattende feilloggingsanlegg som er fullstendig pluggbar. Den kan dynamisk legges til et kjørende ASP.NET-webapplikasjon, eller til og med alle ASP.NET-webapplikasjoner på en maskin, uten noe behov for rekompilering eller omdisponering.

ELMAH støtter ikke alle programmeringsspråk og plattformer. Siden funksjonaliteten er ganske begrenset når du borer inn i årsaken til et problem, brukes den vanligvis til mindre prosjekter. Det er heller ikke egentlig i aktiv utvikling i disse dager, men det er i det minste noe, og det er gratis.

Elmah logging av feil

ELMAH er i utgangspunktet en NuGet-pakke for NET-applikasjoner. Den logger hvert unntak som forekommer på en eller flere nettsteder til lagringsplassen du velger. I motsetning til andre loggerammer, logger ELMAH seg automatisk inn på alle unntak når de konfigureres i sin enkleste form. Jada, det er en API du kan bruke til å logge tilpassede feil. Men de fleste bruker bare den automatiske delen. I denne opplæringen vil vi bare fokusere på de grunnleggende delene.

Her er en flott tutorial om hvordan du kommer i gang.

Dedikerte verktøy for rapportering av feil og krasj

Hvis du ser alvorlig på å håndtere feil og krasjer i applikasjonene dine, kan du bruke et dedikert verktøy for feilovervåking. Den oppdager og diagnostiserer problemer som påvirker brukerne dine automatisk ved å legge til en leverandør til programkoden.

Det er noen kodelinjer - det er alt som trengs.

Ved å bruke et verktøy som dette kan du:

  • Skjær ut støyende unntak og fokuser på tingene som betyr noe, for eksempel å påvirke brukere
  • Konfigurer konfigurerbare varsler via e-post, Slack eller HipChat
  • Bruk ett verktøy for å spore flere språk og plattformer
  • Dra fordel av feilgruppering for lignende feil
  • Hold hele teamet på toppen av feil og deres løsning
Bruk et dedikert programvare for feilovervåking som Raygun

Verktøy som disse er ikke billige eller gratis som de andre programmene vi har diskutert, men hvilken pris legger du på tiden din? Si at du bruker en gratis løsning. Da må du slutte å kode i tre timer mens du prøver å reprodusere en feil. Dette er faktisk en veldig dårlig avkastning.

Team som ønsker å bevege seg raskt og levere ny funksjonalitet til brukerne, vil si at slike profesjonelle løsninger er verdt hvert øre. De kan redusere tiden utviklerne bruker på å fikse feil og få dem tilbake til koding og forbedring av bygninger.

Selv om du synes koden din er perfekt, og brukere ikke har noen problemer, kobler du til et verktøy som Raygun. Du vil bli overrasket over hva du finner.

Ta en proaktiv tilnærming og høste fordelene

Vi vil alle elske teknologi for å fikse programvareproblemene våre automatisk. Dessverre tror jeg vi er en stund unna selvhelbredende og selvbevisst programvare.

Du kan også koble feilovervåkingsløsninger til utviklere arbeidsflyter for å gjøre feil og krasjoppløsning lettere. Men data er ofte skitten og adskilt fra sammenheng i andre systemer.

Fremtiden for feilovervåking ligger i å sørge for at alle team - frontend, back end, management eller support - har full synlighet på alle problemer brukerne møter. Og så ha evnen til å løse det med en gang.

Dette strekker seg også til kommende trender i kontinuerlig leverings- og distribusjonsplass. Du kan bruke reparasjoner og sende til produksjon innen få minutter etter at du har identifisert problemet. Du trenger ikke å vente uker før neste store distribusjon.

Sett fokuset på teamet ditt når du håndterer feil og krasjer i dine egne applikasjoner. Oppdag problemer før brukerne dine gjør det, og ikke stol på dem til å rapportere feil.

Fordi de ikke vil.