Existuje něco jako bezchybná aplikace? [duplicate]

Čím nejblíže se dostanete k aplikaci bez chyb, dražší to bude. Je to jako cílení na 100% pokrytí kódu: stejnou částku času a peněz strávíte získáváním z 0% na 95%, z 95% na 99% a z 99% na 99,9%.

Potřebujete dalších 0,1% pokrytí nebo kvality kódu? Pravděpodobně ano, pokud pracujete na softwarovém produktu, který řídí chladicí systém jaderného reaktoru. Pravděpodobně ne, pokud pracujete na obchodní aplikaci.

Výroba vysoce kvalitního softwaru také vyžaduje velmi odlišný přístup . Nemůžete jen požádat tým vývojářů, kteří strávili celý život psaním obchodních aplikací, aby vytvořili téměř bezchybnou aplikaci. Vysoce kvalitní software vyžaduje různé techniky, například formální důkaz , něco, co určitě nechcete používat v obchodní aplikaci kvůli extrémně vysokým nákladům, které představuje.

Jak jsem vysvětlil v jednom z moje články :

• Obchodní aplikace by neměly „cílit na kvalitu požadovanou pro životně důležitý software, protože pokud tyto obchodní aplikace občas selžou, prostě to tak není“ Nevadí. Viděl jsem chyby a prostoje na webových stránkách pravděpodobně každé velké společnosti, Amazon je jedinou výjimkou. Tento prostoj a ty chyby jsou otravné a možná by to společnost stálo několik tisíc dolarů měsíčně, ale její oprava by byla mnohem dražší.

• Primárním zaměřením by měly být náklady, a měl by být studován pragmaticky. Představme si chybu, která ovlivňuje 5 000 zákazníků a je tak důležitá, že tito zákazníci navždy odejdou. Je to důležité? Ano? Zamyslete se více. Co když řeknu, že každý z těchto zákazníků platí 10 $ ročně a že bude stojí oprava chyby téměř 100 000 $? Oprava chyby nyní vypadá mnohem méně zajímavě.

Nyní, abychom konkrétně odpověděli na vaše otázky:

Proč se chyby hlásí i po absolvování tolika testování? Je to problém s našimi požadavky? Náš klient nevypadá šťastně za nic, co poskytneme? děláme něco nesprávného?

Mnoho věcí se může pokazit. Pod pojmem testování myslíte skutečné automatické testování? Pokud ne, představuje to sám o sobě obrovský problém. Rozumí testeři požadavkům? Komunikujete se zákazníkem pravidelně – alespoň jednou za iteraci, v nejlepším případě zástupce zákazníka je okamžitě dostupný na místě jakýmkoli členem vašeho týmu ? Jsou vaše iterace dostatečně krátké? Testují vývojáři svůj vlastní kód?

Podobně jako píší správné články výše uvedený článek, provést hlášení o chybě a prostudovat proč se tato chyba objevila na prvním místě a proč ji každý tester minul. To vám může poskytnout nějaké představy o mezerách v procesu vašeho týmu.

Je důležité si uvědomit: platí váš zákazník za opravy chyb? Pokud ne, může být vyzván, aby zvážil spoustu věcí buďte bugem. Když ho zaplatíte za čas, který strávíte chybami, pak to značně sníží počet hlášení chyb.

Vyvinul někdo nějakou aplikaci, která byla zcela bez chyb? Jaký je proces? Proč nemůžeme aplikaci nasadit s menšími chybami? Máme být perfekcionisté?

Já. Minulý víkend jsem pro sebe napsal aplikaci a zatím jsem nenašel žádnou chybu.

Chyby jsou pouze chyby, když jsou nahlášeny. Teoreticky je tedy bezchybná aplikace zcela možná: pokud ji nikdo nepoužívá, nebude mít nikdo hlášení chyb.

Nyní, když píšeme rozsáhlou aplikaci, která dokonale odpovídá specifikace a je prokázáno, že je správná (viz výše uvedený formální důkaz), je jiný příběh. Pokud se jedná o životně důležitý projekt, měl by to být váš cíl (což neznamená vaši žádost bude bez chyb).

Je aktuální scénář správným procesem vývoje a testování? Pokud ne, jaký je efektivní způsob, kdy vývojáři, testeři a klient získají maximální užitek společně?

1. Abychom si rozuměli , měli by komunikovat. Tohle se ve většině společností neděje. Viděl jsem. Ve většině společností je projektový manažer jediný, kdo mluví se zákazníkem (někdy se zástupcem).Poté sdílí (někdy částečně) své chápání požadavků s vývojáři, návrháři interakcí, architekty, organizacemi DBA a testery.

   Proto je pro zákazníka (nebo jeho zástupce) zásadní být dosažitelný kýmkoli v týmu (agilní přístup) nebo mít formální komunikační prostředky, které opravňují osobu komunikovat pouze s několika dalšími osobami v týmu a dělat to tak, aby informace mohly být sdíleny s celým týmem, zajistit, aby měl každý stejné informace.

