Oryginalnie wpis miał się nazywać Log Driven Develompment ale okazało się, że już coś takiego istnieje, nie chce tu wchodzić w szczegóły, ale jak by co zapraszam pod link, gdyby kogoś to interesowało. Mój wpis będzie o moim pomyśle, który z powodzeniem stosuje od kliku lat w projektach. Nie pisałem wcześniej, bo chciałem być pewien, że będzie to dobrze działać i znam wszystkie za i przeciw. Mianowice o tworzenie kodu w oparciu o logi. Czyli zamiast debugowania, proponuje przestawić się na przeglądanie logów. Poniżej szczegóły i opis tego pomysłu.

Teoria – czyli o co chodzi

Każdy projekt ma jakiś swoje podejście do logowania tego co dzieje się w metodach, które wykonują się w kodzie. Może to być logowanie automatycznie, parametrów wejściowych i wyjściowych w metodzie, programowanie aspektowe, które również może załatwić nam problem logowania itd.

Jednak automatyczne logowanie nie załatwi czasem dobrej wizualizacji tego co się dzieje np: w dużym i skomplikowanym algorytmie lub kodzie.

Dodatkowo podczas pisania logów  w metodzie mogą zdarzyć się kwiatki, bo jak się logowanie pisze po napisaniu metody to potem logi w przypadku szukania błędów są dość „kosmicznie” –  informacje w logach okazują się dość mało przydatne.

Na to wszystko mamy taki pomysł:

Log Driven Development

Pisanie kodu wg tej teorii polega w tym na tym, że:

• Logujemy co istotniejsze kroki w metodzie.
• Zamiast do szukania błędów używać DEBUG-a (F5, F11 itd), najpierw sprawdzamy co jest w logach. Jeśli z logów nie możemy dowiedzieć się co i jak to dodajemy kolejne logi aż się dowiemy co i jak.

Dodatkowo wszystko robimy rozsądnie. Żeby nie przesadzić z tym dodawaniem logów aby się czegoś dowiedzieć i znów aby nie debugować linia po linij i analizować watche-cze. Nie logujemy całych list ale tylko te pozycje, które generują błąd itd. Często i dużo przeciążamy metodę ToString() aby w  kodzie i logach wyglądało ładnie. Staramy się pokazywać to co istotne.

Z logów powinien ujawnić się jeden flow danego procesu. Nie chodzi o to by w pliku ładnie wyglądało, tylko, aby dało się w łatwy sposób zobaczyć co się zdarzyło lub nie.

Bardzo mocno przywiązujemy uwagę do poziomów logowania. ERROR – ma być tylko wtedy,  gdy chcesz być obudzony w nocy z powodu jego wystąpienia.

Dzięki takiemu podejściu mamy załatwione 3 sprawy:

1. Metody mają dobrej jakości logi.
2. Mamy zrobione flow działania programu. Może go szybko prześledzić w logach.
3. Szukanie błędów powinno być tańsze, szybsze i mniej stresujące.

Minusy

Największy minus to „Single Responsibility Principle„. No cóż nie da się tego obejść w szybki sposób. To znaczy można. Jeśli mamy logowanie automatyczne, to używając odpowiednich wzorców projektowych możemy rozbić każdą metodę na pojedyncze klasy i mieć logowanie z głowy. To jest jak najbardziej ok. podejście i polecam to. Jednak w prawdziwym życiu nie zawsze jest czas na takie rzeczy, nie zawsze się da, oraz czasem napotykamy przerost formy nad treścią (czy każdego if-a będziemy zamieniać na wzorzec fabryka).

Kolejny minus to czytelność kodu. I z jednej strony kod jest czytelniejszy to będzie w plusach (opisze poniżej) a z drugiej strony robi się czasem brzydki kod w sensie czytelności. No zdarzają się takie momenty, że metoda za wiele nie robi a wiadomość do logowania jest dość długa i zawiła. No i wtedy nie wygląda to dobrze, przynajmniej trochę to przeszkadza. Mówię to wszystko  z doświadczenia. Pewnym pomysłem są regiony ale komu się chce to robić. Mam takie snippet, który wstawia region i między nie wstawiam logi. Potem wszystko zwija i wygląda ok. ale pracy więcej.

Plusy

No przede wszystkim szukanie błędów jest łatwiejsze dla mnie i dla innych. Może w logach takie historie jak „Robię to”, „Robię tamto” i „Nie robię tego, bo taki parametr jest 0” są przesadą ale w aplikacjach biznesowych, gdzie wymagania są płynne, dokumentacja jest nie aktualizowana a algorytmy są pisane przez 4 programistów, takie podejście zmniejsza czas ustalenia przyczyny błędu do minimum.

I to uważam z doświadczenia za jeden z największych plusów. Czas naprawy błędów spada drastycznie, no i szybciej się okazuje, że nie ma błędów w kodzie tylko takie były wymagania : )

Podsumowanie

Może ten post powinien być w kategorii o zarządzaniu projektem, bo koszty szukania błędów w sumie najbardziej obciążają firmę a nie samego dev-a. Może…jednak nie mówił bym o tym Wam gdybym sam tego nie próbował od kliku lat. Tak zdarzały się projekty, gdzie nie było to potrzebne, bo nie było błędów, bo aplikacja było prosta itd. Jednak mimo tego jak wejdę teraz do pliku logów (do jakieś aplikacji, którą dawno pisałem), to jak na dłoni widać flow i  szybko można się zorientować jak działa taka aplikacja.

Polecam przynajmniej przetestować : )