Logowanie lepsze niż TODO oraz HACK

Gdy robię jakiegoś haka to wolę to opisać. Kiedyś wspomniałem o korzystaniu z TODO w Przesunięcie dobrych intencji na później.

Wymyśliłem dziś coś podobnego, traktujcie to jako „pomysł”, bo jeszcze nie wiem czy się sprawdza na dłuższą metę.

Zalogowanie pozostawionego problemu

Dzisiaj chciałem napisać, że czasem skorzystanie z TODO bywa za mało. Chodzi o projekty, w których nikt się takimi rzeczami nie przejmuje i generalnie nie planuje się czasu na refactoring (czy nawet poprawianie potencjalnych bugów). Wtedy trzeba dać jakoś mocniej znać, że coś nie zostało do końca zaimplementowane, lub został zrobiony „haczek”, potrzebny właśnie w tej konkretnej chwili. Takim miejscem jest logowanie błędów. Przykład:

Wykorzystanie TODO

// TODO HACK It was impossible to parse date here
// date = DateTime.Parse(value);
date = DateTime.Now;

Wykorzystanie logera (np. log4net)

_logger.Warn("It was impossible to parse date here. Method: Foo()");
// date = DateTime.Parse(value);
date = DateTime.Now;

Dzięki temu będzie coś w logach, opis może oczywiście być bardziej szczegółowy jeśli tego wymaga sytuacja. Gdy ktoś zacznie rozwiązywać jakiegoś niby niepowiązanego babola (Action at a distance), to może spojrzy w logi i coś mu one powiedzą.

Będzie się to logawać za każdym razem gdy wywoła się funkcja. Czy to nie za dużo?

W większości przypadków to pewnie za dużo, należy korzystać jeśli problem jest naprawdę ważny i dzięki temu wymusimy, że zostanie wkrótce poprawiony.

Idealnych rozwiązań brak

Ten sposób oczywiście można łatwo nadużyć traktując logi jako coś do czego wrzucamy kolejne rzeczy, zamiast rozwiązywać problemy. Wtedy logi będą puchły, staną się nieczytelne i przestaniemy zwracać na nie uwagę. Niestety – na nieporządek w kodzie nie ma idealnego lekarstwa.

spagetti code

Advertisements
Ten wpis został opublikowany w kategorii Programowanie i oznaczony tagami , , . Dodaj zakładkę do bezpośredniego odnośnika.