विशेष मामलों और हेरिस्टिक्स का प्रबंधन कैसे करें

Question

मेरे पास अक्सर एक विशिष्ट अच्छी तरह से परिभाषित एल्गोरिदम के आधार पर कोड होता है। यह अच्छी तरह से टिप्पणी करता है और उचित लगता है। अधिकांश डेटा सेट के लिए, एल्गोरिदम महान काम करता है।

लेकिन फिर किनारे के मामलों, विशेष मामलों, हेरिस्टिक को डेटा के विशेष सेट के साथ विशेष समस्याओं को हल करने के लिए जोड़ा जाता है। जैसे-जैसे विशेष मामलों में वृद्धि होती है, टिप्पणियां अधिक से अधिक आलसी होती हैं। मुझे वापस जाने और एक साल में इस कोड को देखने का डर है और याद रखने की कोशिश कर रहा है कि क्यों प्रत्येक विशेष विशेष मामला या ह्युरिस्टिक जोड़ा गया था।

मैं कभी-कभी चाहता हूं कि स्रोत कोड में ग्राफिक्स को एम्बेड या लिंक करने का कोई तरीका था, इसलिए मैं प्रभावी ढंग से कह सकता हूं, "इस डेटा सेट के आलेख में, यह विशेष विशेषता दिनचर्या को गलत तरीके से ट्रिगर कर रही थी, इसलिए कोड का यह टुकड़ा क्यों जोड़ा गया "।

इस तरह की स्थितियों को संभालने के लिए कुछ सर्वोत्तम अभ्यास क्या हैं?

इन असामान्य/किनारे के मामलों को संभालने के लिए विशेष मामलों की हमेशा आवश्यकता होती है। कोड को अपेक्षाकृत पठनीय और समझने योग्य रखने में उन्हें कैसे प्रबंधित किया जा सकता है?

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

इस तरह के मामलों में, क्या लोग संदर्भ के लिए स्रोत पेड़ में डेटा फ़ाइलों को जोड़ते हैं?

Answer 1

यदि आपके पास प्रोजेक्ट के लिए ज्ञान आधार या विकी है, तो आप इसमें ग्राफ जोड़ सकते हैं, Matthew's Fowler quot ई के अनुसार विधि में लिंक कर सकते हैं और एज केस परिवर्तन के लिए स्रोत नियंत्रण प्रतिबद्ध संदेश में भी जोड़ सकते हैं।

//See description at KB#2312 
private object SolveXAndYEdgeCase(object param) 
{ 
    //modify param to solve for edge case 
    return param; 
} 

Commit Message: Solution for X and Y edge case, see description at KB#2312 

यह अधिक काम है, लेकिन परीक्षण मामलों या टिप्पणियों की तुलना में मामलों को अधिक अच्छी तरह से दस्तावेज करने का एक तरीका हो सकता है। भले ही कोई तर्क दे सकता है कि परीक्षण के मामलों में पर्याप्त दस्तावेज होना चाहिए, उदाहरण के लिए, आप पूरे असफल डेटा सेट को स्टोर नहीं करना चाहते हैं।

याद रखें, अस्पष्ट समस्याएं अस्पष्ट समाधान की ओर ले जाती हैं।

Answer 2

आपकी समस्या की विशिष्ट प्रकृति को जानने के बिना उत्तर देना आसान नहीं है, लेकिन मेरे अपने अनुभव में, हार्ड कोड पर विशेष मामलों को संभालने से बचा जाना चाहिए। क्या आपने अपने मुख्य प्रोसेसिंग एल्गोरिदम के बाहर विशेष मामलों को संभालने के लिए नियम इंजन या ऐसा कुछ लागू करने के बारे में सोचा नहीं है?

Answer 3

मार्टिन फाउलर ने अपनी रिफैक्टरिंग पुस्तक में कहा कि जब आपको अपने कोड पर कोई टिप्पणी जोड़ने की आवश्यकता महसूस होती है, तो पहले देखें कि क्या आप उस कोड को विधि में समाहित कर सकते हैं और विधि को एक नाम दे सकते हैं जो टिप्पणी को प्रतिस्थापित करेगा।

