Er det noe som en feilfri applikasjon? [duplikat]

Det nærmeste du kommer en feilfri applikasjon, dyrere blir det. Det er som å målrette 100% kodedekning: du bruker like mye tid og penger på å komme fra 0% til 95%, fra 95% til 99% og fra 99% til 99,9%.

Trenger du disse ekstra 0,1% av kodedekningen eller kvaliteten? Sannsynligvis ja, hvis du jobber med et programvareprodukt som styrer kjølesystemet til en atomreaktor. Sannsynligvis ikke hvis du jobber med en forretningsapplikasjon.

For å lage programvare av høy kvalitet kreves det også en helt annen tilnærming . Du kan ikke bare be et team av utviklere som brukte livet sitt på å skrive forretningsapper om å lage et nesten feilfritt program. Programvare av høy kvalitet krever forskjellige teknikker, for eksempel formelt bevis , noe du absolutt ikke vil bruke i en forretningsapp på grunn av de ekstremt høye kostnadene det representerer.

Som jeg forklarte i en av artiklene mine :

• Forretningsapps bør ikke målrette kvaliteten som kreves for livskritisk programvare, for hvis disse forretningsappene mislykkes fra tid til annen, gjør det bare ikke » t saken. Jeg har sett feil og nedetid på nettsteder til sannsynligvis alle store selskaper, Amazon er det eneste unntaket. Denne nedetiden og disse feilene er irriterende og koster kanskje selskapet noen få tusen dollar per måned, men å fikse det vil være mye dyrere.

• Kostnadene bør være hovedfokuset, og bør studeres pragmatisk. La oss forestille oss en feil som påvirker 5 000 kunder og som er så viktig at disse kundene vil forlate for alltid. Er dette viktig? Ja? Tenk mer. Hva om jeg sier at hver av disse kundene betaler $ 10 per år og at det vil kostet nesten $ 100 000 for å fikse feilen? Feilretting ser nå mye mindre interessant ut.

Nå for å svare på spørsmålene dine spesifikt:

hvorfor blir feil rapportert selv etter å ha gjennomgått så mye testing? Er det vårt krav? Kunden vår virker ikke glad for noe vi tilbyr? gjør vi noe feil?

Mange ting kan gå galt. Med testing, mener du faktisk automatisert testing? Hvis ikke, er dette et stort problem i seg selv. Forstår testere kravene? Kommuniserer du med kunden med jevne mellomrom – minst en gang per iterasjon, i beste fall kundenes representant er umiddelbart tilgjengelig på stedet av ethvert medlem av teamet ditt ? Er iterasjonene dine korte nok? Tester utviklere sin egen kode?

På samme måte som De skriver de riktige tingene artikkelen som er lenket ovenfor, tar en feilrapport og studerer hvorfor denne feilen dukket opp i utgangspunktet, og hvorfor den ble savnet av hver tester . Dette kan gi deg noen ideer om hullene i teamets prosess.

Et viktig poeng å vurdere: betaler kunden for feilrettinger? Hvis ikke, kan han bli oppfordret til å vurdere mange ting å være en feil. Å få ham til å betale for tiden du bruker på feil, vil da redusere antall feilrapporter betraktelig.

Har noen utviklet noen applikasjoner som var helt feilfri? Hva er prosessen? Hvorfor kan vi ikke distribuere applikasjonen med mindre feil? Skal vi være perfeksjonister?

Meg. Jeg har skrevet en app for meg selv den siste helgen og har ikke funnet noen feil så langt.

Feil er bare feil når de blir rapportert. Så i teorien er det fullt mulig å ha en feilfri applikasjon: hvis den ikke brukes av noen, vil det ikke være noen som rapporterer feil.

Nå som du skriver et stort program som passer perfekt til spesifikasjon og er bevist å være korrekt (se formelt bevis nevnt ovenfor) er en annen historie. Hvis dette er et livskritisk prosjekt, bør dette være ditt mål (som ikke betyr din søknad vil være feilfritt).

Er det nåværende scenariet den riktige prosessen med utvikling og testing? Hvis ikke, hva er en effektiv måte der utviklere, testere og klienter får maksimalt utbytte sammen?

1. For å forstå hverandre , de burde kommunisere. Dette er ikke det som skjer i de fleste selskaper jeg har sett. I de fleste selskaper er prosjektleder den eneste som snakker med kunden (noen ganger med en representant).Deretter deler han (noen ganger delvis) sin forståelse av kravene med utviklere, interaksjonsdesignere, arkitekter, DBA og testere.

   Dette er grunnen til at det er viktig enten for kunden (eller kundens representant) å være tilgjengelig av alle i teamet (Agile approach) eller å ha formelle kommunikasjonsmidler som autoriserer en person til å kommunisere bare med noen få andre personer i et team og å gjøre det på en måte som informasjonen kan deles med hele teamet, å sikre at alle har den samme informasjonen.

2. Det er mange prosesser å gjøre utvikling og testing. Uten å vite nøyaktig om selskapet og teamet, er det ingen måte å bestemme hvilken som skal bli brukt i ditt tilfelle. Vurder å ansette en konsulent eller ansette en prosjektleder som er dyktig nok.

Kommentarer

