Sytuacja kobiet w IT w 2024 roku
7.06.20224 min
Igor Vlahek

Igor VlahekTechnical LeadHrvatski Telekom

7 zasad tworzenia efektywnych logów

Poznaj 7 zasad tworzenia efektywnych logów i spraw, aby Twój kod był o wiele bardziej przejrzysty.

7 zasad tworzenia efektywnych logów

Logi są niestety niedocenianą częścią developmentu. Zachowujemy się tak, jakby nasz kod był poprawny od samego początku, ale jest to niestety stwierdzenie dalekie od prawdy. Nasz kod jest podatny na błędy - a już, zwłaszcza gdy nadal jesteśmy w fazie developmentu. 

Nie logujemy tego, co powinniśmy albo w ogóle nie tworzymy logów. A nie robiąc tego, sprawiamy, że znajdowanie błędów jest cięższe i zabiera więcej czasu, co zmniejsza naszą produktywność. 

Mam dla Ciebie jedno proste rozwiązanie: musisz pisać sensowne logi, które zawierają odpowiednią ilość informacji. “Łatwo powiedzieć”, mógłbyś powiedzieć, ale jeszcze łatwiej zrobić. Oto 7 zasad, dzięki którym Twoje logi będą o wiele bardziej efektywne. 

1. Loguj ładowane parametry aplikacji w czasie jej uruchamiania

Aplikacje korzystają z plików zewnętrznych do zdefiniowania swojego zachowania. Zawsze powinno się logować załadowane właściwości danej aplikacji, gdy już ją uruchamiamy. 

Dlaczego? Jest to częsty błąd popełniany podczas instalacji aplikacji w nowym środowisku. Rzadko się to udaje za pierwszym razem. Chcemy wiedzieć, które właściwości zostały załadowane, aby mieć pewność, że podczas uruchamiania mamy te właściwe. Nie chcemy uruchamiać aplikacji, a potem czekać, aż ktoś ostrzeże nas, że nie działa ona tak, jak się tego spodziewaliśmy ze względu na obecność nieprawidłowych wartości niektórych właściwości.  

Zaloguj je od razu i sprawdź, czy właściwości są prawidłowe, w momencie, w którym uruchamiasz aplikację.

Poziom logowania - INFO

2. Loguj konfigurację klienta podczas uruchamiania aplikacji

Poprzednio logowaliśmy załadowane parametry aplikacji. Nie logowaliśmy jednak właściwych parametrów, których używa się do tworzenia klientów. Zaloguj je podczas uruchamiania aplikacji, aby przekazać informacje o tym, jakich właściwie parametrów używamy. 

Dlaczego? Mamy sytuacje, w których umieszczamy odpowiednią wartość właściwości w pliku, ale nie korzystamy z odpowiednich parametrów do tworzenia klienta. Chcemy wiedzieć, którego adresu URL użyjemy i dla jakiegoś klienta w aplikacji. Nie chcemy zaczynać testu ze złym adresem URL. Musimy o tym wiedzieć jak najszybciej - a więc uruchamianie aplikacji jest tutaj odpowiednim momentem.

Poziom logowania - INFO

3. Loguj przychodzące wywołania żądanych metod i argumenty metod dla otwartego API

Większość naszych aplikacji odkrywa jakieś API lub wyzwala jakąś akcję. Zaloguj nazwę tej metody i jej argumenty dla każdej odkrytej metody. Loguj też każde wywołanie API. 

Dlaczego? Jeśli mamy problem w komunikacji między dwoma serwisami, to Ty, czyli obiekt wywoływany, będziesz chciał się dowiedzieć następujących rzeczy: 

  • Jakie API wywołano
  • Jakie parametry przekazano


Takie informacje wraz ze stanem bazy danych są kluczowe dla procesu rezolucji błędów. Stan bazy danych jest niezmienny, więc dostęp do niej jest dowolny - wywołania metody już takie nie są, o ile nie ustalisz niezmienności w logach. Umieść odpowiednie informacje w logach już na początku, aby zminimalizować czas, który jest potrzebny na uporanie się z jakimś problemem. 

Poziom logów - INFO (debuguj, jeśli argumenty metod są fat)

4. Loguj żądanie wychodzące do zewnętrznych systemów

Podobnie jak w przypadku poprzedniej rady, loguj wywołany adres URL z odpowiednim żądaniem dla każdego wywołania wysyłanego do systemu zewnętrznego. 

Dlaczego? Jeśli zachodzi problem w komunikacji między dwoma serwisami, to wywoływany obiekt zapyta o następujące rzeczy: 

  • Docelowy URL/temat 
  • Wysłane argumenty metod.


Pierwszą rzeczą, jaką obiekt wywoływany zrobi, będzie szukanie logów, aby sprawdzić, co właściwie zostało wywołane, jeśli coś nie pasuje między wysłanymi i otrzymanymi parametrami. Umieść te informacje w logach już na początku, aby zminimalizować czas potrzebny do naprawienia błędu. 

Poziom logów: 

  • INFO - w przypadku wywoływanego URL
  • DEBUG - dla żądania i odpowiedzi

5. Logika aplikacji obecna w kodzie powinna być łatwa do odnalezienia w logach 

Komentarzy w kodzie należy unikać, jeśli to tylko możliwe. Zamiast tego należałoby umieścić w nim logi i to w takich miejscach, w których normalnie znalazłyby się komentarze. W taki sposób wyjaśnisz innym swoje intencje, jeśli kod nie komunikuje ich wystarczająco jasno. 

Dlaczego? Bo powinno być tak, że np. tester zrozumie logikę aplikacji, jedynie patrząc na logi. W większości przypadków będą oni w stanie zidentyfikować błąd patrząc właśnie jedynie na wynik logów - zakładając oczywiście, że logi są dobre i wystarczające. 

Poziom logów - INFO albo DEBUG, w zależności od poziomu informacji, które podano

6. Loguj kluczowe ścieżki swojego kodu 

Ścieżki logów są zabierane przez Twoją aplikację, jeśli masz tam wiele ścieżek w wywołaniu API. Zaloguj każdą zabraną ścieżkę, uwzględniając to, dlaczego ją zabrano i logując też parametry, które sprawiły, że ją wybrałeś.  

Dlaczego? Gdy aplikacja zachowuje się w nieoczekiwany sposób, to musisz mieć wszystkie potrzebne informacje, aby znaleźć miejsce, w którym Twoja logika zeszła na złą drogę. 

Poziom logów - INFO albo DEBUG, w zależności od poziomu dostarczonych informacji 

7. Loguj ślad stosu wszystkich wyjątków 

Loguj ślad stosu wszystkich wyjątków. Nie umieszczaj w logach jedynie błędów. Dlaczego? Ponieważ wyjątki w kodzie nie powinny się zdarzać. 

Gdy widzisz coś takiego, to chcesz się dowiedzieć, co się właściwie popsuło. Stosując się do tej zasady, będziesz znać dokładną linijkę kodu, w której coś poszło nie tak. 

Upewnij się, że zalogowałeś cały ślad stosu. Pamiętaj, że jeśli chodzi o wyjątki, to każda informacja się przyda. 

Poziom logów - ERROR

Podsumowanie

Temat logów jest szeroki i można tutaj jeszcze wiele napisać - jeśli jednak będziesz trzymać się wszystkich zasad, to zrobisz spory krok do przodu i staniesz się lepszym developerem. 

Dziękuję za uwagę!


Oryginał tekstu w języku angielskim możesz przeczytać tutaj

<p>Loading...</p>