czwartek, 6 listopada 2008

Inspektor Gadget, czyli śledzenie aplikacji cz. I

Problem śledzenia działania aplikacji oraz eliminowania błędów jest tak stary jak stare jest programowanie. Pierwsze języki programowania nie posiadały rozbudowanych środowisk programistycznych oraz tak zaawansowanych technik śledzenia wykonywania kodu programu. Wraz z rozwojem samych języków, rozwoju ulegały także zintegrowane środowiska wytwarzania oprogramowania. Dziś chyba trudno sobie wyobrazić programowanie, a tym bardziej wyłapywanie błędów bez debugera.
Chciałbym przyjrzeć się w jaki sposób możemy najefektywniej śledzić działanie aplikacji oraz wychwytywać w nich błędy. Wszystko po to, aby nasze programy mogły działać jeszcze szybciej i bezbłędnie.

Podejście pierwsze – najprostsze
Chyba każdy z nas stosował lub nawet stosuje do dziś popularne wyświetlanie zawartości interesujących nas zmiennych na ekranie (konsoli). Popularna technika jest chyba najstarszą formą debugowania programów. Jej podstawową zaletą jest to, że bardzo łatwo ją zaimplementować oraz daje przejrzyste wyniki. Na tym chyba zalety się kończą. Wad jest sporo: kod służący do śledzenia kompilowany jest to programu wynikowego, trudno w nim śledzić bardziej zaawansowane powiązania z innymi zmiennymi itd.

Na szczęście takie podejście do problemu śledzenia aplikacji należy raczej do rzadkości, a metodologie dostępne dla każdego programisty dają znacznie lepsze rezultaty. Innym pewnym rozwinięciem przedstawionej wyżej techniki jest zapis stanu zmiennych do pliku tekstowego. To również popularna technika ze względu na łatwość zapisu do pliku w większości języków programowania. W dalszej części artykułu postaram się je przedstawić w jaki sposób za pomocą dostępnych narzędzi i bibliotek możemy podejść do problemu w bardziej zaawansowany sposób.

Biblioteki logowania
Czym są biblioteki programowania? Są to specjalizowane biblioteki stworzone po to aby programista nie musiał przejmować się samym sposobem wyświetlania, czy zapisu komunikatów diagnostycznych. Praca z nimi zazwyczaj sprowadza się do wywołania odpowiedniej metody, a biblioteka sama dba o odpowiedni przepływ komunikatów diagnostycznych. Należy w tym momencie nadmienić, iż powstał pewien podział na komunikaty diagnostyczne, które zostały oddzielone od komunikatów błędów. Często prowadzi to do innego (definiowanego przez programistę) zachowania się bibliotek logowania w przypadku wystąpienia błędu, a innego w momencie rejestracji informacji czysto diagnostycznych.
W Internecie istnieje wiele bardzo dobrych rozwiązań służących do tego celu. Najciekawsze z nich to:
1. log4net
2. NLog
3. Microsoft Enterprise Library Logging Application Block

Pierwsza z przedstawionych bibliotek jest portem doskonałej javowej biblioteki log4j. Posiada ona bogatą grupę projektów, które z jej rozwiązań korzystają oraz - co jest zaletą – jest dość dojrzałym i stabilnym projektem. Nie ma najmniejszych problemów z dostosowaniem przepływu raportowania, a lista celów naszych logów jest długa.
NLog został stworzony przez polskiego programistę: Jarosława Kowalewskiego . Zawiera wiele celi logowania oraz pozwala na bardzo szeroką konfigurację. Niestety projekt nie jest już tak dynamicznie rozwijany – w zasadzie można powiedzieć o jego wstrzymaniu, choć na oficjalnej stronie takich informacji nie znajdziemy. Nie zmienia to faktu, iż w obecnej formie projekt pozwala na wykonanie wszystkich popularnych operacji zarówno raportowania błędów jaki i informowania o stanie aplikacji.
W kolejnych częsciach artykułów będę starał się przedstawić jak z tych dobrodziejstw korzystać. Zapraszam do odwiedzania!
Nich kod będzie za Wami!

2 komentarze:

Bartek Szafko pisze...

serie artykułów są bardzo fajne - wiem to z własnego doświadczenia :)

temat zdecydowanie warty uwagi

Dariusz Tarczyński pisze...

Dzięki, mam zamiar przedstawić parę ciekawych sposobów podejścia do tematu. Mam nadzieję że się komuś przyda - bo sam blog młodziutki i publika nierozpoznana :-)