Van valami hibamentes alkalmazás? [duplicate]

A legközelebb egy hibamentes alkalmazáshoz jut, drágább lesz. Olyan, mint a 100% -os kód lefedettség megcélzása: ugyanannyi időt és pénzt tölt el 0% -tól 95% -ig, 95% -tól 99% -ig és 99% -tól 99,9% -ig.

Szüksége van erre a kód lefedettségének vagy minőségének további 0,1% -ára? Valószínűleg igen, ha olyan szoftverterméken dolgozik, amely vezérli az atomreaktor hűtőrendszerét. Valószínűleg nem, ha üzleti alkalmazáson dolgozik.

A kiváló minőségű szoftverek elkészítéséhez is szükség van. egészen más megközelítés . Nem lehet csak megkérni egy olyan fejlesztői csapatot, akik életüket üzleti alkalmazások írásával töltötték, hogy hozzanak létre egy szinte hibamentes alkalmazást. A kiváló minőségű szoftverek különböző technikákat igényelnek, például hivatalos igazolást , olyasmit, amelyet biztosan nem szeretne használni üzleti alkalmazásban, az általa képviselt rendkívül magas költségek miatt.

Amint azt a részben kifejtettem cikkeim :

• Az üzleti alkalmazásoknak nem szabad az életkritikus szoftverekhez szükséges minőséget megcélozniuk, mert ha ezek az üzleti alkalmazások időről időre kudarcot vallanak, akkor egyszerűen nem ” Nem számít. Valószínűleg minden nagyvállalat webhelyén hibákat és leállásokat láttam, ez alól az egyetlen kivétel az Amazon. Ez a leállás és ezek a hibák bosszantóak, és havi néhány ezer dollárba kerülhetnek a vállalatnak, de ennek kijavítása sokkal drágább lenne.

• A költségeknek kell az elsődleges hangsúlyt fektetni, és pragmatikusan kell tanulmányozni. Képzeljünk el egy hibát, amely 5000 ügyfelet érint és olyan fontos, hogy ezek az ügyfelek örökre távoznak. Fontos ez? Igen? Gondolkodjon tovább. Mi lenne, ha azt mondanám, hogy mindegyik ügyfél évente 10 dollárt fizet, és Majdnem 100 000 dollárba került a hiba kijavítása? A hibajavítás most sokkal kevésbé érdekes.

Most, hogy konkrétan válaszoljon kérdéseire:

miért jelentik a hibákat még annyi tesztelés után is? Ez a követelményekkel kapcsolatos probléma? Ügyfelünk nem tűnik elégedettnek semmit, amit nyújtunk? valamit helytelenül csinálunk?

Sok minden elromolhat. Tesztelés alatt a tényleges automatizált tesztet érted? Ha nem, ez önmagában is óriási probléma. A tesztelők megértik a követelményeket? Rendszeresen kommunikál-e az ügyféllel – iterációnként legalább egyszer, legfeljebb az ügyfélképviseletet azonnal elérheti a helyszínen a csapat bármely tagja ? Elég rövidek az iterációk? A fejlesztők tesztelik a saját kódjukat?

A hasonlóan a megfelelő cikkek hez hasonlóan, a fentiekben linkelt cikkekhez hasonlóan hibajelentést készít és tanulmányoz miért jelent meg először ez a hiba, és miért hagyta ki minden tesztelő . Ez ötleteket adhat a csapata folyamatának hiányosságairól.

Fontos megfontolandó szempont: fizet-e ügyfele hibajavításokért? Ha nem, akkor arra ösztönözhetik, hogy fontoljon meg sok mindent. légy hibás. Ha rákényszeríted a hibára fordított időre, ez jelentősen csökkenti a hibabejelentések számát.

Fejlesztett valaki olyan alkalmazást, amelyet teljesen hibamentes? Mi a folyamat? Miért nem telepíthetjük az alkalmazást kisebb hibákkal? Állítólag perfekcionisták vagyunk?

Én. A múlt hétvégén írtam magamnak egy alkalmazást, és eddig nem találtam hibát.

