Zárt . Ennek a kérdésnek jobban kell összpontosítania . Jelenleg nem fogadja el a válaszokat.

Megjegyzések

  • A kapcsolt kérdést eltávolítottuk.
  • Úgy gondolom, hogy a megközelítés valóban egyszerű. Ha egyedül fejlesztette ki, mindent tud róla. A hibát hibakeresés nélkül is kijavíthatja. Ezt szem előtt tartva a legjobb módszer az idő kódolása valamivel mással, amíg valaki, aki sokat tud róla, válaszolhat a javítás kérdésére; vagy hagyd pihenni, kódolj más dolgokat, amíg eszedbe nem jut egy ötlet a javításhoz, így nem vesztesz időt és energiát sem. Azt hiszem, a kérdése a vállalati csapatmenedzsmentről szól.
  • Szerintem a Raid. Polcon kívüli, hibajavító spray. Filozófiai kérdés ez? A könyvek puszta túlsúlyból készülnek.

Válasz

A gondolkodásmód és a hibakereséshez való hozzáállás talán a A legfontosabb rész, mert ez határozza meg, hogy mennyire hatékonyan javítja ki a hibát, és mit tanul meg belőle – ha bármi.

A szoftverfejlesztés olyan klasszikusai, mint a The Pragmatic Programmer és a Code Complete , alapvetően ugyanazon megközelítés mellett érvelnek: minden hiba alkalom a tanulásra, szinte mindig önmagáról (mert csak a kezdők okolják először a fordítót / számítógépet).

Szóval rejtélyként kezelje, amelyet érdekes lesz feltörni. Ennek a rejtélynek a feltörését szisztematikusan kell elvégezni, kifejezve feltételezéseinket (önmagunknak vagy másoknak), majd feltételezéseinket szükség szerint egyenként tesztelve – minden rendelkezésünkre álló eszközt felhasználva, különösen a hibakeresőket és az automatizált tesztkereteket. Aztán miután a rejtély megoldódott, még jobbat tehet, ha átnézi az összes kódját az esetlegesen elkövetett hasonló hibákra; és írjon egy automatizált tesztet annak biztosítására, hogy a hiba ne forduljon elő öntudatlanul.

Egy utolsó megjegyzés – a hibákat inkább “hibának” és nem “hibának” nevezem – Dijkstra felszólította kollégáit, hogy használják az utóbbi kifejezést, mert becstelen, támogatva azt az elképzelést, hogy a kártékony és ingatag bug-tündérek hibákat telepítettek programjainkba, miközben mi nem néztünk, ahelyett, hogy a saját (hanyag) gondolkodásunk miatt lennénk ott: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html

Például azzal kezdhetnénk, hogy megtisztítjuk a nyelvünket: már nem hibának nevezzük hibát, hanem hibának. Sokkal őszintébb, mert egyenesen oda teszi a hibát, ahova tartozik, ti. a hibát elkövető programozóval. Annak a hibának az animistás metaforája, amely rosszindulatúan besurrant, miközben a programozó nem nézett, intellektuálisan tisztességtelen, mivel azt leplezi le, hogy a hiba a programozó saját alkotása. A szókincs ezen egyszerű megváltoztatásának az a szép, hogy olyan mély hatása van : míg korábban csak egy hibát tartalmazó program “majdnem helyes” volt, utána egy hibás program csak “hibás” (mert tévesen).

Megjegyzések

  • Valójában szeretem a " error kifejezést " helyett " bug ", nem azért, mert a hibát " a programozóra rója ki hibázott ", de mivel világossá teszi, hogy nem lehet, hogy a programozó hibás. Számomra " bug " hibát jelent a kódban; míg a " erro r " hibát jelent valahol . Talán a kódban, talán a környezet beállításában, esetleg a követelményekben. Meghajt, ha a főnököm " hibalista " hibakóddal rendelkezik, ahol a problémák fele követelményváltozás. Nevezzük feladatlistának, ferchrissakes!
  • +1 a " számára minden hiba alkalmat kínál a tanulásra, szinte mindig önmagáról (mert csak a kezdők hibáztatják a fordítót / számítógép először) "
  • Ön tisztában van a " bug , igaz? Mármint a szoftverfejlesztésben. Természetesen ma nincs ' ez a probléma, de egy hiba valóban a számítógép hardverébe repült a programozó észrevétele nélkül, és problémát okozott.Nehogy valaki meggondoljon engem, tudom, hogy Edison ezt a kifejezést jóval a molyesemény előtt használta, ezért használtam a ' history ', nem ' origin '. Lásd: computerworld.com/article/2515435/app-development/… és hu.wikipedia.org/wiki/Software_bug#Etymology
  • Természetesen @threed. De jó ideje a rovarok nem okozták a szoftveres hibák túlnyomó részét.

