Er der noget som en fejlfri applikation? [duplikat]

Det tætteste du kommer til en fejlfri applikation, dyrere bliver det. Det er som at målrette mod 100% kodedækning: du bruger den samme mængde tid og penge på at komme fra 0% til 95%, fra 95% til 99% og fra 99% til 99,9%.

Har du brug for denne ekstra 0,1% af kodedækning eller kvalitet? Sandsynligvis ja, hvis du arbejder på et softwareprodukt, der styrer kølesystemet i en atomreaktor. Sandsynligvis ikke hvis du arbejder på en forretningsapplikation.

For at lave software af høj kvalitet kræves det også en meget anden tilgang . Du kan ikke bare bede et team af udviklere, der brugte deres liv på at skrive forretningsapps, om at oprette en næsten fejlfri applikation. Software af høj kvalitet kræver forskellige teknikker, såsom formel bevis , noget du bestemt ikke vil bruge i en forretningsapp på grund af de ekstremt høje omkostninger, det repræsenterer.

Som jeg forklarede i en af mine artikler :

• Forretningsapps bør ikke målrette den krævede kvalitet til livskritisk software, for hvis disse forretningsapps fejler fra tid til anden, gør det bare ikke ” Det betyder ikke noget. Jeg har set fejl og nedetid på websteder for sandsynligvis alle store virksomheder, hvor Amazon er den eneste undtagelse. Denne nedetid og disse fejl er irriterende og koster måske virksomheden et par tusinder af dollars om måneden, men at rette op på det ville være meget dyrere.

• Omkostninger bør være det primære fokus, og bør undersøges pragmatisk. Lad os forestille os en fejl, der påvirker 5.000 kunder og er så vigtig, at disse kunder forlader for evigt. Er dette vigtigt? Ja? Tænk mere. Hvad hvis jeg siger, at hver af disse kunder betaler $ 10 om året, og at det vil koster næsten $ 100.000 for at rette fejlen? Fejlretning ser nu meget mindre interessant ud.

Nu for at besvare dine spørgsmål specifikt:

hvorfor rapporteres bugs selv efter at have gennemgået så meget test? Er det vores kravsproblem? Vores klient synes ikke glad for noget, vi leverer? laver vi noget forkert?

Mange ting kan gå galt. Ved test, mener du faktisk automatisk testning? Hvis ikke, er dette et stort problem i sig selv. Forstår testere kravene? Kommunikerer du med kunden regelmæssigt – mindst en gang pr. Iteration, i bedste fald kan kundens repræsentant straks nås på stedet af ethvert medlem af dit team ? Er dine iterationer korte nok? Tester udviklere deres egen kode?

På samme måde som De skriver de rigtige ting artiklen linket ovenfor, tager en fejlrapport og studerer hvorfor denne fejl dukkede op med det første, og hvorfor den blev savnet af hver tester . Dette kan give dig nogle ideer om hullerne i dit teams proces.

Som et vigtigt punkt at overveje: betaler din kunde for fejlrettelser? Hvis ikke, kan han blive opfordret til at overveje mange ting at være en fejl. At få ham til at betale for den tid, du bruger på fejl, reducerer derefter antallet af fejlrapporter betydeligt.

Har nogen udviklet nogen applikationer, der var helt fejlfri? Hvad er processen? Hvorfor kan vi ikke implementere applikationen med mindre fejl? Skal vi være perfektionistiske?

Mig. Jeg har skrevet en app til mig selv sidste weekend og har ikke fundet nogen fejl indtil videre.

Fejl er kun fejl, når de rapporteres. Så i teorien er det fuldstændigt muligt at have en bug-fri applikation: hvis den ikke bruges af nogen, vil der ikke være nogen til at rapportere bugs.

Skriv nu en applikation i stor skala, der passer perfekt til specifikation og det er bevist at være korrekt (se formelt bevis nævnt ovenfor) er en anden historie. Hvis dette er et livskritisk projekt, skal dette være dit mål (hvilket ikke betyder din ansøgning vil være fejlfri).

Er det aktuelle scenarie den korrekte proces til udvikling og test? Hvis ikke, hvad er en effektiv måde, hvor udviklere, testere og klienter får den maksimale fordel sammen?

1. For at forstå hinanden , de burde kommunikere. Dette er ikke, hvad der sker i de fleste virksomheder, jeg har set. I de fleste virksomheder er projektleder den eneste, der taler med kunden (nogle gange med en repræsentant).Derefter deler han (undertiden delvist) sin forståelse af kravene med udviklere, interaktionsdesignere, arkitekter, DBAer og testere.

   Dette er grunden til, at det er vigtigt enten for kunden (eller kundens repræsentant) at være tilgængelig for alle i teamet (Agile tilgang) eller have formelle kommunikationsmidler, der bemyndiger en person til kun at kommunikere med et par andre personer i et team og gøre det på en måde, så informationen kan deles med hele teamet at sikre, at alle har de samme oplysninger.

2. Der er mange processer, der skal udvikles og testes. Uden at vide nøjagtigt virksomheden og teamet er der ingen måde at afgøre, hvilken man skal anvendes i dit tilfælde. Overvej at ansætte en konsulent eller ansætte en projektleder, der er dygtig nok.

Kommentarer

