Kuinka koodin virheenkorjaus on tehokkainta? [suljettu]

Ajattelutapa ja virheenkorjausasenne ovat ehkä tärkein osa, koska se määrittää kuinka tehokkaasti korjaat virheen ja mitä opit siitä – jos mitään.

Ohjelmistokehityksen klassikot, kuten Pragmatic Programmer ja Code Complete , puolustavat periaatteessa samaa lähestymistapaa: jokainen virhe on mahdollisuus oppia, melkein aina itsestäsi (koska vain aloittelijat syyttävät ensin kääntäjää / tietokonetta).

Joten käsittele sitä mysteerinä, joka on mielenkiintoinen murtaa. Ja salaperäisyyden murtaminen olisi tehtävä järjestelmällisesti ilmaisemalla oletuksemme (itsellemme tai muille) ja testaamalla sitten oletuksemme yksitellen tarvittaessa – käyttämällä kaikkia käytettävissä olevia työkaluja, erityisesti virheenkorjaajia ja automaattisia testikehyksiä. Sitten, kun mysteeri on ratkaistu, voit tehdä vieläkin paremmin tarkastelemalla kaikkia koodejasi mahdollisesti tekemiesi vastaavien virheiden varalta; ja kirjoita automaattinen testi varmistaaksesi, että virhe ei toistu tietämättään.

Viimeinen huomautus – mieluummin kutsun virheitä ”virheiksi” eikä ”virheiksi” – Dijkstra kehotti kollegoitaan käyttämään jälkimmäistä termiä, koska se on epärehellistä ja tukee ajatusta siitä, että vahingolliset ja epävakaat bug-keijut istuttivat vikoja ohjelmiin, kun emme katsoneet, sen sijaan, että olisimme siellä oman (huolimattoman) ajattelumme takia: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html

Voisimme esimerkiksi aloittaa kielemme siivoamisesta ei enää kutsua virhettä virheenä, vaan kutsumalla sitä virheeksi. Se on paljon rehellisempi, koska se laittaa syyn suoraan siihen, mihin se kuuluu, nimittäin. ohjelmoijan kanssa, joka teki virheen. Animistinen metafora virheestä, joka hiipeli vahingollisesti, kun ohjelmoija ei katsonut, on älyllisesti epärehellistä, koska se peittää, että virhe on ohjelmoijan oma luomus. Tämän yksinkertaisen sanastomuutoksen mukava asia on, että sillä on niin syvällinen vaikutus : Vaikka aiemmin vain yhden virheen sisältävä ohjelma oli ”melkein oikea”, sen jälkeen virheohjelmalla varustettu ohjelma on vain ”väärä” (virheellisesti).

kommentit

• Pidän itse asiassa termistä " error " pikemminkin kuin " bug ", ei siksi, että siitä syytetään " ohjelmoijaa kuka teki virheen ", mutta koska se tekee selväksi, että se ei ehkä ole ollut ohjelmoijan vika. Minulle " bug " merkitsee virhettä koodissa; kun taas " erro r " merkitsee virhettä jossain . Ehkä koodissa, ehkä ympäristön asetuksissa, ehkä vaatimuksissa. Ajaa minua, kun pomolleni on " -virhelista ", jossa puolet ongelmista on vaatimusten muutoksia. Kutsukaa sitä tehtäväluetteloksi, ferchrissakes!
• +1 " -kentälle jokainen virhe on mahdollisuus oppia, melkein aina itsestäsi (koska vain aloittelijat syyttävät kääntäjää / tietokone ensin) "
• Olet tietoinen termin " virheestä ", eikö? Tarkoitan, sellaisena kuin sitä käytetään ohjelmistokehityksessä. Tietysti meillä ei ole ' tätä ongelmaa tänään, mutta vika todellakin lensi tietokoneen laitteistoon, jota ohjelmoija ei huomannut, ja aiheutti ongelman.Jotta joku ajattelisi korjata minua, tiedän, että Edison käytti tätä termiä kauan ennen koi-tapahtumaa, minkä vuoksi käytin sanaa ' history ', ei ' alkuperä '. Katso computerworld.com/article/2515435/app-development/… ja fi.wikipedia.org/wiki/Software_bug#Etymology
• @threed Tietysti. Hyönteiset eivät ole kuitenkaan pitkään aikaan aiheuttaneet suurinta osaa ohjelmistovirheistä.