Válasz

  1. Tesztek írása. A tesztelés nemcsak a hibák megelőzésében kiváló (tapasztalatom szerint a TDD helyesen készítve szinte minden triviális, hülye hibát kiküszöböl), hanem sokat segít a hibakeresésben is. A tesztelés miatt a tervezés meglehetősen moduláris, ami megkönnyíti a probléma elkülönítését és megismétlését. Emellett te irányítod a környezetet, így sokkal kevesebb meglepetés lesz. Sőt, ha kap egy kudarcot valló tesztesetet, akkor ésszerűen biztos lehet abban, hogy a téged zavaró magatartás valódi okát szögezte le.

  2. Ismerje meg a hibakereső használatát. A print utasítások meglehetősen jól működhetnek valamilyen szinten, de a hibakereső legtöbbször nagyon hasznos (és egyszer tudod, hogyan kell használni, sokkal kényelmesebb, mint a print állításoknál.

  3. Beszélj valakiről a problémádról, még akkor is, ha ez csak egy gumikacsa . Az a kényszer, hogy szavakkal fejezze ki a problémát, amelyen dolgozik, valóban csodákat tesz.

  4. Adjon meg magának időkorlátot. Ha például 45 perc elteltével úgy érzi, hogy nem megy sehová, csak egy ideig váltson más feladatokra. Amikor visszatér a hibájához, remélhetőleg más lehetséges megoldásokat is megismerhet, amelyeket korábban nem gondolt volna.

Megjegyzések

  • +1 a " címre, ha arra kényszeríted magad, hogy szavakkal fejezd ki a problémát, amin dolgozol, valóban csodákat tesz. "
  • És az (1) kiegészítéséhez szinte minden olyan hiba, amelyet a kódban lát, azt jelenti, hogy ' van egy hiba – vagy legalábbis egy kihagyás – a tesztcsomagban. Javítsa egyszerre mindkettőt, és nemcsak azt bizonyítja, hogy ' megoldotta a problémát, ' biztonságban van újra bevezették.

Válasz

A többi válasz tetszik a legtöbbnek, de itt van néhány tipp a tennivalókról MIELŐTT bármit is tenne. Időt takarít meg a beaucoup számára.

  1. Határozza meg, hogy valóban van-e hiba. A hiba MINDIG különbség a rendszer viselkedése és a követelmények között; a tesztelőnek képesnek kell lennie a várható és a tényleges viselkedés megfogalmazására. Ha nem tud támogatást nyújtani a várható viselkedéshez, nincs követelmény és nincs hiba – csak valaki véleménye. Küldje vissza.

  2. Vegye fontolóra a lehetőséget hogy a várt magatartás téves. Ennek oka lehet a követelmény téves értelmezése. Ennek oka lehet maga a követelmény hibája is (delta a részletes követelmény és az üzleti követelmény között). Ezeket is visszaküldheti.

  3. Szigetelje el a problémát. Csak a tapasztalatok tanítják meg ennek a leggyorsabb módját – néhány ember szinte meg tudja csinálni a belével. Az egyik alapvető megközelítés egy dolog változtatása, miközben minden más dolog állandóan tartása (más környezetekben is előfordul-e a probléma? más böngészőkkel? egy másik vizsgálati régióban? a nap különböző időpontjaiban?) Egy másik megközelítés a veremdombok vagy hibaüzenetek vizsgálata – néha csak elmondhatja a formázás módja szerint a rendszer melyik eleme dobta az eredeti hibát (pl. ha németül van, az a harmadik fél, akivel Berlinben dolgozol).

  4. Ha két együttműködő rendszerre szűkítette, ellenőrizze a két rendszer közötti üzeneteket forgalomfigyelő vagy naplófájlok segítségével , és meghatározza, melyik rendszer viselkedik a specifikációval és melyik nem. Ha kettőnél több rendszer van a forgatókönyvben, akkor páros ellenőrzéseket hajthat végre, és “lefelé” haladhat az alkalmazás-veremben.

  5. A probléma elkülönítésének oka annyira kritikus az lehet, hogy a probléma nem a kód hibája miatt következik be, amely felett Ön ellenőrzése alatt áll (pl. harmadik féltől származó rendszerek vagy a környezet), és azt szeretné elérni, hogy az adott fél a lehető leggyorsabban átvegye az irányítást. Ez mind a munka megtakarítása, mind pedig azonnali pontba helyezés érdekében, hogy a felbontás a lehető legrövidebb időn belül elérhető legyen. Tíz napig nem akar dolgozni egy kérdésen, hogy valakinek más webszolgáltatását találja.

  6. Ha megállapította, hogy valóban van hiba, és valóban a kódban van, amelyet Ön irányít, tovább elkülönítheti a problémát az utolsó “ismert jó” build megkeresésével valamint a forrásellenőrzési naplók ellenőrzése azon változások miatt, amelyek a problémát okozhatták. Ez sok időt takaríthat meg.

  7. Ha nem tudja kitalálni a forrás vezérléséből, akkor itt az ideje, hogy csatolja a hibakeresőt, és végigvigye a kódot a kitaláláshoz. Lehetséges, hogy mostanra már nagyon jó elképzelése van a problémáról.

Ha már tudta, hol van a hiba, és ki tudja találni a javítást, itt jó kijavítási eljárás:

  1. Írjon olyan egységtesztet, amely megismétli a problémát és nem sikerül.

  2. Az egységteszt módosítása nélkül tegye meg átmegy (az alkalmazás kódjának módosításával).

  3. Tartsa az egység tesztet a tesztcsomagjában a regresszió megelőzéséhez / észleléséhez.

Válasz

Szerintem a hiba reprodukálása is fontos. Az összes eset, amely a hibát reprodukálja, felsorolható, majd megbizonyosodhat arról, hogy a hibajavítás lefedi ezeket az eseteket.

Válasz

Van egy kiváló könyv, amelyet elolvastam erről a témáról, a Miért sikertelenek a programok címmel, amely különböző stratégiákat vázol fel a hibák felkutatásához, a tudományos módszer alkalmazásától kezdve a hiba, delta hibakeresés. A könyv másik érdekes része, hogy megszünteti a “bug” kifejezést. Zeller megközelítése:

(1) A programozó hibát hoz létre a kódban. (2) A hiba fertőzést okoz (3) A fertőzés terjed (4) A fertőzés meghibásodást okoz.

Ha tovább akarja fejleszteni a hibakeresési képességeit, nagyon ajánlom ezt a könyvet.

Saját tapasztalataim szerint rengeteg hibát találtam alkalmazásunkban, de a menedzsment egyszerűen tovább nyom minket hogy új funkciókat hozzon ki. “Gyakran hallottam” Mi magunk találtuk meg ezt a hibát, és az ügyfél még nem vette észre, ezért hagyja csak addig, amíg meg nem teszik. Úgy gondolom, hogy a hibák kijavításával szembeni reaktivitás és a proaktív fellépés nagyon rossz ötlet, mivel amikor eljön az ideje a javítás tényleges behelyezésének, más problémákat is meg kell oldani, és további funkciók menedzselése ASAP-on keresztül akarja elérni az ajtót, így elkapják egy ördögi körfolyamatban, amely nagy stresszt és kiégést okozhat, és végül hibás rendszert vezethet be.

A kommunikáció szintén másik tényező hibakeresés esetén. E-mail küldése vagy dokumentálása a a hibakereső minden rendben van, de a saját tapasztalataim szerint más fejlesztők is találnak hasonló hibát, és ahelyett, hogy újból felhasználnák a kód javításához használt megoldást (mivel mindent elfelejtettek), hozzáadják a saját verzióikat, tehát 5 különböző megoldás van a kódodban, és ennek eredményeként duzzadtabbnak és zavaróbbnak tűnik. Tehát, ha kijavítasz egy hibát, győződjön meg róla, hogy néhány ember átnézi a javítást, és visszajelzést ad, ha valami hasonlót kijavítottak. jó stratégiát talált a kezelésére.

limist megemlítette a könyvet,

A Pragmatikus Programozó , amely érdekes anyagokat tartalmaz a hibák kijavításáról. Az előző bekezdésben megadott példával ezt a következőképpen nézem meg: Szoftver entrópiája , ahol egy megtört özvegy hasonlatát használják. Ha két sok törött Megjelennek az ablakok, csapata apátiássá válhat a javítással szemben, hacsak nem proaktív álláspontot képvisel.

Megjegyzések

  • I ' hallottuk " Ezt a hibát mi magunk találtuk meg, és az ügyfél még nem látta ', ezért hagyja csak addig, amíg túl sokszor teszik " t is. És miután helyszíni látogatásokra mentek, gyakran az ügyfél észrevette , de még nem ' t jelentette. Néha azért, mert úgy gondolják, hogy ' nincs értelme, mert nem nyerték meg ' t, néha azért, mert már nézik a versenytárs ' cseréjét, és néha (helyesen vagy helytelenül) " nos, akkor amúgy is minden gőzölgő halom baromfi ".
  • @JuliaHayward – Ez nagyon gyakran előfordul, de a te helyzetedben ügyfelei elégedettek lehetnek a funkcionalitással, és nem aggódnak túlságosan azzal, hogy mi zajlik ' a motorháztető alatt. A probléma akkor kezd felszínre kerülni, amikor az ügyfél visszatér, és további funkciókat kér, és hozzá kell adnia egy további fejlesztést, például azt, hogy az alkalmazás többnyelvű, mobil kompatibilis legyen bla bla, elkezdi nézegetni, mi van, és látja a fal minden repedését.
  • Csak megmutatja, hogy a világ összes könyve a szoftvertervezésről, tesztelésről és a jó kommunikációról, valamint sok termék, amelyen dolgozik, terjedő rendetlenséget jelent.Annak ellenére, hogy tudjuk, mi a ' joga, a stressz és az irreális határidők (a már elrontott kóddal szemben) okai annak, hogy a kód a jelenlegi állapotában van. Magamnak nincs válaszom rá, én ' az irodában eléggé megkülönböztetem nyögő arcként ***** * miközben rúgok és üvöltözök, hogy egészséges legyen a kód és a fejlesztési folyamat zökkenőmentes legyen, de néha a csapat nem kötődik jól egymással.

Válasz

Hiba, hiba, probléma, hiba – bárhogy is nevezzük, nem sok különbség van. Ragaszkodom a problémához, mivel “amihez szoktam.

  1. Találd ki, mi a probléma észlelése: fordíts le egy ügyfélről” s “Bob még mindig nincs a rendszerben” a “Amikor megpróbálom hozzon létre felhasználói rekordot Bob számára, ez meghiúsul egy kulcsfontosságú kivétellel, bár Bob nincs “még bent”
  2. Találja ki, hogy ez valóban probléma vagy csak félreértés (sőt, Bob nem ” nincs ott senki, akit bobnak hívnak, és az insertnek működnie kell.
  3. Próbáljon meg minimálisan megbízható lépéseket követni a probléma reprodukálásához – valami hasonló: “Adott egy rendszer, amelynek felhasználói nyilvántartása” Bruce “, amikor a” Bob “felhasználói rekordot beillesztik, akkor kivétel lép fel.
  4. Ez a teszt – ha lehetséges, tegye be egy automatizált rendszerbe. próbakábel, amelyet újra és újra futtathat, ez felbecsülhetetlen lesz a hibakeresés során. A tesztkészlet részévé is teheti, hogy megbizonyosodjon arról, hogy az adott probléma később nem jelenik meg újra.
  5. Hozza ki a hibakeresőt, és kezdje el a töréspontokat – a teszt futtatásakor találja ki a kód elérési útját, és azonosítsa, mi a baj. Amíg ezt megteszi, finomíthatja a tesztet úgy is, hogy a lehető legszűkebbé tegye – ideális esetben egységnyi tesztet.
  6. Javítsa ki – ellenőrizze a teszt sikeres teljesítését.
  7. Ellenőrizze az eredeti problémát az ügyfél által leírt módon szintén rögzített (nagyon fontos – lehet, hogy csak a probléma egy részét javítottad ki). Ellenőrizze, hogy nem vezetett-e be regressziókat a program egyéb aspektusaiba.

Ha nagyon ismeri a kódot, vagy ha a probléma vagy a probléma megoldása nyilvánvaló, akkor kihagyhatja ezeket. lépések.

Hogyan kell hozzá fordulnunk, hogy értékes időnket a lehető leghatékonyabban tudjuk felhasználni, és lehetővé tegyük számunkra, hogy kevesebb időt töltsünk a megkeresésével és több időt kódoljunk ?

Kifogásolom ezt, mivel ez azt jelenti, hogy az új kód megírása értékes lépés, mint egy magas színvonalú munkaprogram. Nincs semmi baj azzal, hogy a lehető leghatékonyabban oldja meg a problémákat, de egy program nem feltétlenül jobb, ha csak több kódot ad hozzá.

Megjegyzések

  • ez a legjobb válasz IMO

Válasz

Így csinálom:

  1. ugyanazt a módszert használja minden alkalommal a probléma megtalálásához. Ez javítja a hibákra adott reakcióidőt.
  2. A legjobb módszer valószínűleg a kód elolvasása. Ennek az az oka, hogy minden információ elérhető a kódban. Csak hatékony módszerekre van szüksége a helyes helyzet megtalálásához és a részletek megértéséhez.
  3. A hibakeresés nagyon lassú, és csak akkor szükséges, ha a programozói még nem értik, hogyan hajtja végre a számítógép az asm utasításokat / nem értik a híváshalmokat. és az alapvető dolgok
  4. Próbáljon meg olyan bizonyítási technikákat kifejleszteni, mint például a függvény prototípusainak használata a program viselkedésének megalapozása érdekében. Ez segít gyorsabban megtalálni a helyes pozíciót

Válasz

Ha hibát észlelünk a kódunkban, mit tehetünk a gyomirtás érdekében? Hogyan kell hozzá fordulnunk ahhoz, hogy értékes időnket a lehető leghatékonyabban tudjuk felhasználni, és lehetővé tegyük számunkra, hogy kevesebb időt töltsünk a megkeresésével és több időt töltsünk kódolással? Ezenkívül mit szabad kerülni a hibakeresés során?

Feltéve, hogy éles környezetben van, a következőket kell tennie:

  1. Írja le helyesen a „hibát”, és azonosítsa azokat az eseményeket, amelyek miatt előfordulhat.

  2. Határozza meg, hogy a „hiba” kódhiba vagy specifikációs hiba. Például egy betűs név megadása hibának tekinthető egyes rendszereknél, de elfogadható viselkedés más rendszereknél. Néha a felhasználó jelentett egy hibát, amely szerinte problémát jelent, de a felhasználó elvárása a rendszer viselkedésével szemben nem volt része a követelményeknek.

  3. Ha bebizonyították, hogy hibában van, és a hibát a kód okozza, akkor meghatározhatja, hogy mely kódrészeket kell javítani a hiba megelőzése érdekében. Vizsgálja meg a viselkedés hatását az aktuális adatokra és a jövőbeli rendszerműveletekre is (hatáselemzés kód és adatok).

  4. Ezen a ponton valószínűleg megkapja a becslést arról, hogy mennyi erőforrást fognak felhasználni a hiba kijavításához. Megjavíthatja azonnal, vagy ütemezzen javítást a szoftver közelgő kiadásán belül.Ez attól is függ, hogy a végfelhasználó hajlandó-e fizetni a javításért. Ki kell értékelnie a rendelkezésre álló lehetőségeket a hiba kijavításához. Többféleképpen lehet. Ki kell választania a helyzetnek leginkább megfelelő megközelítést.

  5. Elemezze a hiba megjelenésének okait (követelmények, kódolás, tesztelés stb.). Kényszerít olyan folyamatokat, amelyek megakadályoznák az állapot újbóli előfordulását.

  6. Dokumentálja az epizódot megfelelően.

  7. Engedje el a javítást (vagy a új verzió)

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük