26

Nov

Modernne tarkvara loomine VII: Logimine või blogimine?

Marek Tihkan 4 kommentaari

Küllaltki tüüpiliseks peetakse rakenduse vigade logimist. Proovitakse kasutada Aspect Oriented Programmingu võtteid, et saavutada see võimalikult lihtsalt, kuid siiski kui palju on kasu logist, mis kõik vead kirja paneb?

Paljudel kordadel kui vea kirja paneme, on rakendame ka mehhanisme, et olukorda taastada kasutaja jaoks. Seetõttu ei tohiks meid väga huvitada need veateated. Ise pole sattunud väga logisid lugema, võib-olla on see algaja õnn vms. Põhimõtteliselt peaksime kirja panema need juhtumid, mida me ei oota, mitte need, mis on vuugitäiteks. Näiteks kui proovime minna lehele ASP.NET MVC rakenduses, mille kontrollerit ei leita, siis võime saada küllaltki tüüpilise vea. Kas kellegi viga viitamisel peaks tootma meie logi? Arvatavasti oleks piisavalt kena näidata kasutajale kurba sõnumit, et seda lehte pole ja lõpetada sellega.

Teine probleem vigade logimisel on see, et need on juba tekkinud ning me ei teinud midagi selleks, et neid ennetada. Huvitav kontseptsioon oleks panna rakendus blogima. Selle realiseerimiseks tuleks valmistada rakendusele vastav diagnostika. Näiteks iga tunni aja tagant proovib kõik vajalikud ühendused üle ning mõne puudumisel annab teada ilusasti ajaveebi kandena (ühenduse puudumine ei tähenda, et rakendus peaks koheselt käpuli olema, vaid kogub lokaalselt tegevusi ja näitab kasutajatele infot cachest). Kui seda veidi lihtsamaks teha, siis see võiks ka siutsuda ehk luua Twitteri anloog.

Praegu näen kahte lähenemisviisi: logida etteaimamatud vead või üritada diagnoosida, millised probleemid võiksid tekkida ja teavitada seda eelnevalt. Viimase puhul pole veel mingit üldist lahendust näinud, kuid see võib olla koht, kus saab enda ideedel voolata lasta. Esimese puhul saab kenasti kasutada ära raamistikke, mida leidub hulgaliselt Log4Net, NLog, Log4J, Log4R. Ega selle kohta väga midagi rääkida polegi, sest tegemist oleks peamiselt ühe klassiga, millel on paar meetodit.

Kohati tundub, et logimisel polegi eriti mõtet. Näiteks NHibernate võib kirjutada tapeedirullegi täis, kuid reaalset kasu sellest pole. Pigem enne rakenduse avalikkuseni viimist tasuks käia näiteks NHProfileriga üle ja parandada vead. Kui suuremaid probleeme peaks tekkima rakenduse töötamisel, siis võib tekkida tunne, et päringuid eelnevalt ei testitud.

Seega olen seisukohal, et logimine on millegi tegemata jätmine: keskkonna eelduste kontrollimine, testimine, vigade töötlemine vms. Kui keegi leiab häid vastuargumente, siis olen avatud kuulama neid.

Loe veel sarnastel teemadel:

  • Share/Bookmark

KATEGOORIAD » Analüüs/Arhitektuur

SILDID »

4 kommentaari

1

Halvasti kirjutatud logimisest ei ole nii või naa kasu, sest tapeedirullitäitest logidest miskit vajalikku üles leida on ka omaette kunst. Ehk seega kõike ei ole mõtet, vaid me enam-vähem ikka teame, kus võib viga tekkida ning paneme sinna logimise juurde. Ja siit tulles sinu mõtte juurde, et kui me niikuinii teame, millest võib viga tekkida või mis on need kriitilised kohad, siis miks mitte neid juba aegsasti kontrollida ja kuhugi teada anda.

Aga samas võib ootamatuid olukordi alati tekkida. Sellisel juhul ma leian, et logmisest palju efektiivsem oleks see, kui koguda kokku kõik vajalik info vea kohta, mille abil ideaalis peaks saama vea taastekitada ning edastada see vastavatele isikutele/süsteemidele edasi. Kui ma ei eksi, siis Ayende on seda lahendust edukalt kasutanud NHProfi juures.

Siim
10:29, 26. november

2

Kas see lahendus on eraldiseisev ning on võimalik lisada juurde enda süsteemidesse või tuleb veel igal ühel endal sellega tegeleda?

Marek Tihkan
12:17, 27. november

3

“Kas kellegi viga viitamisel peaks tootma meie logi? Arvatavasti oleks piisavalt kena näidata kasutajale kurba sõnumit, et seda lehte pole ja lõpetada sellega.”

ma arvan et lausa REEGLINA on vigase viitamise süü saidiomanikul endal, mitte viitajal. see tuleneb sellest et sinu saidil on kunagi muiste antud viide töötanud. ja sel juhul ongi ainuke mõistlik lahendus logimine, et saaks külastajad edaspidi suunata sinna, kuhu nad minna soovisid.

ap
14:01, 29. november

4

Minuteada mingit valmis tükki sellisest lahendusest ei ole, aga ma ei ole selle teema koha pealt uurinud ka väga palju.

Siim
12:33, 30. november

Lisa kommentaar

  • * Kuvatakse kommentaari juures
  • * Ei publitseerita