समाधानों की गुणवत्ता में सुधार करने का एक सरल तरीका

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

SPCAF ( http://spcaf.com ) के लिए कोड विश्लेषण नियमों को विकसित करते हुए, मैंने इस स्थिति को जल्दी से ठीक करने का एक तरीका पाया।



इस तरह के सभी कोड ब्लॉक खोजें:

try { // } catch(Exception e) { //  ,  throw; } 

प्रकार throw; catch । यह महत्वपूर्ण है कि पकड़ अंतर्निहित Exception को इंगित करता है, और विशिष्ट प्रकार के अपवाद को नहीं।

आपका एप्लिकेशन क्रैश होना शुरू हो जाएगा और आपको throw को हटाए बिना मिली सभी त्रुटियों को ठीक करना होगा। मैंने पहले ही कई बार विभिन्न परियोजनाओं पर काम किया है, और इससे बहुत सकारात्मक परिणाम मिले हैं। यहां तक ​​कि अगर प्रोग्रामर विरोध करते हैं, तो फेंकने की अनुमति न दें।

अध्ययन

नियमों का परीक्षण करने के लिए, मैंने लगभग 70 .wsp फाइलें, SharePoint समाधान एकत्र किए। उनमें से ज्यादातर परियोजनाएं हैं जिनमें मैंने भाग लिया है, और मैं उन सभी समस्याओं से अच्छी तरह परिचित हूं जो विकास के दौरान उत्पन्न हुई थीं। मैंने बिना throw try\catch ब्लाक्स के घनत्व की गणना की और यही हुआ:

• सबसे समस्याग्रस्त समाधान 36 लाइनों का 1 ब्लॉक है । यही है, लगभग हर महत्वपूर्ण विधि इस तरह के try\catch में लपेटी गई थी।
• औसत स्कैल के निर्णय - 90-100 लाइनों पर 1 ब्लॉक । इनमें से कुछ समाधानों ने पहले ही try\catch ।
• अच्छे निर्णय - 120-130 लाइनों पर 1 ब्लॉक । उन्हें कभी कोई समस्या नहीं थी।

तर्क

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

वास्तव में, सभी अपवादों को पकड़ना एक प्रोग्रामर द्वारा की गई गलती को दबाने का प्रयास है। त्रुटि अभी भी क्रॉल करती है, लेकिन इतनी स्पष्ट नहीं है, और अक्सर पूरी तरह से अलग जगह पर। समाधान विकसित करते समय यह समस्याएं पैदा करता है। यह SharePoint के लिए विशेष रूप से सच है, क्योंकि इसका API बेहद जटिल है।

मुझे पता है कि SharePoint समाधान में केवल एक ही मामला है जब सभी अपवादों को पकड़ने और उन्हें आगे नहीं फेंकना उचित है - दृश्य घटकों में, ताकि एक डेवलपर त्रुटि पोर्टल पर बाढ़ न आए। लेकिन उनमें से भी यह एक पंक्ति में हर किसी को पकड़ने के बजाय, विशिष्ट प्रकार के अपवादों को संभालने पर विचार करने योग्य है। अन्य मामलों में, कोड को जितनी जल्दी हो सके और जोर से दुर्घटनाग्रस्त होना चाहिए, अधिमानतः रिपोर्ट करना कि क्या गलत हुआ। अपवाद के मामले में किसी भी रिटर्न को false या null न बनाएं, कोड को गिरने दें, फिर उपयोगकर्ता को देखने से पहले डेवलपर्स और परीक्षकों को त्रुटि दिखाई देगी।

निष्कर्ष

त्रुटि दमन की समस्या न केवल SharePoint समाधानों के लिए और न केवल C # और .NET प्लेटफ़ॉर्म के लिए प्रासंगिक है। शायद अन्य परियोजनाओं में आप अपवादों के दमन को समाप्त करके स्थिति में काफी सुधार कर सकते हैं।

पुनश्च। नियमों की जाँच करने वाले नियमों का समूह - http://spcafcontrib.codeplex.com/