2010-08-09 8 views
5

हाल की घटनाओं के कारण, मैं यह पता लगाने की कोशिश कर रहा हूं कि मुझे सामान्य रूप से कोड के लिए कितना डिबगिंग लॉग उपयोग करना चाहिए।सामान्य डीबगिंग लॉग प्रथाओं

मैं जो कर रहा हूं वह डीबगिंग लॉग का बहुत कम उपयोग कर रहा है, और केवल उन मामलों में जहां मुझे कुछ अतिरिक्त जानकारी चाहिए या आप क्या चाहते हैं। यह मुझे समझ में आया, जैसा कि ऐसा लगता है कि आपको अपने कोड की हर छोटी चीज़ को लॉग नहीं करना चाहिए, क्योंकि इससे आपको इतनी सारी जानकारी मिल सकती है कि वास्तव में कुछ महत्वपूर्ण याद करना आसान होगा (या खोदने से पागल हो जाना लॉग के माध्यम से और सत्यापन)।

दूसरी तरफ, मैं एक उदाहरण प्रस्तुत करता हूं: मैंने अपने जावा प्रोजेक्ट के लिए लॉगबैक/एसएलएफ 4j का उपयोग शुरू किया है, और यह जांचने के लिए कि मेरे पास .xlm फ़ाइल सही तरीके से स्थापित है, मैंने एक डीबगिंग लॉग स्टेटमेंट को अंत में जोड़ा विधि जो गुई घटकों को शुरू करती है। आम तौर पर मैंने कभी लॉग बयान नहीं दिया होगा, क्योंकि यह बहुत स्पष्ट है कि यदि आप प्रोग्राम चलाते हैं तो आपके गुई घटक सही तरीके से प्रारंभ नहीं होते हैं। हालांकि इस बार मैंने कार्यक्रम चलाया, और कम और देखा कि लॉग दिखाते हैं कि गुई घटकों को दो बार शुरू किया जा रहा था, भले ही उनमें से केवल एक सेट प्रदर्शित किया जा रहा था। एक सभ्य आकार की बग, लेकिन कुछ ऐसा जो संभवतः उन डिबगिंग स्टेटमेंट के बिना पकड़ा नहीं होता।

तो मेरा प्रश्न: क्या डीबगिंग लॉग की बात आती है जब वहां कोई "सर्वोत्तम प्रथाएं" होती है? सूचना लॉग, अपवाद, त्रुटियों इत्यादि की बात आती है, लेकिन मैंने डीबगिंग लॉग के संबंध में बहुत कुछ नहीं पाया है, लेकिन मैंने कई बेहतरीन अभ्यास प्रश्न देखे हैं।

धन्यवाद :)

+0

बड़े लॉग के माध्यम से पढ़ना है एक आवश्यक बुराई जिसके लिए उपयोग करने की आवश्यकता है। नौकरी के साथ आता है। :) – euphoria83

+0

@ euohoria83 - ब्लीच! मानसिक रूप से खुद को तैयार करने के लिए समय लगता है: पी – vimalloc

उत्तर

3

कुछ विचार:

  1. सिर्फ लॉग न करें क्या हो रहा है, लेकिन उपलब्ध मानकों/विधि तर्क आदि यह इस आसानी से नज़रअंदाज़ लॉग इन करने के ख्याल रखना।
  2. तथ्य के बाद लॉग इन करने के बजाय कॉन्फ़िगरेशन के माध्यम से डीबग लॉगिंग को अक्षम करना आसान है।
  3. जब तक यह वास्तव में कोई मुद्दा नहीं बन जाता है तब तक ओवरहेड लॉगिंग के बारे में चिंता न करें।
  4. आप एक AOP फ्रेमवर्क (स्प्रिंग/AspectJ आदि)
+0

हाँ, यह ओवरहेड/डिसबैबलिंग विशिष्ट लॉग नहीं है जिसके बारे में मुझे चिंता है, जैसा आपने कहा था कि करना बहुत आसान है। यह और अधिक है कि मैं इन लॉग स्टेटमेंट्स के साथ अपने कोड को कितना अव्यवस्थित करता हूं। उदाहरण के लिए, जब भी किसी विधि को बुलाया जाता है, तो मुझे लॉग इन करना चाहिए, बस कुछ विधियों को कहने पर, कन्स्ट्रक्टर इत्यादि? जब मैं एक दिया गया चर बदलता हूं (जो प्रोग्राम को क्रैश करने में सक्षम नहीं होगा), क्या मुझे यह बीमा करने के लिए लॉग इन करना चाहिए कि इसकी अपेक्षित मूल्य है? मुझे लगता है कि आपका पहला बिंदु सॉर्टा इसे बताता है, लेकिन मैं बस इसके चारों ओर अपने सिर को लपेटने की कोशिश कर रहा हूं। – vimalloc

+0

जब भी कोई विधि कहलाती है, तो अलग लॉग स्तर बनाने के बारे में क्या? इस तरह आप सभी लॉगिंग स्टेटमेंट्स को जगह में डाल सकते हैं, लेकिन आउटपुट को आवश्यकतानुसार चालू और बंद कर सकते हैं। लेकिन मुख्य रूप से कोड कोड बदलते समय लॉग इन करना एक अच्छा विचार है, जैसे "if" कथन में। –

1

मैं तय करने में नहीं लगता कि किसी भी "सर्वोत्तम प्रथाओं" देखते हैं का उपयोग करके कुछ लॉगिंग (तरीकों के प्रवेश/निकास) स्वचालित कर सकते हैं क्या/कैसे लॉग करने के लिए बहुत कुछ। यह उन 22-पकड़ स्थितियों में से एक है। यदि आपको लॉग देखने की ज़रूरत है, तो वहां "पर्याप्त" पर्याप्त जानकारी नहीं है, लेकिन यदि आप नहीं करते हैं तो "सब" लॉगिंग सिर्फ कोड अव्यवस्था है और एक अनावश्यक रनटाइम ओवरहेड है। आपको प्रत्येक आवेदन के लिए रेखा को आकर्षित करने के बारे में एक अलग निर्णय लेने की आवश्यकता है।

हालांकि एक बिंदु को ध्यान में रखना है। यदि आप और आपके ग्राहक अस्थायी डीबगिंग कथन जोड़ने के लिए कोड को हैक करने में सक्षम हैं, तो आपको जगह पर जितना स्थायी लॉगिंग कोड की आवश्यकता नहीं है। लेकिन अगर आपके पास चीजों को डीबग करने के लिए (लगभग) उत्पादन कोड पर हैकिंग का विकल्प नहीं है, तो आप को लॉगिंग कोड के एक निश्चित स्तर की आवश्यकता है, बस मामले में ...

संबंधित मुद्दे