it-swarm-eu.dev

Jak co nejefektivněji ladit kód?

Chyby vkrádající se do kódu lze minimalizovat, ale ne zcela odstranit, jak je psáno - programátoři jsou, i když mnozí by nesouhlasili , pouze lidé.

Když zjistíme chybu v našem kódu, co můžeme udělat, abychom ji odstranili? Jak bychom se k ní měli přiblížit, abychom co nejefektivněji využili náš drahocenný čas a umožnili nám trávit méně času pokusem jej najít a více času kódováním? Co bychom se měli vyhnout při ladění?

Zde si uvědomte, že nemluvíme o prevenci chyb; mluvíme o tom, co dělat, když se objeví chyby . Vím, že je to široké pole a může být velmi závislé na jazyce, platformě a nástrojích. Pokud ano, pokračujte v zahrnutí odpovědí, jako jsou myšlení a obecné metody.

33
gablin

Pravděpodobně nejdůležitější součástí je myšlení a přístup k ladění, protože určuje, jak účinně chybu vyřešíte a co z ní zjistíte - pokud vůbec.

Klasika vývoje softwaru jako The Pragmatic Programmer a Code Complete v podstatě argumentují pro stejný přístup: každá chyba je příležitost učit se, téměř vždy o sobě (protože kompilátor/počítač nejprve obviňují pouze začátečníci).

Takže s ním zacházejte jako s tajemstvím, které bude zajímavé prasknout. A praskat, že záhada by měla být prováděna systematicky, vyjádřením našich předpokladů (pro nás nebo pro ostatní) a poté otestováním našich předpokladů, v případě potřeby, jeden po druhém - pomocí každého nástroje, který máme k dispozici, zejména debuggerů a automatizovaných testovacích rámců. Poté, co je záhada vyřešena, můžete to udělat ještě lépe tím, že si ve svém kódu prohlédnete podobné chyby, které jste možná udělali; a napsat automatizovaný test, aby se zajistilo, že k chybě nedojde znovu nevědomky.

Jedna poslední poznámka - raději nazývám chyby „chybami“ a ne „chybami“ - Dijkstra své kolegy honil za použití posledního termínu, protože je to nepoctivé, což podporuje myšlenku, že v našich programech byly v našich programech zasazeny zhoubné a drsné víly, zatímco jsme byli „ Nehledě, místo toho, abychom tam byli kvůli našemu vlastnímu (nedbalému) myšlení: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html

Mohli bychom například začít s čištěním našeho jazyka tak, že už nebudeme volat chybu, ale voláním chyby. Je to mnohem upřímnější, protože přímo vinu tam, kam patří, viz. s programátorem, který udělal chybu. Animistická metafora chyby, která se zlomyslně vkrádala, zatímco programátor se nedíval, je intelektuálně nečestná, protože zakrývá, že chyba je vlastní tvorbou programátora. Pěkná věc této jednoduché změny slovní zásoby je, že má takový hluboký účinek: zatímco předtím byl program s pouze jednou chybou „téměř správný“, potom program s chybou je prostě „špatný“ (protože v chyba).

38
limist
  1. Napište testy. Testování je nejen skvělé v prevenci chyb (podle mého názoru TDD udělal správně, eliminuje téměř všechny triviální, hloupé chyby), ale také hodně pomáhá při ladění. Testování nutí váš návrh být spíše modulární, což výrazně usnadňuje izolaci a replikaci problému. Také ovládáte prostředí, takže bude mnohem méně překvapení. Navíc, jakmile dostanete neúspěšný testovací případ, můžete si být jisti, že jste přibili skutečný důvod chování, které vás obtěžuje.

  2. Naučte se používat debugger. Příkazy print mohou na určité úrovni fungovat docela dobře, ale debugger je většinou velmi velmi užitečný (a jakmile víte, jak používat, to je mnohem pohodlnější než print příkazy).

  3. Mluvte o někom o svém problému, i když je to jen gumová kačenka . Přinutit se vyjádřit problém, na kterém pracujete slovy, opravdu dělá zázraky.

  4. Dejte si časový limit. Pokud se například po 45 minutách cítíte, že jdete nikam, stačí na nějakou dobu přejít na jiné úkoly. Až se vrátíte ke své chybě, doufejme, že uvidíte další možná řešení, která byste předtím neuvažovali.

16
Ryszard Szopa

Existuje vynikající kniha, kterou jsem četl na toto téma s názvem Proč Program Fail , která nastiňuje různé strategie pro hledání chyb, od použití vědecké metody izolovat a vyřešit chybu, až delta ladění. Další zajímavou částí této knihy je, že se zbavuje pojmu „chyba“. Zellerův přístup je:

(1) Programátor vytvoří chybu v kódu. (2) Vada způsobuje infekci (3) Infekce se šíří (4) Infekce způsobuje selhání.

Pokud chcete zlepšit své ladicí dovednosti, velmi doporučuji tuto knihu.