A hibák csak akkor jelentenek hibát, ha bejelentik őket. Tehát elméletileg egy hibamentes alkalmazás használata teljesen lehetséges: ha azt senki nem használja, akkor senki sem jelentheti a hibákat.

Most egy olyan nagyszabású alkalmazást írhat, amely tökéletesen megfelel a specifikáció és bizonyítottan helytálló (lásd a fent említett hivatalos igazolást) egy másik történet. Ha ez életkritikus projekt, akkor ez legyen a célod (ami nem jelenti az alkalmazásodat hiba nélkül lesz).

A jelenlegi forgatókönyv a fejlesztés és tesztelés helyes folyamata? Ha nem, mi az a hatékony módszer, ahol a fejlesztők, a tesztelők és az ügyfelek együtt érik el a maximális hasznot?

1. Egymás megértése érdekében , kommunikálniuk kell. Ez nem történik meg a legtöbb általam látott vállalatnál. A legtöbb vállalatnál a projektvezető az egyetlen, aki beszél az ügyféllel (néha egy képviselővel).Ezután megosztja (néha részben) a követelményekkel kapcsolatos megértését a fejlesztőkkel, az interakciótervezőkkel, az építészekkel, a fejlesztési szakértőkkel és a tesztelőkkel.

   Ezért vagy az ügyfél (vagy az ügyfél képviselője) számára elengedhetetlen, hogy legyen elérhető bárki számára a csoportban (agilis megközelítés), vagy legyenek olyan hivatalos kommunikációs eszközök, amelyek felhatalmazzák az embert arra, hogy csak néhány más személyrel kommunikáljon a csapatban, és ezt úgy tegye meg, hogy az információkat meg lehessen osztani az egész csapattal, annak biztosítása, hogy mindenki ugyanazokkal az információkkal rendelkezzen.

2. Számos folyamatot kell fejleszteni és tesztelni. A vállalat és a csapat pontos ismerete nélkül nincs mód arra, hogy meghatározzuk, melyiket kell alkalmazza az Ön esetére. Fontolja meg tanácsadó vagy egy elég ügyes projektvezető alkalmazását.

Megjegyzések

• +1. Mielőtt még elindítaná a projektet, meg kell értenie, hogy mi " elég jó a kiadáshoz " és ennek megfelelően épít.
• @ JuliaHayward nem tudott ' egyetérteni. A végjáték itt nem ' nincs null hiba – olyan funkcionális szoftvert állít elő, amely időben hozzáadott értéket képvisel.

Nem minden hiba jön létre egyenlően, ezért a búzát ki kell rendezni a pelyvából.

Elvárások

Sok hibát egyszerűen a szoftver működésének és a végfelhasználó elvárásainak hiánya okoz. Ez az elvárás sok területről származik: más szoftverek használata, hibás dokumentáció, túlbuzgó értékesítő személyzet, a szoftver működése stb.

Kúszik

Magától értetődik, hogy minél többet szállít, annál nagyobb a hiba lehetősége. Sok hiba egyszerűen felmerül az új funkciók hátterében. Ön szállítja az X & Y-t, de az ügyfél azt mondja, hogy ennek hátulján most Z-t is kell tennie.

A probléma tartományának megértése

Sok hiba abból az egyszerű okból következik be, hogy a problémás tartományt rosszul értették. Minden ügyfélnek megvannak a maga üzleti szabályai, zsargonja és módja a dolgoknak. Ennek nagy részét sehol sem dokumentálják – csak az emberek fejében lesz. A világ legjobb akaratával nem reménykedhet abban, hogy mindezt egyetlen menetben rögzíti.

Tehát … mit tegyen ez ellen.

Automatizált egység tesztek

Sok hibát egy vagy más kódváltozás váratlan mellékhatásaként vezetnek be. automatizált egységtesztekkel rendelkezik, számos problémát kiküszöbölhet, és már a kezdetektől jobb kódot készíthet.

A tesztek csak olyan jók, mint a megadott adatok – ezért győződjön meg róla, hogy teljesen megértette a problémás tartományt.