इसलिए एक सार के रूप में आप नाम की एक विधि बना सकते हैं।

private bool ConditionXAndYHaveOccurred(object param) 
{ 
    // code to check for conditions x and y 
    return result; 
} 

private object ApplySolutionForEdgeCaseWhenXAndYHappen(object param) 
{ 
    //modify param to solve for edge case 
    return param; 
} 

तो फिर तुम जैसे

if(ConditionXAndYHaveOccurred(myObject)) 
{ 
    myObject = ApplySolutionForEdgeCaseWhenXAndYHappen(myObject); 
} 

नहीं एक कठिन और तेजी से ठोस उदाहरण कोड लिख सकते हैं, लेकिन यह एक या दो साल में पठनीयता के साथ मदद मिलेगी।

Answer 4

यूनिट परीक्षण यहां सहायता कर सकता है। परीक्षण जो वास्तव में विशेष मामलों का अनुकरण करते हैं, प्रायः दस्तावेज के रूप में कार्य कर सकते हैं कि कोड ऐसा करता है कि कोड क्या करता है। यह अक्सर टिप्पणी में समस्या का वर्णन करने के बाद बेहतर हो सकता है।

ऐसा नहीं है कि इस विशेष मामले के लिए अपने स्वयं के कार्य करता है और सभ्य टिप्पणी करने के लिए से निपटने चलती बदल देता है ...

Answer 5

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

उनमें से टिप्पणियों के साथ कुछ अच्छे यूनिट परीक्षण स्वयं विशेष मामलों का सबसे अच्छा विवरण हैं। और कोड की टिप्पणी भी आसान हो जाती है। कोई बस कुछ यूनिट परीक्षणों को इंगित कर सकता है जो कोड में उस बिंदु पर हल की जा रही समस्या को चित्रित करते हैं।

Answer 6

ऐसा लगता है कि आपको कोड टिप्पणियों की तुलना में अधिक संपूर्ण दस्तावेज़ीकरण की आवश्यकता है। इस तरह कोई दस्तावेज में प्रश्न में कार्य को देख सकता है और एक उदाहरण चित्र प्रस्तुत किया जा सकता है जिसके लिए एक विशेष मामला आवश्यक है।

Answer 7

बारे

यहाँ

मैं कभी कभी इच्छा इस डेटा सेट के ग्राफ में एम्बेड करने के लिए या स्रोत कोड में लिंक ग्राफिक्स, तो मैं प्रभावी रूप से कह सकते हैं एक तरह से वहाँ था, ", इस विशेष सुविधा दिनचर्या को गलत तरीके से ट्रिगर करने का कारण बन रहा था, इसलिए यही कारण है कि कोड का यह टुकड़ा जोड़ा गया था "।

हिस्सा:

हैं "ग्राफिक" है कि आप एम्बेड करना चाहते एक ग्राफ है, और यदि आप Doxygen उपयोग करते हैं, आप अपनी टिप्पणी में dot आदेशों एम्बेड कर सकते हैं दस्तावेज में एक ग्राफ उत्पन्न करने के लिए:

/** 
If we have a subgraph looking like this: 
\dot 
digraph g{ 
A->B; 
A->C; 
B->C; 
} 
\enddot 
the usual method does not work well and we use this heuristic instead. 
*/ 

Answer 8

डॉन नूथ ने आपके प्रोग्राम प्रलेखन के लिए भूखंड, ग्राफ, चार्ट, गणितीय समीकरणों और जो भी आपको समझने की आवश्यकता है, उसे शामिल करने के लिए literate programming का आविष्कार किया। एक साक्षर कार्यक्रम यह बताने का एक शानदार तरीका है कि ऐसा कुछ क्यों है और समय के साथ इस तरह से कैसे पहुंचा। कई, कई साक्षर-प्रोग्रामिंग उपकरण हैं; "noweb" उपकरण सबसे सरल है और कुछ लिनक्स वितरण के साथ भेज दिया जाता है।