Programování

Učení a zdokonalování vašich dovedností při ladění

Programátoři tráví vysoké procento času laděním spíše než psaním kódu. Pravděpodobně jste měli nějaké školení v učení jazyka nebo rámce - ale jak jste se naučili opravit chyby ve vašem softwaru?

Když jste se zamilovali do programování (nebo jste se alespoň rozhodli, že jde o odměňovanou kariéru), pravděpodobně jste to považovali za kreativní snahu. Navrhli byste skvělý software, napsali kód a teplouš!—Fungovalo by to perfektně poprvé.

To jo. Že jo.

Ve skutečném světě jste místo psaní nových věcí strávili spoustu času laděním kódu. Jsem si jistý, že bych mohl vykopat nějaké nejasné procento času vývojáře, které se věnuje opravě defektů, spíše než vytváření nových funkcí, ale pochybuji, že musíte slyšet číslo. Můžete si příliš snadno představit dny, které jste strávili hledáním Chyby z pekla a jejich vlivu na harmonogram vašeho projektu.

Nyní existuje spousta způsobů, jak se programátoři mohou a mohou naučit nové softwarové dovednosti, ať už je to čtení knihy, účast na technické konferenci nebo návštěva webů jako JavaWorld.com. (Jsem docela rád, že děláte to druhé.) Obvykle se však zaměřují na nástroje, jako jsou jazyky nebo rámce, a nikoli na meta-techniky, například „Jak najít chybu za dvě hodiny místo dvou dnů.“ Jazyky mohou přicházet a odcházet, stejně tak ladicí programy IDE, ale schopnost rozpoznat, pod jakou skálou se vaše chyba skrývá, vám zůstane navždy.

Velká část dovednosti naučit se ladit je samozřejmě zkušenost. Může to být vaše vlastní zkušenost nebo příležitost být Grasshopperem u nohou hlavního programátora. Mám také podezření, že někteří lidé mají vrozený talent na řešení problémů (stejně relevantní pro opravu rozbitého auta jako špatně fungující aplikace) a ti z nás, kteří to nemají, mohou jen závistět.

Nicméně, nějaký z toho se lze naučit. Například jeden hlavní programátor mého známého měl axiom: Pokud jste hledali chybu po (relativně) dlouhou dobu a nemůžete ji najít, řekl: „Hledáte na špatném místě.“ Zřetelně znějící, ale určitě pravdivý ... a jak často jste ztrácel čas hledáním v modulu XYZ, když byl problém úplně někde jinde?

Zeptal jsem se několika vývojářů na způsoby, jak se naučili nebo jak vylepšili své ladicí schopnosti. Překvapivý počet z nich hovořil o svém zvládnutí ladicího programu IDE nebo jiných odborných znalostech o nástrojích, ale většinu z toho, co jsem chtěl vědět, je jejich rada na zlepšení schopnosti opravovat chyby. Zde je krátké shrnutí jejich odpovědí.

  1. Buďte disciplinovaní. Ladění je proces, řekl jeden vývojář, ne řada náhodných událostí. Nenatáčejte knoflíky náhodně; sledovat proces spuštění kódu. Stejně jako oprava sekačky na trávu, řekl. Dostává část A potřebný vstup? A co výstup? Pokud je to v pořádku, pokračujte.
  2. Chcete-li zlepšit své dovednosti, laděte kód jiných lidí, nikoli svůj vlastní. Bude snazší vidět chyby v předpokladech druhé osoby, než je vidět ty vlastní. Můžete to udělat jako součást kontroly kódu napříč peery a ladění napříč peery. Rozvinete schopnost rychleji rozpoznávat běžné příčiny závad, slíbil jste jednomu vývojáři a naučíte se rozpoznávat (a opouštět) své vlastní špatné vývojové postupy.
  3. Předstírejte, že jste kompilátor. Před stisknutím tlačítka Kompilace vyhledejte a opravte co nejvíce chyb. Zatímco většina moderních IDE obsahuje integrované debuggery (jako je Intellisense sady Visual Studio), z jejich automatizace se naučíte méně než z vědomého zkoumání procesu. (Stejným způsobem se nikdy nenaučíte správně hláskovat spoléháním na kontrolu pravopisu, která bude dělat veškerou práci.)
  4. Naučte se opravovat chyby co nejdříve v procesu vývoje. To by mohlo znamenat něco formalizovaného, ​​například vývoj řízený testem. To také znamená věnovat čas ladění vašeho designu místo toho, abyste kódovali.
  5. Ladění je nejjednodušší, když můžete držet celý systém ve své hlavě. Nedělejte chybu, když se soustředíte pouze na jednu část aplikace. Věnujte pozornost vzájemným vztahům mezi moduly. Přečtěte si kód na více úrovních abstrakce, doporučil jeden programátor. „Nalezení chyby je nejtěžší část a je nutné jasně pochopit, co dělá více částí kódu,“ řekla.
  6. Část stejné rady, myslím, je návrh někoho jiného: získejte dobré porozumění systému o jednu úroveň níže, než na čem pracujete. „Pokud ladíte program na úrovni systému C, pomůže vám to poznat nějaké sestavení a něco o OS,“ vysvětlil vedoucí inženýr systémového softwaru. „Pokud ladíte aplikaci J2EE, pomůže vám to zjistit něco o vláknech Java, RMI a GC.“ V mnoha případech poukázal na to, že chybové zprávy pocházejí z této úrovně. „Pokud pochopíte, co to znamená, pomůže vám to zjistit, co se na vaší úrovni abstrakce zhoršuje,“ vysvětlil.

Několik vývojářů také doporučilo další zdroje. Mezi nimi je kniha Davida Agana Debugging, která slibuje devět nepostradatelných pravidel, a Why Program Fail: A Guide to Systematic Debugging, která má vyjít ve druhém vydání. Vývojář, který to doporučil, říká, že učí systematickému přístupu k ladění se spoustou praktických příkladů. Další navrhl online esej Deset dovedností vysoce efektivních softwarových testerů.

Všechny tyto odpovědi se mi líbí, ale domnívám se, že je třeba sdílet více moudrosti. Jak jste získali své ladicí schopnosti? Jak jste pomohli ostatním zlepšit jejich?

Tento příběh „Učení a zlepšování dovedností při ladění“ původně publikoval JavaWorld.

$config[zx-auto] not found$config[zx-overlay] not found