Kód lefedettség

Ez együtt jár az egységek automatizált tesztelésével. győződjön meg róla, hogy annyi kódot tesztelnek, ahány praktikus.

Tanulja meg a tanulságokat

Az őrület ugyanazt csinálja újra és újra, és más eredményekre számít

Érted az utolsó kudarc okait? Ugye? Tényleg? Lehet, hogy abbahagytad a probléma de mi volt az igazi gyökérforrás? Rossz adatok? Felhasználói hiba? Lemezkorrupció? Hálózati kimaradás?

Semmi sem bosszantja jobban az ügyfeleket, mint hogy ugyanazokkal a problémákkal szembesüljenek újra és újra anélkül, hogy előrelépnének valamilyen megoldási lehetőség felé.

A szoftverfejlesztés kezdetétől fogva léteznek hibák. Kérdéséből nehéz megmondani, hogy a hibák milyen mértékben és milyen súlyossággal befolyásolják a használhatóságot vagy a funkcionalitást.

Hibáktól mentes programok léteznek, de szinte minden nem triviális rendszernek vannak hibái.

Dönteni kell valamilyen fontossági sorrendről, és valószínűleg meg kell vizsgálnia a hibák okát – hol vezették be. Túl sok mindent kell megvitatni ilyen kérdésekről egy egyszerű Q & Egy bejegyzés.

Teljes könyv készült az ok-okozati elemzésről és a minőségi problémákkal küzdő szervezet javítási folyamatáról.

Tehát az én ajánlásom a következő: (nincs külön sorrendben)

• Hajtson végre hibakövető rendszert, ha még nem találta meg
• Határozza meg a hibák súlyosságának osztályozási módját
• Tudja meg, miért nem felel meg az ügyfelek elvárásainak (a fejlesztők, a minőségbiztosítás, az ügyfél stb.)
• Ismerjen meg néhány gyakorlatot, például az “öt miért” -t, és végezzen hasonló vizsgálatokat a hibáinak egyes okaiba.

Attól függ, hogy Ön mit hív alkalmazásnak.

Ha olyan interaktív programra gondol, ahol biztosnak kell lennie abban, hogy a valós idejű viselkedés minden körülmények között pontosan ilyen és ilyen, akkor alapvetően lehetetlen bizonyítani, hogy nincsenek hibák benne. Feltételezem, hogy lehetséges lenne, ha meg tudná oldani a leállítási problémát , de ezt megteheti.

Ha azonban a egy “ilyen és ilyen bemenet végül ilyen és ilyen végállapotot eredményez” állítás, akkor nagyobb az esélyed a “hibamentes bizonyításra”, mert használhatsz invariantusokat . Ez és csak ez lehetővé teszi a helyességbizonyítás felosztását részproblémákban, amelyek mindegyike viszonylag könnyen kipróbálható, hogy megfelelően működjenek minden körülmények között a maradék programból (bár általában nem lehet nagyon pontos abban, hogy mennyi idő & memória lehet).

Ezek a technikák alapvetően bármelyikben lehetségesek programozási nyelv (bár egyes ezoterikus nyelvek, például a Malbolge megpróbálják cáfolni ezt !), de minden elengedhetetlen nyelven nagyon gyorsan elrontódik, mert aprólékosan nyomon kell követnie sok mindent implicit programállapot. A funkcionális nyelvekben ¹ a bizonyítékok általában sokkal szebben néznek ki ( tiszta nyelvek , vagy egy nyelv tisztán funkcionális részhalmaza). Mégis, különösen a dinamikus típusok esetében, sok követelményt kell megírnia arról, hogy milyen bemenetek megengedettek. Ez természetesen az erős statikus típusú rendszerek egyik fő előnye: a követelmények ott vannak a kódban!
Nos, ideális esetben ez van. A gyakorlatban az O “Caml vagy akár a Haskell programok általában tartalmaznak nontotal függvények , azaz olyan funkciók, amelyek egyes bemeneteknél összeomlanak / lefagynak / dobnak, a megfelelő ² típus ellenére. Mivel bár ezeknek a nyelveknek nagyon rugalmas típusú rendszereik vannak, néha még mindig nem lehet használni őket teljes korlátozásra.