1. Kirjoita testit. Testaus on paitsi erinomaista virheiden ehkäisemisessä (kokemukseni mukaan TDD oikein tehty eliminoi melkein kaikki triviaalit, tyhmät virheet), mutta myös auttaa paljon virheenkorjauksessa. Testaus pakottaa suunnittelun olevan melko modulaarinen, mikä helpottaa ongelman eristämistä ja toistamista. Lisäksi hallitset ympäristöä, joten yllätyksiä tulee olemaan paljon vähemmän. Lisäksi, kun saat epäonnistuneen testitapauksen, voit olla kohtuullisen varma, että olet naulannut sinut häiritsevän käyttäytymisen todellisen syyn.

2. Opi käyttämään virheenkorjainta. print -lausekkeet voivat toimia kohtuullisen hyvin jollain tasolla, mutta virheenkorjaus on suurimmaksi osaksi erittäin hyödyllistä (ja kerran osaat käyttää sitä, se on paljon mukavampaa kuin print -lausunnot).

3. Keskustele jonkun kanssa ongelmastasi, vaikka se olisi vain kumiankka . Jos pakotat itsesi ilmaisemaan ongelmaa, jolla työskentelet, tehdään todella ihmeitä.

4. Anna itsellesi määräaika. Jos esimerkiksi 45 minuutin kuluttua sinusta tuntuu, että et ole menossa mihinkään, vaihda vain muihin tehtäviin jonkin aikaa. Kun palaat virheen luo, toivottavasti pystyt näkemään muita mahdollisia ratkaisuja, joita et olisi aiemmin harkinnut.

Kommentit

• +1 ryhmälle " Jos pakotat itsesi ilmaisemaan käsittelemäsi ongelman sanoin, tapahtuu todella ihmeitä. "
• Ja jos haluat lisätä kohtaan (1), melkein jokainen koodissa näkyvä vika tarkoittaa, että siellä ' on virhe – tai ainakin puute – testipaketissa. Korjaa molemmat samanaikaisesti, eikä vain todista, että olet ' korjannut käsillä olevan ongelman, olet ' turvassa sen estämiseltä palautettu.

Pidän useimmista muista vastauksista, mutta tässä on joitain vinkkejä mitä tehdä ENNEN mitä teet mitään. Säästää aikaa Beaucoupilla.

1. Selvitä onko virhettä. Virhe on AINA ero järjestelmän käyttäytymisen ja vaatimusten välillä; testaajan pitäisi pystyä ilmaisemaan odotettu ja todellinen käyttäytyminen. Jos hän ei pysty tarjoamaan tukea odotetulle käytökselle, sitä ei vaadita eikä virhettä ole – vain jonkun mielipide. Lähetä se takaisin.

2. Harkitse mahdollisuutta että odotettu käyttäytyminen on väärin. Tämä voi johtua vaatimuksen väärästä tulkinnasta. Se voi johtua myös itse vaatimuksen puutteesta (delta yksityiskohtaisen vaatimuksen ja yritysvaatimuksen välillä). Voit myös lähettää nämä takaisin.

3. Eristä ongelma. Vain kokemus opettaa sinulle nopeimman tavan tehdä tämä – jotkut ihmiset voivat melkein tehdä sen suoliston kanssa. Yksi perusmenetelmä on vaihtaa yhtä asiaa pitämällä kaikki muut asiat vakiona (esiintyykö ongelma muissa ympäristöissä? muiden selainten kanssa? eri testialueella? eri päivinä?) Toinen lähestymistapa on tarkastella pinon kaatopaikkoja tai virheilmoituksia – joskus voit kertoa vain tapa, jolla se alustetaan, mikä järjestelmän osa heitti alkuperäisen virheen (esim. jos se on saksaksi, voit se kolmas osapuoli, jonka kanssa työskentelet Berliinissä).

4. Jos olet kaventanut sen kahteen järjestelmään, jotka tekevät yhteistyötä, tarkista näiden kahden järjestelmän väliset viestit liikennevalvontalaitteella tai lokitiedostoilla ja määritä mikä järjestelmä käyttäytyy spesifikaation mukaan ja mikä ei. Jos skenaariossa on enemmän kuin kaksi järjestelmää, voit suorittaa paritarkastukset ja työskennellä sovelluspinon ”alas”.