2. Vývoj a testování je možné provádět mnoha procesy. Bez přesné znalosti společnosti a týmu neexistuje způsob, jak určit, který z nich by měl být ve vašem případě použijte. Zvažte najmutí konzultanta nebo najmutí dostatečně zkušeného projektového manažera.

Komentáře

• +1. Než zahájíte projekt, musíte pochopit, co je " dost dobré na vydání " a podle toho stavět.
• @JuliaHayward Nelze ' souhlasit více. Konečná hra zde nemá ' nulové vady – produkuje funkční software, který přidává hodnotu včas.

Ne všechny chyby jsou vytvářeny stejně, takže musíte pšenici vytřídit z plevy.

Očekávání

Mnoho chyb se objevuje jednoduše kvůli nedostatku v tom, co software dělá a co koncový uživatel očekává. Toto očekávání pochází z mnoha oblastí: používání jiného softwaru, nesprávná dokumentace, příliš horlivý prodejní personál, způsob, jakým software dříve fungoval atd.

Scope creep

Je samozřejmé, že čím více dodáte, tím větší je potenciál chyb. Mnoho chyb se jednoduše objevuje na zadní straně nových funkcí. Dodáváte X & Y, ale zákazník říká, že na zadní straně by to nyní mělo dělat také Z.

Pochopte problémovou doménu

Mnoho chyb nastává z prostého důvodu, že problémové doméně bylo špatně porozuměno. Každý klient má svá vlastní obchodní pravidla, žargon a způsoby, jak dělat věci. Hodně z toho nebude nikde zdokumentováno – bude to jen v hlavách lidí. S nejlepší vůlí na světě nemůžete doufat, že to všechno zachytíte najednou.

Takže … co s tím dělat.

Automatizované testy jednotek

Mnoho chyb je představeno jako neočekávaný vedlejší účinek nějaké změny kódu. máte automatizované jednotkové testy, můžete vyřešit mnoho z těchto problémů a od samého začátku vytvářet lepší kód.

Testy jsou pouze tak dobré jako dodaná data – ujistěte se proto, že plně rozumíte problémové doméně.

Pokrytí kódu

To jde ruku v ruce s automatickým testováním jednotek. Měli byste ujistěte se, že je testováno tolik kódu, kolik je praktické.

Naučte se lekce

Šílenství dělá to samé znovu a znovu a znovu a očekává jiné výsledky

Rozumíte příčinám posledního selhání? Opravdu? Možná jste přestali problém vyskytující se, ale jaký byl pravý kořenový zdroj? Špatná data? Chyba uživatele? Poškození disku? Výpadek sítě?

Nic neobtěžuje klienty víc než opakované problémy se stejnými problémy bez pokroku směrem k nějaké formě řešení.

Vady existovaly od začátku vývoje softwaru. Z vaší otázky je těžké určit, do jaké míry a jaké závažnosti mají vady vliv na použitelnost nebo funkčnost.

Existují bezvadné programy, ale téměř každý netriviální systém bude mít vady.

Budete se muset rozhodnout pro jakýsi druh stanovení priorit a pravděpodobně budete muset udělat nějaké studium příčin závad – kde byly zavedeny. O takových věcech je příliš mnoho k diskusi v jednoduchém Q & Příspěvek.

Byly napsány celé knihy o kauzální analýze a opravném procesu pro organizaci, která má problémy s kvalitou.

Takže moje doporučení je: (v žádném konkrétním pořadí)

• Implementovat systém sledování defektů, pokud jste jej dosud nenašli
• Určete způsob klasifikace závažnosti defektů
• Zjistěte, proč nesplňujete očekávání zákazníků (jsou to vývojáři, QA, zákazník atd.)
• Zjistěte více o některých cvičeních, jako je „Pět důvodů“, a proveďte podobné vyšetřování některé z příčin vašich vad.

Závisí na tom, čemu říkáte aplikace.

Pokud máte na mysli interaktivní program, kde si musíte být jisti, že chování v reálném čase je za všech okolností přesně takové a takové, pak je v zásadě nemožné prokázat, že zde nejsou žádné chyby v tom. Předpokládám, že by bylo možné, kdybyste mohli vyřešit problém se zastavením , ale nemůžete. T.