• +1. Før du starter et prosjekt, må du ha forståelse for hva som er " god nok til frigjøring " og bygg deretter.
• @JuliaHayward Kunne ikke ' ikke enig mer. Sluttspillet her er ikke ' t null feil – det produserer funksjonell programvare som tilfører verdi i tide.

Ikke alle feil er skapt like, så du må sortere hveten fra agnet.

Forventninger

Mange feil heves bare på grunn av mangel på hva programvaren gjør og hva sluttbrukeren forventer. Denne forventningen kommer fra mange områder: ved hjelp av annen programvare, feil dokumentasjon, overivrig selgere, hvordan programvaren pleide å fungere osv. Osv.

Omfangskryp

Det sier seg selv at jo mer du leverer, jo større er potensialet for feil. Mange feil blir ganske enkelt hevet på baksiden av nye funksjoner. Du leverer X & Y men kunden sier at på baksiden av dette skal det nå også gjøre Z.

Forstå problemdomenet

Mange feil oppstår av den enkle årsaken at problemdomenet var dårlig forstått. Hver klient har sine egne forretningsregler, sjargong og måter å gjøre ting på. Mye av dette kan ikke dokumenteres hvor som helst – det vil bare være i hodet på mennesker. Med den beste viljen i verden, kan du ikke håpe å fange alt dette på en gang.

Så … hva du skal gjøre med det.

Automatiserte enhetstester

Mange bugs blir introdusert som en uventet bivirkning av en eller annen kodeendring. Hvis du har automatiserte enhetstester, kan du prøve mange av disse problemene og produsere bedre kode fra begynnelsen.

Testene er bare like gode som de oppgitte dataene – så sørg for at du forstår problemdomenet fullt ut.

Kodedekning

Dette går hånd i hånd med automatisert enhetstesting. Du bør sørg for at så mye kode testes som praktisk.

Lær leksjonene

Galskap gjør det samme igjen og igjen og igjen og forventer forskjellige resultater

Forstår du årsakene til den siste feilen? Gjør du? Virkelig? Du har kanskje stoppet problemet forekommer, men hva var den virkelige rotkilden? Dårlige data? Brukerfeil? Diskorrupsjon? Nettverksbrudd?

Ingenting irriterer klienter mer enn å møte de samme problemene igjen og igjen uten fremgang mot en eller annen form for løsning.

Avhenger av hva du kaller et program.

Hvis du mener et interaktivt program der du må være sikker på at sanntidsadferden er nøyaktig slik og slik under noen omstendigheter, så er det i utgangspunktet umulig å bevise at det ikke er noen feil i det. Jeg antar at det ville være mulig hvis du kunne løse stoppingsproblemet , men du kan ikke t.

Men hvis du begrenser deg til en uttalelse om «slik og slik innspill vil til slutt gi en slik og slik endelig tilstand», så er sjansene dine for et «feilfritt bevis» bedre, fordi du kan bruke invarianter . Det, og bare det, gjør det mulig å bryte ned korrekthetsbevis i delproblemer, som hver enkelt relativt enkelt kan bevises å fungere korrekt under alle omstendigheter av det gjenværende programmet (selv om du vanligvis ikke kan være veldig nøyaktig om hvor lang tid & minne det kan ta).

Slike teknikker er i utgangspunktet mulig i alle programmeringsspråk (selv om noen esoteriske som Malbolge prøver å avkrefte det !), men på alle tvingende språk blir det rotete veldig raskt, fordi du må metikoløst holde oversikt over mye implisitt programtilstand. I funksjonelle språk ¹ har bevisene en tendens til å se mye bedre ut ( rene språk , eller den rent funksjonelle delen av et språk). Likevel, spesielt med dynamiske typer, må du skrive ut mange krav til hvilke innganger som er tillatt. Det er selvfølgelig en av de viktigste fordelene med sterke statiske systemsystemer: Kravene er der i koden!
Vel, ideelt sett, altså. I praksis har O «Caml eller til og med Haskell-programmer en tendens til å inneholde ikke-funksjoner , dvs. funksjoner som vil krasje / henge / kaste for visse innganger, til tross for riktig type ² . For selv om disse språkene har veldig fleksible typesystemer, er det noen ganger fremdeles ikke mulig å bruke det til å begrense noe fullt ut.

Skriv inn språk som er avhengig av typen ! Disse kan «beregne» typene nøyaktig etter behov, så alt du definerer kan ha nøyaktig den typesignaturen som fremmer alt du trenger. Og avhengige typede språk blir faktisk mest lært som sikre miljøer em Dessverre tror jeg ingen av dem virkelig er i stand til å skrive produksjonsprogramvare. For praktiske applikasjoner tror jeg det nærmeste du kan komme fullstendig bug-proof er å skrive i Haskell med så grundig totale funksjoner som mulig. Dette får deg pen nær bug-proof – om enn, igjen, bare med hensyn til den funksjonelle beskrivelsen. «Den unike måten å håndtere IO med monader gir også noen veldig nyttige bevis, men det forteller deg generelt ikke noe om hvor lang tid det vil ta å bli ferdig. Ganske muligens, noe kan ta eksponentiell tid under spesielle omstendigheter – fra brukerens POV, som sannsynligvis vil være like alvorlig en feil som om programmet henger helt.