• +1. Før du selv starter et projekt, skal du have en forståelse af, hvad der er " god nok til frigivelse " og bygg derefter.
• @JuliaHayward Kunne ikke ' ikke være mere enige. Slutspillet her er ikke ' t nul defekter – det producerer funktionel software, der tilføjer værdi rettidigt.

Ikke alle bugs er skabt ens, så du skal sortere hveden fra agnet.

Forventninger

Mange bugs hæves simpelthen på grund af en mangel på, hvad softwaren gør, og hvad slutbrugeren forventer. Denne forventning kommer fra mange områder: ved hjælp af anden software, forkert dokumentation, alt for ivrig salgspersonale, hvordan softwaren plejede at fungere osv. Osv.

Scope creep

Det siger sig selv, at jo mere du leverer, jo større er potentialet for fejl. Mange bugs hæves simpelthen på bagsiden af nye funktioner. Du leverer X & Y, men kunden siger, at det på bagsiden af dette nu også skal gøre Z.

Forstå problemdomænet

Mange bugs opstår af den simple grund, at problemdomænet blev dårligt forstået. Hver klient har deres egne forretningsregler, jargon og måder at gøre tingene på. Meget af dette kan ikke dokumenteres hvor som helst – det vil bare være i folks hoveder. Med den bedste vilje i verden kan du ikke håbe at fange alt dette på én gang.

Så … hvad skal man gøre ved det.

Automatiserede enhedstest

Mange bugs introduceres som en uventet bivirkning af en eller anden kodeændring. Hvis du har automatiserede enhedstest, kan du afværge mange af disse problemer og producere bedre kode fra starten.

Test er kun lige så gode som de leverede data – så sørg for, at du forstår problemdomænet fuldt ud.

Kodedækning

Dette går hånd i hånd med automatiseret enhedstest. Du bør sørg for, at så meget kode testes som praktisk.

Lær lektionerne

Galskab gør det samme igen og igen og igen og forventer forskellige resultater

Forstår du årsagerne til den sidste fiasko? Gør du? Virkelig? Du er muligvis stoppet problemet forekommer, men hvad var den sande rodkilde? Dårlige data? Brugerfejl? Disk korruption? Netværksafbrydelse?

Intet irriterer klienter mere end at støde på de samme problemer igen og igen uden fremskridt hen imod en eller anden form for opløsning.

Afhænger af, hvad du kalder en applikation.

Hvis du mener, et interaktivt program, hvor du skal være sikker på, at realtidsadfærden er nøjagtig sådan og sådan under alle givne omstændigheder, så er det dybest set umuligt at bevise, at der ikke er nogen fejl i det. Jeg formoder, at det ville være muligt, hvis du kunne løse standsningsproblemet , men du kan ikke t.

Men hvis du begrænser dig til en erklæring om “sådan og sådan input vil i sidste ende give sådan en sådan endelig tilstand”, så er dine chancer for en “bug-free proof” bedre, fordi du kan bruge invariants . Dette, og kun det, gør det muligt at opdele et korrekthedsbevis i underproblemer, som hver især relativt let kan bevises at fungere korrekt under alle omstændigheder af det resterende program (selvom du generelt ikke kan være meget nøjagtige om, hvor lang tid & hukommelse det kan tage).

Sådanne teknikker er dybest set mulige i enhver programmeringssprog (selvom nogle esoteriske som Malbolge forsøger at afkræfte det !), men på alle tvingende sprog bliver det rodet meget hurtigt, fordi du skal nøjagtigt holde styr på en masse implicit programtilstand. På funktionelle sprog ¹ har bevisene en tendens til at se meget pænere ud ( rene sprog eller den rent funktionelle delmængde af et sprog). Især med dynamiske typer bliver du stadig nødt til at skrive en masse krav om, hvilke input der er tilladt. Det er selvfølgelig en af de største fordele ved stærke statiske typesystemer: kravene er lige der i koden!
Nå, ideelt set, altså. I praksis har O “Caml eller endda Haskell-programmer tendens til at indeholde ikke-samlede funktioner , dvs. funktioner, der går ned / hænger / kaster for visse indgange på trods af den korrekte type ² . For selvom disse sprog har meget fleksible systemsystemer, er det sommetider stadig ikke muligt at bruge det til at begrænse noget fuldt ud.

Indtast sprog, der er skrevet afhængigt. ! Disse kan “beregne” typer nøjagtigt efter behov, så alt, hvad du definerer, kan have nøjagtig den typesignatur, der fremviser alt hvad du behøver. Og afhængigt-typede sprog undervises faktisk som bevismiljøer em Desværre tror jeg, at ingen af dem virkelig er i stand til at skrive produktionssoftware. Til praktiske applikationer tror jeg, at det tætteste du kan komme til helt bug-proof er at skrive i Haskell med så grundigt samlede funktioner som muligt. Det får dig smuk tæt på bug-proof – omend, kun igen med hensyn til den funktionelle beskrivelse. “Den unikke måde at håndtere IO med monader giver også nogle meget nyttige beviser, men det fortæller dig generelt ikke noget om, hvor lang tid noget tager at Afslut. Meget muligvis kan noget tage eksponentiel tid under særlige omstændigheder – fra brugerens POV, hvilket sandsynligvis ville være en så alvorlig fejl, som hvis programmet hænger helt.