Pokud se však omezíte na prohlášení „takový a takový vstup nakonec přinese takový a takový konečný stav“, pak jsou vaše šance na „bezchybný důkaz“ lepší, protože můžete použít invarianty . To a jen to umožňuje rozčlenit důkaz správnosti v dílčích problémech, z nichž lze relativně snadno prokázat, že správně funguje za všech okolností zbývajícího programu (i když obvykle nemůžete být velmi přesní, kolik času & paměti může zabrat).

Takové techniky jsou v zásadě možné v jakémkoli programovací jazyk (i když některé esoterické, jako je Malbolge , se snaží to ! vyvrátit!), ale ve všech imperativních jazycích je velmi rychle nepořádek, protože musíte hodně pečlivě sledovat implicitní stav programu. Ve funkčních jazycích ¹ mají důkazy tendenci vypadat mnohem hezčí ( čisté jazyky nebo čistě funkční podmnožina jazyka). Stále, zejména u dynamických typů, budete muset napsat spoustu požadavků na to, jaké vstupy jsou povoleny. To je samozřejmě jedna z hlavních výhod silných systémů statického typu: požadavky jsou přímo v kódu!
No, v ideálním případě to je. V praxi programy O „Caml nebo dokonce Haskell mají tendenci obsahovat nontotal functions , tj. funkce, které se při určitých vstupech zhroutí / zablokují / vyhodí, navzdory správnému typu ² . Protože i když tyto jazyky mají velmi flexibilní typy systémů, je někdy stále nemožné je použít k úplnému omezení.

Zadejte jazyky se závislým typem ! Ty mohou „vypočítat“ typy přesně podle potřeby, takže vše, co definujete, může mít přesně ten typový podpis, který prokáže vše, co potřebujete. A skutečně, jazyky se závislým typem se většinou vyučují jako prostředí prostředí . Bohužel si myslím, že žádný z nich opravdu není na psaní produkčního softwaru. U praktických aplikací se domnívám, že nejblíže k zcela odolné proti chybám je psaní v Haskellu se stejně důkladnými funkcemi jako možné. Tím se pěkně přiblížíte k odolnosti proti chybám –, i když opět pouze s ohledem na funkční popis. Haskell „Jedinečný způsob zpracování IO s monadami také poskytuje několik velmi užitečných důkazů, ale obecně vám neříká nic o tom, jak dlouho bude něco trvat Dokončit. Je docela možné, že za určitých okolností – z POV uživatele může něco trvat exponenciální čas, což by pravděpodobně byla stejně závažná chyba, jako kdyby program úplně visel.

¹ _{Nebo obecněji popisné jazyky. S logickými jazyky nemám mnoho zkušeností, ale předpokládám, že mohou být podobně pěkné jako důkaz jde.}

² _{Pokud nejde o správný typ, překladač jej nikdy v těchto jazycích nepovolí; což již eliminuje spoustu chyb. (A díky odvození typu Hindley-Milner také činí programy stručnějšími!)}

Komentáře

• " Pokud máte na mysli interaktivní program, kde si musíte být jisti, že chování v reálném čase je za všech okolností přesně takové a takové, pak to ' v zásadě nelze dokázat, že ' nejsou žádné chyby v tom. Předpokládám, že by bylo možné, kdybyste mohli problém se zastavením vyřešit, ale můžete ' t. ": nejsem si jistý, jestli to prohlášení je správné. Nelze ověřit libovolný program, ale co program, který jste napsali takovým způsobem, který takové ověření umožňuje?
• Viz např. cs.cmu.edu/~rwh/smlbook/book.pdf , na začátku stránky 198: " Nakonec je důležité si uvědomit, že specifikace, implementace a ověření jdou ruku v ruce. Je nereálné navrhnout ověřit, zda libovolný kus kódu splňuje libovolnou specifikaci. Výsledky základní vypočítatelnosti a složitosti jasně ukazují, že v takovém úsilí nikdy nemůžeme uspět. Naštěstí je to také zcela umělé. V praxi specifikujeme, kódujeme a ověřujeme současně, přičemž každá aktivita informuje druhou."
• @Giorgio: určitě můžete psát některé programy způsobem, který takové ověření umožňuje , ale to vás docela docela omezuje mnoho. Ve velkém programu budete ' téměř vždy někde využívat Turingovu úplnost. – Ano, v praxi zadáte, kódujete a " ověřujete " současně, ale toto ověření je často dostatečně heuristické (na základě např. Testů jednotek , nikoli skutečné důkazy).
• Co myslíte tím, že " využíváte Turingovu úplnost "?
• " … ale toto ověření je často dostatečně heuristické (na základě např. jednotkových testů, nikoli skutečných důkazů) ": Ne , pokud si pozorně přečtete poznámky, hovoří o prokázání správnosti pomocí formálních metod (např. pomocí indukce), nemluví o jednotkových testech. Viz také compcert.inria.fr/doc .