Komentáře k článku

Nešvary logování

Co se týká softwarového vývoje, logování je jedna z nejvíce zanedbávaných oblastí. Samozřejmě, pokud nejde o něco naprosto amatérského, tak je logování v každé aplikaci. Stejně tak, aby člověk pohledal vývojáře, který si během programování nevypisuje na konzoli potřebné runtime informace.

Zpět na článek

11 komentářů k článku Nešvary logování:

  1. balki

    Moj oblubeny nesvar je zabudnut po sebe vycistit debug logy typy „moje_priezvisko tralalala iteracia: 50 nastalo toto a toto.“

    Alebo nezalogovat exception z threadu v multithreadovej aplikacii. Potom mozem dohladavat, ze co sa vlastne pokazilo ….

    1. Vít KotačkaAutor příspěvku

      Re:
      Seriál neplánuju – článků, jak správně logovat je na internetu dost. Jak jsem psal v úvodu, je to shrnutí dlouholetého pocitu/zkušenosti. A třeba negativní příklad zapůsobí taky pozitivně.

  2. ivoszz

    S většinou ze zde tepaných nešvarů nelze nesouhlasit, ale autor zde prokazuje, jak je zarostlý do Java prostředí a jde i proti některým moderním trendům (12 factor apps).

    1. Vít KotačkaAutor příspěvku

      Re:
      Asi úplně nechápu smysl tohoto komentáře. Pro chyby v logování je použitý jazyk zcela irelevantní. Dané chyby lidi (vývojáři) prostě dělají. (Mmch. autor neprokazuje vůbec nic.)

      Jak souvisí uvedené nešvary s The Twelve-Factor App? Že by další silver bullet? Já bych řekl, že se buď míjí, nebo nejsou v rozporu – např. technical leader (či libovolná zodpovědná osoba) nastaví, že se bude vyvíjet podle 12-Fac App a bude sledovat (zméněné code review) dodržování. Nicméně rád se poučím z konstruktivního komentáře.

      1. Oldis

        Re:
        je otazkou jde-li o chyby, za chybu povazuju kdyz neco nefunguje nebo to rovnou spadne, ale formatovani logu a podobne je spis šlendrian nez chyba.

        1. Vít KotačkaAutor příspěvku

          Re:
          To je otázka, jak si definujeme chybu. Např. requirement, že request musí být sledovatelný přes všechny komponenty, a jeho nedodržení je chyba. Totéž bez requirementu může být „jen“ šlendrián, ale může to stát velkou spoustu peněz.

          Navíc chyba není jen, že něco spadne. Pokud bude něco špatně fungovat (= business logika), ať skrytě, či explicitně a nebudu mít nástroje (třeba logovaní), abych to napravil, bude to problém. Může to být problém minoritní, a může být pekelně drahý.

          1. Oldis

            Re:
            ano, ale vývojáři jsou dost citliví na slovíčka a proto místo bug či wrong jim radši řeknu že je to imperfect nebo imcomplete.

            1. emik

              Re:
              Poslanci, když něco udělají blbě, říkají, že došlo k diskrepanci.
              Zní to dobře, ne?
              A sdělovací prostředky a zainteresovaní (potrefení) už měsíc dopředu rovnou říkají, že je to blbě. Pak se to schválí.

        2. Vít KotačkaAutor příspěvku

          Re:
          Formátování logu může být otravné, ale dá se řešit. Chybějí (runtime) informace v logu můžou být kritické.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=20929