Jak nejefektivněji ladit kód? [uzavřeno]

Myšlenka a přístup k ladění je možná nejdůležitější část, protože určuje, jak efektivně chybu opravíte a co se z ní naučíte – pokud vůbec.

Klasika v oblasti vývoje softwaru jako Pragmatický programátor a Code Complete v zásadě argumentují stejným přístupem: každá chyba je příležitost naučit se, téměř vždy o sobě (protože kompilátor / počítač obviňují pouze začátečníci).

Berte to tedy jako záhadu, kterou bude zajímavé prolomit. A prolomení této záhady by mělo být prováděno systematicky, vyjádřením našich předpokladů (pro sebe nebo pro ostatní) a následným testováním našich předpokladů, pokud je to nutné, jednotlivě – pomocí všech nástrojů, které máme k dispozici, zejména debuggerů a automatizovaných testovacích rámců. Poté, co bude záhada vyřešena, můžete si ještě lépe prohlédnout celý svůj kód a najít podobné chyby, které jste možná udělali; a napsat automatický test, aby se zajistilo, že k chybě nedojde nevědomky znovu.

Jedna poslední poznámka – raději nazývám chyby „chyby“ a ne „chyby“ – Dijkstra svým kolegům vynadal, aby použili druhý termín, protože je to nečestné, podporující myšlenku, že zlověstné a vrtkavé chybné víly zasadily do našich programů chyby, zatímco jsme se nedívali, místo abychom tam byli kvůli našemu (nedbalému) myšlení: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD10xx/EWD1036.html

Mohli bychom například začít vyčistit náš jazyk již nevoláte chybu jako chybu, ale voláte ji jako chybu. Je to mnohem upřímnější, protože to dává vinu tam, kam patří, viz. s programátorem, který udělal chybu. Animistická metafora chyby, která se škodlivě vplížila dovnitř, když se programátor nedíval, je intelektuálně nečestná, protože maskuje, že chyba je vlastní tvorbou programátora. Pěknou věcí této jednoduché změny slovní zásoby je, že má tak hluboký účinek : zatímco dříve byl program s pouze jednou chybou „téměř správný“, poté byl program s chybou jen „špatný“ (protože omylem).

Komentáře

• Vlastně se mi líbí výraz " chyba " spíše než " chyba ", ne proto, že by to bylo na vině " programátoru kdo udělal chybu ", ale proto, že jasně ukazuje, že to nemohl ne zavinit programátor. Pro mě " chyba " implikuje chybu v kódu; zatímco " chyba r " implikuje chybu někde . Možná v kódu, možná v nastavení prostředí, možná v požadavcích. Přiměje mě to, když má můj šéf " seznam chyb ", kde polovinou problémů jsou změny požadavků. Říkejte tomu seznam úkolů, ferchrissakes!
• +1 pro " každá chyba je příležitostí se učit, téměř vždy o sobě (protože kompilátor viní pouze začátečníky / nejprve počítač) "
• Znáte historii pojmu " chyba ", že? Mám na mysli, jak se používá při vývoji softwaru. Dnes samozřejmě tento problém nemáme ' t, ale chyba ve skutečnosti vletěla do hardwaru počítače bez povšimnutí programátora a způsobila problém.Pokud si někdo myslí, že mě neopraví, vím, že Edison použil tento výraz dlouho před můrovým incidentem, a proto jsem použil slovo ' history ', ne ' origin '. Viz computerworld.com/article/2515435/app-development/… a en.wikipedia.org/wiki/Software_bug#Etymology
• @threed Samozřejmě. Hmyz však již nějakou dobu nezpůsobil naprostou většinu softwarových chyb.