Adja meg a függően beírt nyelveket ! Ezek szükség szerint pontosan kiszámíthatják a típusokat, így minden, amit megadhat, pontosan olyan típusú aláírással rendelkezhet, amely elősegíti az összes szükséges elemet. És a függően beírt nyelveket többnyire biztos környezetekként tanítják . Sajnos úgy gondolom, hogy egyikük sem áll igazán a gyártási szoftverek megírásában. A gyakorlati alkalmazásokhoz azt gondolom, hogy a teljesen hibabiztos hoz legközelebb a Haskellben történő írás lehet olyan alapos funkciókkal, mint lehetséges. Ez elég hez vezet a hibabiztos – közelében, bár ezúttal is csak a funkcionális leírás tekintetében. Az IO monádokkal történő kezelésének egyedülálló módja szintén nagyon hasznos bizonyítékokat ad, de általában nem mond el semmit arról, hogy meddig tart valami Befejez. Valószínűleg valami exponenciális időt vehet igénybe bizonyos körülmények között – a felhasználó POV-jától, ez valószínűleg olyan súlyos hiba lenne, mintha a program teljesen lefagyna.

¹ _{Vagy általánosabban: leíró nyelvek. Nincs sok tapasztalatom a logikai nyelvekkel kapcsolatban, de feltételezem, hogy bizonyításukban hasonlóan szépek lehetnek üdvözlettel.}

² _{Ha nem a megfelelő típus, a fordító soha nem engedélyezi ezeket a nyelveket; ez már sok hibát kiküszöböl. (És a Hindley-Milner típusú következtetésnek köszönhetően ez a programokat is tömörebbé teszi!)}

Hozzászólások

• " Ha olyan interaktív programra gondolsz, ahol biztosnak kell lenned abban, hogy a valós idejű viselkedés minden körülmények között pontosan ilyen és ilyen, akkor ' alapvetően lehetetlen bizonyítani, hogy nincs ' hiba benne. Feltételezem, hogy lehetséges lenne, ha megoldaná a leállítási problémát, de ' t. ": Nem tudom, hogy ez állítás helyes. Lehetetlen ellenőrizni egy tetszőleges programot, de mi a helyzet egy olyan programmal, amelyet úgy írt, hogy lehetővé teszi az ilyen ellenőrzést?
• Lásd pl. cs.cmu.edu/~rwh/smlbook/book.pdf , a 198. oldal elején: " Végül fontos megjegyezni, hogy a specifikáció, a megvalósítás és az ellenőrzés kéz a kézben jár. Irreális azt javasolni, hogy ellenőrizzük, hogy egy tetszőleges kódrész megfelel-e egy tetszőleges specifikációnak. Az alapvető számíthatósági és bonyolultsági eredmények egyértelművé teszik, hogy ilyen törekvésben soha nem lehet sikeres. Szerencsére ez is teljesen mesterséges. A gyakorlatban egyszerre adunk meg, kódolunk és ellenőrizünk, minden tevékenység tájékoztatva a másikat."
• @Giorgio: Bizonyos programokat úgy is írhatsz, hogy az lehetővé tegye az ilyen ellenőrzést , de ez valóban korlátoz téged nagyon. Egy nagy programban ' szinte mindig ki kell használnia Turing teljességét valahol. – Igen, a gyakorlatban megadja, kódolja és " egyszerre ellenőrzi az " elemeket, de az ellenőrzés gyakran elég heurisztikus (pl. Egységtesztek alapján) , nem valós bizonyítékok).
• Mit értesz " alatt Turing teljességének kihasználásával "?
• " … de ez az ellenőrzés gyakran elég heurisztikus (pl. egységtesztek, nem valós bizonyítékok alapján) ": Nem , ha figyelmesen elolvassa a jegyzeteket, az a formális módszerek segítségével történő igazolásról szól (pl. indukcióval), nem egységtesztekről szól. Lásd még: compcert.inria.fr/doc .