GraphQL.cz/Fórum/Co by mělo být součástí dokumentace pro chybová hlášení?

Co by mělo být součástí dokumentace pro chybová hlášení?

Když se potýkáme s chybovými hlášeními ve vývoji aplikací, je pro mě důležité mít přehled o tom, co všechno by měla zahrnovat dokumentace těchto chyb. Zajímalo by mě, jaké konkrétní informace považujete za nezbytné, aby bylo možné efektivně identifikovat a řešit problémy. Co byste řekli, že je klíčové mít na paměti, když zaznamenáváme chyby? Měly by tam být třeba podrobnosti jako je typ chyby, její umístění v kódu nebo nějaký unikátní identifikátor? A co logy nebo kontext, ve kterém k chybě došlo? Jak moc je důležitá reprodukovatelnost chyby a také popis kroků k jejímu vyvolání? Zajímalo by mě také, jestli máte nějaké doporučení ohledně formátu, ve kterém by tyto informace měly být prezentovány. Například, měl by být záznam strukturovaný nebo spíš volný text? A nezapomeňme na uživatelské rozhraní – jakým způsobem by měly být tyto chyby zobrazovány koncovým uživatelům? Je lepší mít jednoduchá hlášení s minimem technických detailů nebo podrobné zprávy pro pokročilé uživatele? Díky za jakékoli tipy a zkušenosti, které můžete sdílet!

163 slov
1.6 minut čtení
1. 8. 2023
Jan Šafařík

Když se bavíme o dokumentaci chybových hlášení, tak bych řekl, že je fakt důležitý mít tam pár klíčových věcí. Určitě typ chyby – jestli je to něco jako runtime exception nebo třeba logická chyba. Umístění v kódu je taky nutnost, abys věděl, kde hledat. Unikátní ID pro každou chybu pomůže s přehledností. Nezapomeň na kontext, kdy k chybě došlo – jaký byl stav aplikace, co uživatel dělal atd. A reprodukovatelnost? To je zásadní, pokud nemůžeš chybu vyvolat znova, tak je těžké ji opravit. Krok za krokem popis toho, co udělat, aby se chyba objevila, by měl být součástí.

Co se týče formátu, strukturovaný záznam je fajn – usnadní to hledání a přehlednost. Ale volný text může být taky dobrý pro detailnější popisy. A k uživatelskému rozhraní – ideálně jednoduchý popis pro koncového uživatele, aby věděl, co se stalo a co má dělat dál. Pro pokročilé uživatele můžeš klidně přidat víc technických detailů. Méně je někdy více, ale vše záleží na cílové skupině.

162 slov
1.6 minut čtení
12. 9. 2024
Roman Hácha

Je dobrý mít vše, co se dá, když jde o chybová hlášení. Určitě by tam měly být ty základní věci jako typ chyby, místo v kódu, kde k tomu došlo, a nějaký unikátní ID pro snadnější sledování. Logy a kontext jsou fakt důležitý – bez toho se těžko zjišťuje, co se vlastně stalo.

Reprodukovatelnost je klíčová! Pokud nemáš jasně popsány kroky k vyvolání chyby, tak to může být dost frustrující. Formát bych doporučil strukturovaný, aby se v tom dalo rychle orientovat, ale zase ne zas moc komplikovaný.

Co se týče uživatelského rozhraní, tak pro koncový uživatele bych šel radši po jednoduchých hlášeních bez technických detailů. Ne každý má technický background, takže je lepší to udělat srozumitelné. Pro pokročilé uživatele můžeš mít možnost podívat se na podrobnosti, ale pro běžného smrtelníka stačí něco jako 'Něco se pokazilo, zkuste to znovu'.

Takže shrnuto: jasný popis chyby, kontext a logy jsou klíčové, formát by měl být přehledný a uživatelská hlášení spíš jednoduchá.

159 slov
1.6 minut čtení
12. 11. 2023
Robert Karásek

Když se bavíme o dokumentaci chybových hlášení, tak bych určitě řekl, že je fajn mít tam nějaký unikátní identifikátor pro každou chybu, aby se s tím dalo snadno pracovat. Důležitý je typ chyby a její umístění v kódu, to fakt pomůže při hledání. Také by tam měly být logy – ty dokážou hodně říct, co se stalo. K reprodukovatelnosti bych dodal, že je klíčové popsat kroky k vyvolání chyby, jinak se to těžko řeší. Co se týče formátu, strukturovaný záznam je lepší než volný text, aspoň se to dá snadno filtrovat a hledat. A pro uživatelské rozhraní – pro koncový uživatele bych šel spíš po jednoduchých hlášeních, technické detaily si zaslouží spíš pokročilí uživatelé. Takže shrnuto: unikátní ID, typ a místo chyby, logy, reprodukovatelnost a jasný popis kroků. To by mělo být v základu.

134 slov
1.3 minut čtení
14. 10. 2023
Adam Štěpánek
GraphQL.cz/Články/Error handling v GraphQL
Jak chybová hlášení ovlivňují klientské aplikace - nejlepší praktiky pro návrh APIObjevte, jak správně navrhnout API tak, aby chybová hlášení pomáhala klientským aplikacím efektivně reagovat na problémy a poskytovala uživatelům lepš...
1000 slov
10 minut čtení
26. 2. 2023
Barbora Němcová
Přečíst článek
Podobné otázky