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 24 517×
Přečteno 22 960×
Přečteno 18 575×
Přečteno 17 531×
Přečteno 16 787×