Podle mé osobní zkušenosti jsem v naší aplikaci našel spoustu chyb, ale vedení nás prostě tlačí kupředu, abychom dostali nové funkce. Často jsem slyšel „Tuto chybu jsme našli sami a klient si toho ještě nevšiml, takže ji prostě nechte, dokud to neudělá“. Myslím, že být reaktivní na rozdíl od proaktivního v opravování chyb je velmi špatný nápad, protože když přijde čas na opravu, máte další problémy, které je třeba vyřešit, a další funkce se chtějí zbavit dveří ASAP, takže vás chytí v začarovaném cyklu, který může vést k velkému stresu a vyhoření a nakonec k defektnímu jízdnímu systému.

Komunikace je také dalším faktorem při hledání chyb. Odeslání e-mailu nebo jeho zdokumentování na sledování chyb je v pořádku a dobře, ale podle mé vlastní zkušenosti ostatní vývojáři najdou podobnou chybu a spíše než opětovné použití řešení, které jste dali, opravit kód (protože na to všechno zapomněli) ), přidají své vlastní verze, takže máte ve svém kódu 5 různých řešení a v důsledku toho to vypadá nafouklejší a matoucí. Když tedy opravíte chybu, ujistěte se, že několik lidí tuto opravu zkontroluje a poskytne vám zpětnou vazbu v případě, že opravili něco podobného a našli dobrou strategii, jak ji vyřešit.

limist se zmínil o knize The Pragmatic Programmer , která obsahuje zajímavý materiál k opravě chyb. Na příkladu, který jsem uvedl v předchozím odstavci, bych se podíval na toto: Software Entrophy , kde se používá analogie rozbité vdovy. Pokud se objeví dvě mnoho rozbitých oken, může se váš tým stát apatickým směrem k jeho opravě, pokud nezaujme aktivní postoj.

3
Desolate Planet

Líbí se mi většina ostatních odpovědí, ale zde je několik tipů, co dělat, než uděláte něco z toho. Ušetří vám čas na beaucoup.

  1. Zjistěte, zda skutečně existuje chyba. Chyba je VŽDY rozdíl mezi chováním systému a požadavky; tester by měl být schopen formulovat očekávané a skutečné chování. Pokud není schopen poskytnout podporu očekávanému chování, není zde žádný požadavek a žádná chyba - pouze názor někoho. Poslat to zpět.

  2. Zvažte možnost, že očekávané chování není správné. Důvodem může být nesprávná interpretace požadavku. Mohlo by to být také způsobeno vadou samotného požadavku (delta mezi podrobným požadavkem a požadavkem podnikání). Můžete je také poslat zpět.

  3. Izolujte problém. Jedině zkušenost vás naučí nejrychlejším způsobem, jak toho dosáhnout - někteří lidé to mohou dělat téměř svým střevem. Jedním ze základních přístupů je změna jedné věci při zachování všech ostatních věcí konstantní (dochází k problému v jiných prostředích? U jiných prohlížečů? V jiné testovací oblasti? V různých časech dne?) Dalším přístupem je podívat se na skládky skládek nebo chybové zprávy - někdy můžete říct, jak je formátován, která složka systému vyvolala původní chybu (např. pokud je to v němčině, můžete vinit třetí stranu, se kterou pracujete v Berlíně).

  4. Pokud jste ji zúžili na dva spolupracující systémy, prohlédněte si zprávy mezi těmito dvěma systémy prostřednictvím sledování provozu nebo souborů protokolu a určete, který systém se chová podle specifikace a který nikoli. Pokud jsou ve scénáři více než dva systémy, můžete provádět párové kontroly a zpracovávat cestu „dolů“ v aplikačním zásobníku.

  5. Důvod, proč je izolace problému tak kritická, spočívá v tom, že problém nemusí být způsoben vadou kódu, nad kterou máte kontrolu (např. Systémy třetích stran nebo životní prostředí), a chcete, aby tato strana převzala co nejrychleji to možné . To je jak pro úsporu práce, tak pro okamžité nasměrování, aby bylo možné dosáhnout rozlišení v co nejkratším časovém rámci. Nechcete pracovat na problému po dobu deseti dnů, abyste zjistili, že se jedná o problém s webovou službou někoho jiného.

  6. Pokud jste zjistili, že skutečně existuje vada a je skutečně v kódu, který ovládáte, můžete problém dále izolovat hledáním posledních „známých dobrých“ protokolů řízení zdrojů, které obsahují změny, které mohly problém způsobit. To může ušetřit spoustu času.

  7. Pokud nemůžete přijít na to z ovládání zdroje, nyní je čas připojit debugger a projít kódem, aby to přijde. Je pravděpodobné, že nyní máte docela dobrou představu o problému stejně.

Jakmile víte, kde je chyba a může myslet na opravu, zde je dobrý postup pro její opravu:

  1. Napište test jednotky, který problém reprodukuje a selže.

  2. Aniž byste měnili test jednotky, nechte jej projít (změnou kódu aplikace).

  3. Ponechejte test jednotky v testovací sadě, abyste zabránili/detekovali regresi.

3
John Wu