5. Syy ongelman eristämiseen on niin kriittinen Ongelma ei välttämättä johdu koodivirheestä, jota hallitset (esim. kolmansien osapuolten järjestelmät tai ympäristö), ja haluat saada osapuolen ottamaan haltuunsa mahdollisimman nopeasti. Tämä on sekä säästää työtäsi että saada ne heti paikalleen, jotta resoluutio voidaan saavuttaa mahdollisimman lyhyessä ajassa. Et halua työskennellä kymmenen päivän ajan vain löytääksesi ongelman jonkun toisen verkkopalvelussa.

6. Jos olet todennut, että vika on todella olemassa ja se todella on hallitsemassasi koodissa, voit eristää ongelman etsimällä viimeistä ”tunnettua hyvää” koontiversiota ja tarkistamme lähteen hallintalokien muutokset, jotka ovat saattaneet aiheuttaa ongelman. Tämä voi säästää paljon aikaa.

7. Jos et pysty selvittämään sitä lähteen hallinnasta, nyt on aika liittää virheenkorjain ja käydä läpi koodi sen selvittämiseksi. Todennäköisesti sinulla on jo nyt melko hyvä käsitys ongelmasta.

Kun tiedät virheen ja pystyt keksimään korjauksen, tässä on hyvä korjausmenettely:

1. Kirjoita yksikötesti, joka toistaa ongelman ja epäonnistuu.

2. Tee yksikkötestiä muuttamatta se läpäisee (muokkaamalla sovelluskoodia).

3. Pidä yksikötesti testipaketissasi regressioiden estämiseksi / havaitsemiseksi.

Mielestäni virheen toistaminen on myös tärkeää. Kaikki virheen toistavat tapaukset voidaan luetella, ja voit sitten varmistaa, että virhekorjauksesi kattaa kaikki kyseiset tapaukset.

Tästä aiheesta on lukemani erinomainen kirja nimeltä Miksi ohjelmat epäonnistuvat , jossa hahmotellaan erilaisia vikojen löytämisstrategioita aina tieteellisen menetelmän soveltamisesta virhe, delta-virheenkorjaukseen. Tämän kirjan toinen mielenkiintoinen osa on, että siinä poistetaan termi ”vika”. Zellerin lähestymistapa on:

(1) Ohjelmoija luo vian koodiin. (2) Vika aiheuttaa infektion (3) Infektio leviää (4) Infektio aiheuttaa epäonnistumisen.

Jos haluat parantaa virheenkorjaustaitoja, suosittelen tätä kirjaa.

Omassa henkilökohtaisessa kokemuksessani olen löytänyt sovelluksestamme paljon vikoja, mutta hallinta yksinkertaisesti painaa meitä eteenpäin saada uusia ominaisuuksia ulos. Olen ”usein kuullut”. Löysimme tämän virheen itse ja asiakas ei ole vielä huomannut sitä, joten jätä se, kunnes he huomaavat ”. Mielestäni reaktiivisuus ja ennakoivuus vikojen korjaamisessa on erittäin huono idea, koska kun on aika todella korjata, sinulla on muita ratkaistavia asioita ja lisää ominaisuuksien hallintaa haluaa ASAP-ovelta, joten saat kiinni noidankehässä, joka voi aiheuttaa paljon stressiä ja palamista ja viime kädessä vikoja.

Viestintä on myös toinen tekijä vikoja löydettäessä. Sähköpostin lähettäminen tai dokumentoiminen vikaseuranta on kaikki kunnossa, mutta omien kokemusteni mukaan muut kehittäjät löytävät samanlaisen virheen ja käyttävät pikemminkin koodin korjaamiseen käyttämääsi ratkaisua (koska he ovat unohtaneet kaiken), mutta lisäävät omat versiot, joten koodissasi on viisi erilaista ratkaisua ja se näyttää sen seurauksena paisuneemmalta ja hämmentävämmältä. Joten kun korjaat virheen, varmista, että muutamat ihmiset tarkistavat korjauksen ja antavat sinulle palautetta, jos he ovat korjaaneet jotain vastaavaa ja löysi hyvän strategian sen hoitamiseksi.

limist mainitsi kirjan,