Vastaa
Lähinnä virhevapaata sovellusta, kalliimmaksi se tulee. Se haluaa kohdistaa 100-prosenttisesti koodikattavuuteen: vietät saman määrän aikaa ja rahaa 0-95 prosentilla, 95-99 prosentilla ja 99-99,9 prosentilla.
Tarvitsetko tämän ylimääräisen 0,1% koodin kattavuudesta tai laadusta? Luultavasti kyllä, jos työskentelet ohjelmistotuotteen parissa, joka ohjaa ydinreaktorin jäähdytysjärjestelmää. Luultavasti ei, jos työskentelet liikesovelluksen parissa.
Laadukkaiden ohjelmistojen tekeminen vaatii myös hyvin erilainen lähestymistapa . Et voi vain pyytää kehittäjiä, jotka viettivät elämänsä kirjoittamalla yrityssovelluksia, luomaan lähes virheettömän sovelluksen. Laadukas ohjelmisto vaatii erilaisia tekniikoita, kuten muodollinen todistus , jotain, jota et varmasti halua käyttää yrityssovelluksessa sen edustamien erittäin korkeiden kustannusten takia.
Kuten selitin omat artikkelini :
-
Yritysohjelmien ei tulisi kohdistaa elämän kriittisten ohjelmistojen vaatimaa laatua, koska jos nämä yrityssovellukset epäonnistuvat ajoittain, ne vain eivät ” Olen nähnyt vikoja ja seisokkeja luultavasti jokaisen suuryrityksen verkkosivustolla, ainoa poikkeus on Amazon. Tämä seisokki ja nämä virheet ovat ärsyttäviä ja saattavat maksaa yritykselle muutamia tuhansia dollareita kuukaudessa, mutta korjaaminen olisi paljon kalliimpaa.
-
Kustannusten tulisi olla ensisijainen painopiste, ja sitä tulisi tutkia käytännöllisesti. Kuvitelkaamme virhettä, joka vaikuttaa 5 000 asiakkaaseen ja on niin tärkeä, että asiakkaat lähtevät ikuisesti. Onko tämä tärkeää? Kyllä? Ajattele lisää. Entä jos sanon, että jokainen näistä asiakkaista maksaa 10 dollaria vuodessa ja että se maksaa maksaa melkein 100 000 dollaria virheen korjaamiseksi? Virheenkorjaus näyttää nyt paljon vähemmän mielenkiintoiselta.
Vastaa nyt kysymyksiisi erityisesti:
miksi virheistä ilmoitetaan edes niin suuren testin jälkeen? Onko se vaatimuksemme ongelma? Asiakkaamme ei tunnu onnelliselta mistä tahansa tarjoamastamme? teemmekö jotain väärin?
Monet asiat voivat mennä pieleen. Tarkoitatko testauksella todellista automaattista testausta? Jos ei, tämä on itsessään valtava ongelma. Ymmärtävätkö testaajat vaatimuksia? Kommunikoitko asiakkaan kanssa säännöllisesti – ainakin kerran iteraatiota kohden, parhaimmalla mahdollisella tavalla asiakkaan edustaja on heti paikan päällä kaikkien tiimisi jäsenten käytettävissä ? Ovatko toistosi tarpeeksi lyhyitä? Testasivatko kehittäjät omaa koodiaan?
Samoin kuin he kirjoittavat yllä linkitetyt artikkelit oikein, ottaa virheraportin ja tutki miksi tämä vika ilmestyi aluksi ja miksi kukin testaaja jäi siitä väliin . Tämä voi antaa sinulle ideoita tiimisi prosessin aukoista.
Tärkeä huomioitava asia: maksatko asiakkaasi virhekorjauksista? Jos ei, häntä voidaan rohkaista harkitsemaan monia asioita ole vika. Kun hänet maksetaan virheille käyttämästäsi ajasta, vikailmoitusten määrä vähenee huomattavasti.
Onko kukaan kehittänyt mitään sovelluksia, jotka olivat täysin virheetön? Mikä on prosessi? Miksi emme voi käyttää sovellusta pienillä virheillä? Pitäisikö meidän olla perfektionisteja?
Minä. Olen kirjoittanut sovelluksen itselleni viime viikonloppuna, enkä ole vielä löytänyt mitään virhettä.
Virheet ovat vain virheitä, kun niistä ilmoitetaan. Joten teoriassa virheettömän sovelluksen saaminen on täysin mahdollista: jos kukaan ei käytä sitä, kukaan ei ilmoita virheistä.
Kun kirjoitat nyt laajamittaisen sovelluksen, joka sopii täydellisesti määrittely ja on osoittautunut oikeaksi (katso edellä mainittu muodollinen todiste) on erilainen tarina. Jos tämä on elämän kannalta kriittinen projekti, tämän pitäisi olla tavoitteesi (mikä ei tarkoita hakemustasi tulee olemaan virhetön).
Onko nykyinen skenaario oikea kehitys- ja testausprosessi? Jos ei, mikä on tehokas tapa, jolla kehittäjät, testaajat ja asiakas saavat maksimaalisen hyödyn yhdessä?
-
Ymmärtääkseen toisiaan , heidän tulisi kommunikoida. Tätä ei tapahdu useimmissa yrityksissä, joita olen nähnyt. Useimmissa yrityksissä projektipäällikkö on ainoa, joka puhuu asiakkaalle (joskus edustajalle).Sitten hän kertoo (joskus osittain) ymmärryksestään vaatimuksista kehittäjien, vuorovaikutussuunnittelijoiden, arkkitehtien, DBA: n ja testaajien kanssa.
Siksi asiakkaan (tai asiakkaan edustajan) on välttämätöntä olla kaikkien joukkueen jäsenten ulottuvilla (ketterä lähestymistapa) tai käyttää virallisia viestintävälineitä, jotka valtuuttavat henkilön kommunikoimaan vain muutamien muiden ryhmässä olevien henkilöiden kanssa ja tekemään sen tavalla, että tiedot voidaan jakaa koko tiimille, varmistaa, että kaikilla on samat tiedot.
-
Kehittämistä ja testaamista on monia prosesseja. Tietämättä tarkasti yritystä ja tiimiä, ei ole mitään keinoa määrittää, kumman pitäisi Harkitse konsultin palkkaamista tai tarpeeksi taitavan projektipäällikön palkkaamista.
Kommentit
- +1. Ennen kuin aloitat edes projektin, sinun on ymmärrettävä, mikä on " tarpeeksi hyvä julkaisua varten " ja rakenna vastaavasti.
- @JuliaHayward ei voinut ' sopia enemmän. Loppupeli ei ole ' nolla virheitä – se tuottaa toiminnallisia ohjelmistoja, jotka lisäävät arvoa oikeaan aikaan.
Vastaa
Kaikkia vikoja ei ole luotu yhtä suuriksi, joten sinun on lajiteltava vehnä akanoista.
Odotukset
Monet virheet tuodaan esiin yksinkertaisesti ohjelmiston puutteen ja loppukäyttäjän odottaman puutteen vuoksi. Tämä odotus tulee monilta aloilta: muiden ohjelmistojen käytöstä, virheellisestä dokumentaatiosta, liian innokkaasta myyntihenkilöstöstä, ohjelmiston käytöstä jne.
Laajuus hiipii
On sanomattakin selvää, että mitä enemmän toimitat, sitä suurempi on virheiden mahdollisuus. Monet virheet ovat yksinkertaisesti esillä uusien ominaisuuksien takana. Toimitat X & Y, mutta asiakas sanoo, että tämän takana sen pitäisi nyt tehdä myös Z.
Ymmärrä ongelma-alue
Monet virheet johtuvat siitä yksinkertaisesta syystä, että ongelma-alue ymmärrettiin huonosti. Jokaisella asiakkaalla on omat liiketoimintasäännöt, ammattikieltä ja tapoja tehdä asioita. Suurta osaa tästä ei dokumentoida missään – se on vain ihmisten päissä. Maailman parhaalla tahdolla et voi toivoa, että otat kaiken tämän yhdellä kertaa.
Joten … mitä tehdä asialle.
Automaattiset yksikötestit
Monet virheet otetaan käyttöön odottamattomana sivuvaikutuksena koodin muutoksesta tai muusta. Jos Jos sinulla on automatisoituja yksikötestejä, voit sulkea monet näistä ongelmista ja tuottaa paremman koodin alusta alkaen.
Testit ovat vain yhtä hyviä kuin toimitetut tiedot – joten varmista, että ymmärrät ongelman täysin.
Koodin kattavuus
Tämä kulkee käsi kädessä automaattisen yksikötestauksen kanssa. varmista, että testataan niin paljon koodia kuin on käytännöllistä.
Opi oppitunteja
Hulluus tekee samaa ja uudestaan ja uudestaan ja uudestaan ja odottaa erilaisia tuloksia
Ymmärrätkö viimeisen epäonnistumisen syyt? Oletko? Todellakin? Olet ehkä lopettanut ongelma mutta mikä oli todellinen juurilähde? Huonot tiedot? Käyttäjän virhe? Levyn vioittuminen? Verkkokatkos?
Mikään ei ärsytä asiakkaita enemmän kuin kohdata samat ongelmat uudestaan ja uudestaan ilman edistymistä kohti jonkinlaista ratkaisua.
Vastaa
Vikoja on ollut olemassa ohjelmistokehityksen alusta lähtien. Kysymyksestäsi on vaikea kertoa, missä määrin ja missä vakavuudessa viat vaikuttavat käytettävyyteen tai toiminnallisuuteen.
Virheettömiä ohjelmia on olemassa, mutta melkein missä tahansa muussa kuin triviaalissa järjestelmässä on vikoja.
Sinun on päätettävä jonkinlaisesta priorisoinnista ja todennäköisesti joudut tekemään jonkin verran tutkimusta vikojen syystä – missä ne esitettiin. Tällaisista asioista on aivan liian paljon keskustella yksinkertaisella Q: lla & Viesti.
Kokonaisia kirjoja syy-analyysistä ja korjausprosessista organisaatiolle, jolla on laatuongelmia.
Joten suosittelen on: (ei erityisessä järjestyksessä)
- Ota käyttöön vianseurantajärjestelmä, jos et ole vielä löytänyt sitä.
- Määritä tapa luokitella vikojen vakavuus
- Selvitä, miksi et vastaa asiakkaiden odotuksiin (ovatko kehittäjät, laadunvalvonta, asiakas jne.)
- Tutustu joihinkin harjoituksiin, kuten ”viisi miksi”, ja tee vastaavia tutkimuksia osaksi vikojen syitä.
Vastaus
Riippuu siitä, mitä kutsut sovellukseksi.
Jos tarkoitat vuorovaikutteista ohjelmaa, jossa sinun on oltava varma siitä, että reaaliaikainen käyttäytyminen on täsmälleen sellaista ja sellaista missään olosuhteissa, niin siellä on periaatteessa mahdotonta todistaa, ettei siinä ole vikoja sen sisällä. Oletan, että se olisi mahdollista, jos voisit ratkaista pysäytysongelman , mutta et voi.
Jos kuitenkin rajoitat itsesi lausunto ”sellainen ja sellainen panos tuottaa lopulta sellaisen ja sellaisen lopullisen tilan”, niin mahdollisuutesi ”virheetöntä todistusta” ovat paremmat, koska voit käyttää invarianteja . Tämä ja vain tämä sallii virheellisyystodistuksen jakamisen aliongelmiin, joista kukin voidaan suhteellisen helposti kokeilla toimimaan oikein kaikissa olosuhteissa jäljellä olevasta ohjelmasta (vaikka et yleensä voi olla kovin tarkka siitä, kuinka paljon aikaa & muisti voi viedä).
Tällaiset tekniikat ovat periaatteessa mahdollisia missä tahansa ohjelmointikieli (vaikka jotkut esoteeriset kielet, kuten Malbolge , yrittävät torjua sen !), mutta kaikilla välttämättömillä kielillä se sotkeutuu hyvin nopeasti, koska sinun on tarkkailtava tarkkaan paljon implisiittinen ohjelman tila. Toiminnallisilla kielillä 1 todisteet näyttävät yleensä paljon mukavammilta ( puhtaat kielet tai kielen puhtaasti toimiva osajoukko). Silti, erityisesti dynaamisten tyyppien kanssa, sinun on kirjoitettava paljon vaatimuksia siitä, mitkä syötteet ovat sallittuja. Se on tietysti yksi vahvojen staattisten tyyppisten järjestelmien tärkeimmistä eduista: vaatimukset ovat oikeassa siinä koodissa!
No, ihannetapauksessa se on. Käytännössä O ”Caml- tai jopa Haskell-ohjelmat sisältävät yleensä ei-funktiot eli toiminnot, jotka kaatuvat / jumittuvat / heittävät tietyille tuloille huolimatta oikeasta tyypistä 2 . Koska näillä kielillä on hyvin joustavat tyyppijärjestelmät, ei ole joskus silti mahdotonta käyttää sitä rajoittaa jotain täysin.
Kirjoita riippuvaisesti kirjoitetut kielet ! Nämä voivat ”laskea” tyyppejä tarkalleen tarpeen mukaan, joten kaikella määrittelemälläsi voi olla juuri tarvittava allekirjoitus, joka todistaa kaiken tarvitsemasi. Ja riippuvasti kirjoitettuja kieliä opetetaan enimmäkseen todistettavina ympäristöinä . Valitettavasti mielestäni yksikään niistä ei todellakaan kirjoita tuotanto-ohjelmistoja. Käytännöllisissä sovelluksissa mielestäni lähin täysin virhesuojattu on Haskellissa kirjoittaminen yhtä perusteellisilla toiminnoilla kuin Se vie sinut melko lähelle virhesuojattua –, vaikkakin taas vain toiminnallisen kuvauksen suhteen. Haskell Ainutlaatuinen tapa käsitellä IO: ta monadien kanssa antaa myös erittäin hyödyllisiä todisteita, mutta se ei yleensä kerro sinulle mitään siitä, kuinka kauan jotain kestää suorittaa loppuun. Mahdollisesti jokin saattaa viedä eksponentiaalista aikaa tietyissä olosuhteissa – käyttäjän POV: lta, mikä olisi todennäköisesti yhtä vakava virhe kuin jos ohjelma jumittuu kokonaan.
1 Tai yleisemmin kuvaavat kielet. Minulla ei ole paljon kokemusta loogisista kielistä, mutta luulen, että ne voivat olla yhtä hyviä todisteina terveisin.
2 Jos se ei ole oikea tyyppi, kääntäjä ei koskaan salli sitä näillä kielillä; se poistaa jo paljon vikoja. (Ja Hindley-Milner-tyyppisen päätelmän ansiosta se tekee ohjelmista myös ytimekkäämpiä!)
Kommentit
- " Jos tarkoitat vuorovaikutteista ohjelmaa, jossa sinun on oltava varma siitä, että reaaliaikainen käyttäytyminen on täsmälleen sellaista missään olosuhteissa, niin se ' ei periaatteessa voida todistaa, ettei ' ole virheitä sen sisällä. Oletan, että se olisi mahdollista, jos pystyt ratkaisemaan pysäytysongelman, mutta voit ' t. ": En ole varma, onko tämä lause on oikea. Mielivaltaisen ohjelman tarkistaminen on mahdotonta, mutta entä ohjelma, jonka olet kirjoittanut tavalla, joka sallii tällaisen vahvistuksen?
- Katso esim. cs.cmu.edu/~rwh/smlbook/book.pdf , sivun 198 alussa: " Lopuksi on tärkeää huomata, että määrittely, toteutus ja todentaminen kulkevat käsi kädessä. On epärealistista ehdottaa tarkistusta siitä, että mielivaltainen koodinpätkä täyttää mielivaltaisen eritelmän. Peruslaskettavuuden ja monimutkaisuuden tulokset tekevät selväksi, ettemme voi koskaan menestyä tällaisessa pyrkimyksessä. Onneksi se on myös täysin keinotekoinen. Käytännössä määritämme, koodaamme ja tarkistamme samanaikaisesti, jolloin kukin toiminto ilmoittaa toisille."
- @Giorgio: varmasti voit kirjoittaa joitain ohjelmia tavalla, joka sallii tällaisen vahvistuksen , mutta se todella rajoittaa sinua melko paljon. Suuressa ohjelmassa sinun täytyy ' melkein aina hyödyntää Turingin täydellisyyttä jossain. – Kyllä, käytännössä määrität, koodaat ja " varmistat " samanaikaisesti, mutta todentaminen on usein riittävän heuristista (perustuu esimerkiksi yksikkötesteihin) , ei todellisia todisteita).
- Mitä tarkoitat " hyödyntämällä Turingin täydellisyyttä "?
- " … mutta todentaminen on usein riittävän heuristista (perustuu esimerkiksi yksikkötesteihin, ei todellisiin todisteisiin) ": Ei , jos luet huomautukset huolellisesti, se puhuu oikeellisuuden osoittamisesta muodollisilla menetelmillä (esim. induktio), se ei puhu yksikkötesteistä. Katso myös compcert.inria.fr/doc .