Chyba, chyba, problém, vada - cokoli chcete nazvat, to nijak nezmění. Budu se držet problému, protože na to jsem zvyklý.

  1. Zjistěte, jaké je to vnímání problému: překládat ze zákaznického „Bob stále není v systému“ na „Když se pokusím vytvořit uživatelský záznam pro Bob, selže to s duplicitní klíčovou výjimkou, i když Bob již není tam'
  2. Zjistit, jestli je to opravdu problém nebo jen nedorozumění (opravdu, Bob tam není, není nikdo, kdo by se jmenoval bob a vložka by měla fungovat).
  3. Pokuste se získat minimální spolehlivé kroky, které můžete použít k reprodukci problému - něco jako „Vzhledem k systému s uživatelským záznamem„ Bruce “, když je vložen uživatelský záznam„ Bob “, dojde k výjimce“
  4. Toto je váš test - pokud je to možné, vložte jej do automatizovaného zkušebního svazku, který můžete znovu a znovu spustit, což bude při ladění neocenitelné. Můžete se také stát součástí vaší testovací sady a zajistit, aby se tento konkrétní problém později neobjevil.
  5. Vyjměte debugger a začněte uvádět body přerušení - při spuštění testu zjistěte cestu k kódu a určete, co je špatně. I když to děláte, můžete také vylepšit svůj test tím, že bude co nejužší - ideálně jednotkový test.
  6. Opravte to - ověřte své zkušební průchody.
  7. Ověřte, zda je původní problém popsaný zákazníkem také opraven (velmi důležité - možná jste opravili jen podmnožinu problému). Ověřte, že jste nezavedli regrese v jiných aspektech programu.

Pokud jste velmi dobře obeznámeni s kódem nebo pokud je problém nebo oprava zřejmá, můžete některé z těchto kroků přeskočit.

Jak bychom se k ní měli přiblížit, abychom co nejefektivněji využili náš drahocenný čas a umožnili nám trávit méně času pokusem jej najít a více času kódováním?

S tím nesouhlasím, protože to znamená, že psaní nového kódu je hodnotné, než mít kvalitní pracovní program. Není nic špatného na tom, jak co nejúčinněji řešit problémy, ale program se nemusí nutně vylepšit pouhým přidáním dalšího kódu.

3
ptyx

Myslím, že reprodukce chyby je také důležitá. Mohou být uvedeny všechny případy, které reprodukují chybu, a pak se můžete ujistit, že oprava chyby pokrývá všechny tyto případy.

3
aslisabanci

Když zjistíme chybu v našem kódu, co můžeme udělat, abychom ji odstranili? Jak bychom se k ní měli přiblížit, abychom co nejefektivněji využili náš drahocenný čas a umožnili nám trávit méně času pokusem jej najít a více času kódováním? Co bychom se měli vyhnout při ladění?

Za předpokladu, že se nacházíte v produkčním prostředí, je třeba udělat následující kroky:

  1. Popište „chybu“ správně a určete události, které ji způsobí.

  2. Zjistěte, zda je „chyba“ chyba kódu nebo chyba specifikace. Například zadání jednoho písmene názvu může být považováno za chybu pro některé systémy, ale pro jiné systémy přijatelné chování. Někdy by uživatel oznámil chybu, o níž si myslí, že je problém, ale očekávání uživatele ohledně chování systému nebyla součástí požadavků.

  3. Pokud jste prokázali, že došlo k chybě a chyba je způsobena kódem, pak můžete určit, které kousky kódu je třeba opravit, aby nedošlo k chybě. Zkoumejte také vliv chování na aktuální data a budoucí operace systému (analýza dopadu na kód a data).

  4. V tomto okamžiku byste pravděpodobně měli odhadnout, kolik zdrojů bude spotřebováno na opravu chyby. Můžete to hned opravit nebo naplánovat opravu v rámci nadcházejícího vydání softwaru. Závisí to také na tom, zda je koncový uživatel ochoten za opravu zaplatit. Měli byste také vyhodnotit různé dostupné možnosti, jak chybu opravit. Může existovat více než jeden způsob. Musíte vybrat přístup, který nejlépe vyhovuje dané situaci.

  5. Analyzujte důvody, proč se tato chyba objevila (požadavky, kódování, testování atd.). Vynutit procesy, které by zabránily opakování stavu.

  6. Epizodu přiměřeně dokumentujte.

  7. Uvolněte opravu (nebo novou verzi)

1
NoChance

Takto to dělám:

  1. vždy použijte stejnou metodu k nalezení problému. Tím se zlepší váš reakční čas na chyby.
  2. Nejlepší způsob je pravděpodobně čtení kódu. Je to proto, že všechny informace jsou v kódu k dispozici. Potřebujete pouze efektivní způsoby, jak najít správnou polohu a schopnost porozumět všem detailům.
  3. ladění je velmi pomalé a je to nutné pouze v případě, že vaši programátoři dosud nechápou, jak počítač provádí instrukce ASM/nerozumí hromadám hovorů a základním materiálům
  4. Zkuste vyvinout metody důkazu, jako je použití prototypů funkcí k odůvodnění chování programu. Pomůže to rychleji najít správnou polohu
1
tp1