1. Psát testy. Testování je nejen skvělé při prevenci chyb (podle mých zkušeností TDD provedeno 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ž značně usnadňuje izolaci a replikaci problému. Také ovládáte prostředí, takže vás překvapí mnohem méně. Jakmile navíc získáte testovací případ, který vám propadne, můžete si být přiměřeně jisti, že jste přibili skutečný důvod chování, které vás obtěžuje.

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

3. Promluvte si o svém problému s někým, i když je to jen gumová kachnička . Když se budete nutit slovy vyjádřit problém, na kterém pracujete, opravdu zázraky.

4. Dejte si časový limit. Pokud například po 45 minutách máte pocit, že nikam nevedete, přepněte na nějakou dobu na jiné úkoly. Až se vrátíte k chybě, doufejme, že uvidíte další možná řešení, která byste dříve nezvažovali.

Komentáře

• +1 pro " Nutí vás vyjádřit problém, na kterém pracujete, slovy, dělá opravdu zázraky. "
• A přidat do (1), téměř každá chyba, kterou v kódu vidíte, znamená, že ' sa chyba – nebo alespoň opomenutí – v testovací sadě. Opravte oboje současně a nejen že prokážete, že jste ' opravili problém, jste ' v bezpečí proti jeho znovu zavedeno.

Líbí se mi většina ostatních odpovědí, ale zde je několik tipů, co dělat PŘED tím, než něco z toho uděláte. 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í tam žádný požadavek a není tam žádná chyba – pouze názor někoho jiného. Zašlete jej zpět.

2. Zvažte možnost že očekávané chování je špatné. Mohlo by to být způsobeno nesprávnou interpretací požadavku. Mohlo by to být také způsobeno vadou samotného požadavku (delta mezi podrobným požadavkem a obchodním požadavkem). Můžete je také odeslat zpět.

3. Izolujte problém. Nejrychlejší způsob, jak to udělat, vás naučí pouze zkušenost – někteří lidé to dokáží téměř se svými vnitřnostmi. Jedním ze základních přístupů je změna jedné věci, zatímco zachování všech ostatních věcí konstantní (nastává problém v jiných prostředích? s jinými prohlížeči? v jiné testovací oblasti? v různých časech dne?) Dalším přístupem je podívat se na skládky zásobníku nebo chybové zprávy – někdy můžete říct jen mimochodem je naformátováno, která součást systému hodila původní chybu (např. pokud je to v němčině, můžete bla já, ta třetí strana, se kterou pracujete v Berlíně).

4. Pokud jste to zúžili na dva systémy, které spolupracují, zkontrolujte zprávy mezi těmito dvěma systémy pomocí sledování provozu nebo souborů protokolu , a určit, který systém se chová ke specifikaci a který ne. Pokud jsou ve scénáři více než dva systémy, můžete provádět párové kontroly a postupovat „dolů“ v zásobníku aplikací.

5. Důvod, proč je izolace problému tak důležitý je, že problém nemusí být způsoben vadou kódu, kterou máte pod kontrolou (např. systémy třetích stran nebo prostředí) a chcete, aby tato strana převzala kontrolu co nejrychleji. To vám má ušetřit práci a okamžitě je dostat na bod, aby bylo možné dosáhnout rozlišení v co nejkratším časovém rámci. Nechcete na problému pracovat deset dní, jen abyste zjistili, že je to opravdu problém s webovou službou někoho jiného.

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

7. Pokud to nemůžete zjistit z řízení zdroje, nyní je čas připojit debugger a projít kódem, abyste to zjistili je pravděpodobné, že už máte o problému docela dobrou představu.

Jakmile víte, kde je chyba, a můžete myslet na opravu, tady je dobré postup pro jeho opravu:

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

2. Bez úpravy testu jednotky proveďte to projde (úpravou kódu aplikace).

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

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

Na toto téma jsem si přečetl vynikající knihu s názvem Proč selhávají programy , která popisuje různé strategie pro hledání chyb, od použití vědecké metody až po izolaci a vyřešení bug, to delta debugging. Druhou zajímavou částí této knihy je, že odstraňuje pojem „chyba“. Zellerův přístup je:

(1) Programátor vytvoří v kódu vadu. (2) Vada způsobí infekci (3) Infekce se rozšíří (4) Infekce způsobí poruchu.

Pokud si chcete vylepšit své ladicí schopnosti, tuto knihu velmi doporučuji.

Podle vlastních osobních zkušeností jsem v naší aplikaci našel spoustu chyb, ale vedení nás jednoduše tlačí dál získat nové funkce. „Často jsem slyšel“ Tuto chybu jsme našli sami a klient si ji ještě nevšiml, takže ji nechte, dokud to neudělá. “ Myslím, že být reaktivní na rozdíl od proaktivního při opravě chyb je velmi špatný nápad, protože až přijde čas na opravu, máte další problémy, které je třeba vyřešit, a další funkce, které správa potřebuje, jsou hned za dveřmi, takže vás chytí v začarovaném cyklu, který může vést k velkému stresu a vyhoření, a v konečném důsledku k defektnímu systému.

Komunikace je také dalším faktorem, když jsou nalezeny chyby. Zaslání e-mailu nebo jeho zdokumentování na sledování chyb je v pořádku a dobře, ale podle mých vlastních zkušeností najdou ostatní vývojáři podobnou chybu a místo toho, aby znovu použili řešení, které jste vložili k opravě kódu (protože už na to všechno zapomněli), přidávají své vlastní verze, takže ve svém kódu máte 5 různých řešení a ve výsledku to vypadá více nafouklé a matoucí. Takže když opravíte chybu, ujistěte se, že několik lidí tuto opravu zkontroluje a dá vám zpětnou vazbu v případě, že opravili něco podobného a našel dobrou strategii, jak s tím zacházet.

Limist zmínil knihu,