Poslední dobou si dokonce pohrávám s myšlenkou, že do designu aplikace patří i dobrá debugovatelnost a testovatelnost možná víc, než samotný účel (ten vetšinou zvládne na pár řádcích každý). Já vím, nic nového pod sluncem, ale jenom málokdo tak píše kód.
Rok jsem tlačil v práci, aby jsme přešli od logování "on error only", protože některé podezřelé věci prostě error nejsou a krčit pak zpětně rameny, protože se nemohu podívat např. že komponenta nebo API nevrátila nějaký seznam, přestože měla, zatímco prázdné pole je jeden z validních výsledků, to mi nikdy nešlo pod fousy ...
Teda, logování jenom errorů si v praxi nedokážu vůbec představit. Naše aplikace produkuje za den gigabajty logů (které se sypou do Elastic Searche, odkud se po delší době zahazují). Samozřejmě po většinu času na to nikdo nekouká, ale když se něco stane (nebo když má klient podezření, že se něco stalo), tak jsme z logů schopní zjistit hrozně moc.
No, já si to taky nedokázal před tím představit. Vlastně jsem ani nevěděl, že taková "strategie" existuje. Pak "nás" to vypeklo a už radši logujeme všechno.
Ono je to často dobré i pro to, že si třeba člověk udělá obrázek o tom, co "havárii" předcházelo. Někdy k nezaplacení. Nebo že uživatel zkouší něco udělat vícekrát, přestože tvrdí opak, etc. ...
pracuje na pozici IT architekta. Poslední roky se zaměřuje na integrační a komunikační projekty ve zdravotnictví. Mezi jeho koníčky patří také paragliding a jízda na horském kole.
Přečteno 22 290×
Přečteno 21 796×
Přečteno 17 411×
Přečteno 16 606×
Přečteno 15 642×