مقالات باگتو

 بهترین روش های Logining
بهترین روش های Logining

ترجمه ی فارسی کلمه ی log ” ثبت وقایع” است. با استفاده از log اطلاعاتی را که هنگام بروز مشکل در برنامه بتوان برای رفع ایراد از آنها کمک گرفت، ثبت کنیم. تفاوت نوشتن log برای یک برنامه و ننوشتن آن را می توان با مثال صرف زمان 5 دقیقه برای رفع یک ایراد یا زمان 5 ساعتی برای آن توصیف کرد.البته باید به این هم توجه کنید، این که شما برای یک برنامه log بنویسید لزوما به این معنی نیست که شما می توانید سریعا به مشکل رخ داده برسید، این موضوع به مهارت شما در نوشتن log از روال اجرای برنامه نیز بر می گردد . 

نکاتی که نباید در مورد Log فراموش شود :

  1. موضوع اولی که باید مورد بررسی قرار گیرد نحوه ی نوشتن log است. log باید به صورتی نوشته شود که هر کس دیگری غیر از شما هم آن را بخواند متوجه شود. به یاد داشته باشید همیشه شما نیستید که فایل log را میخوانید، خواننده ی فایل می تواند همکار شما یا حتی فردی در شرکت طرف قرار داد شما باشد.
  2. از نوشتن اطلاعات مهم و امنیتی مربوط به کاربران برنامه یا خود برنامه در فایل log تا آنجا که ممکن است پرهیز کنید.
  3. موضوع بعدی مدیریت اندازه ی فایل های ذخیره سازی log هاست. اگر اندازه این فایل ها بزرگ باشد و متن زیادی در آن نوشته شده باشد بررسی کردن آن ها دشوار است. بهتر است تنظیماتی انجام دهیم که اطلاعات مربوط به هر بازه ی زمانی مشخص در فایل جداگانه ذخیره شود. به طور مثال اطلاعات هر هفته یا هر روز در یک فایل جدا ذخیره شود.
  4. زیاد ننویسیم کم هم ننویسیم. نوشتن بیش از اندازه ی اطلاعات در log کار را سخت می کند

 

لاگ‌ها بخش مهمی از هر نرم‌افزار هستند. در این مقاله در  مورد اینکهچگونه می‌توان لاگ را تأمل‌برانگیزتر کرد و درباره مواردی که باید در نظر داشته باشید و همچنین مواردی که هنگامLOGباید از آنها اجتناب کنید، صحبت می‌شود.

من مطمئن هستم که هر مهندس نرم‌افزاری در شرایطی غیرمنتظره قرار گرفته است که نتواند بفهمد در کد چه می‌گذرد؟ گاهی اوقات یک عبارت Insightful logمی‌تواند برای پاسخ به این شرایط غیرمنتظره مفید باشد. اجازه دهید به چند مورد بپردازیم که شخصاً آنها را پذیرفته‌ام و معتقدم که به‌اندازه کافی مناسب هستند تا دیگران بتوانند برایloggingمؤثر و قابل درک از آنها پیروی کنند.

توجه: هنگام نوشتن این مقاله، کتابخانهlog4j  در نظر گرفته شده است.

برخی از سطوح مورداستفاده رایج لاگ:FATAL،ERROR،WARN،INFO،DEBUG،TRACE.

تفسیر ساده پیام‌های log levelsرایج:

  • FATAL: نشان‌دهنده رخداد یک اشتباه جدی است که باید فوراً بررسی شود و راه حلی برای ازبین‌بردن آن پیدا کرد.
  • ERROR:نشان‌دهنده یک اشتباه در روند برنامه است باید بررسی و برطرف شود.
  • WARN:پیام‌هایی که برای پیگیری کردن رفتارهای خارج از انتظار برنامه است و به ما می‌گویداین روند ممکن است ادامه یابد، اما احتیاط بیشتری کنید.
  • INFO:حاوی پیام‌های اطلاعاتی پیرامون برنامه و عملکرد آن (مثلروند تجاری مهم که تغییر حالت داده یا به پایان رسیده) است.باید توانایی درک پیام‌هایINFOرا داشته باشیم و به‌سرعت بفهمیم برنامه در حال انجام چه کاری است (این پیام‌ها برای کنترل روال اجرای برنامه است).
  • DEBUG: نکات و اطلاعات راهنمای توسعه‌دهنده در پیداکردن باگ‌ها و رفع آنها
  • TRACE:اطلاعات بسیار دقیق و در سطح ریزتری، فقط برای توسعه در نظر گرفته شده است. به‌طورکلی، این برای موارد موقتی است

 

مواردی که باید در نظر داشته باشید

  • مدل‌های داده با متدtoString ()داشته باشید، این کاربرایقراردادن داده‌های مهم در گزارش مفید خواهد بود.Gson  همچنین برای ایجادJSONبرای شیء شما (ترجیحاً مدل‌های کوچک‌تر داده) وجود دارد.
  • هر عبارتloggingباید شامل داده‌ها و توضیحات باشد.
  • استدلال‌های متدlogو مقادیر برگشتی به‌عنوان DEBUG log کهبه‌عنوان یک دیباگر در چرخه توسعه کار می‌کند و همچنین برای اهداف تحقیق مفید است.
  • هنگام فراخوانی سرویس‌هایAPIخارجی، مطمئن شوید که همه چیز ثبت شده است. این کار به شناسایی مسائل جانبی کمک می‌کند، آیا ما در فراخوانی آن اشتباه کرده‌ایم یا پردازشAPIاشتباه کرده است؟
  • مطمئن شوید که یکexceptionدو دفعهlogنشده است. این کار منجر به درک نادرست خطا می‌شود.
  • Logها باید برای خواندن آسان باشند
  • ازlog context برای ردیابی بهتر یک ریکوست استفاده کنید.

مواردی که باید از آنها اجتناب کرد

  • ازlog.isDebugEnabled ()برای لاگ‌های مستقیم خودداری کنید. از این موارد فقط در مواردی که برایlogging نیاز به محاسبه است استفاده کنید.
  • از ترکیبStringبا +استفاده نکنید، از جایگزین {} استفاده کنید.
  • ازobj.getAttribute ()بدون اطمینان از اینکهobjخالی است یا خیر استفاده نکنید چون ممکن است منجر بهNPEشود.
  • از پرینت بیش از حد اشیاء خودداری کنید. مثال: فهرست <Object> نباید در یک گزارش واحد چاپ شود. بهتر است لیستی ازobjectIDتهیه کرده و آن را وارد کنید.
  • log PIIداده‌ها را انجام ندهید.خیلی مهم است که هیچ اطلاعات شخصی وارد سیستم نشود. چون ممکن است باعث نقضGDPRشود.
  • پسوردها وSecret Keysرا لاگ نکنید. اطلاعات محرمانه، نباید لاگ شود.

لاگ‌ها باید به مهندسان نرم‌افزار کمک کند تا دریابند که کجا، چه چیزی و چرا مشکلی پیش‌آمده است. اگر توسعه‌دهنده بتواند مشکلات را فقط از طریق لاگ‌ها پیدا کند،loggingخوب است.


تگ‌ها
اشتراک

0 نظرات


;