मेन्यू

कोड रीफैक्टरिंग: इसके बारे में आपको क्या जानना चाहिए

code refactoring what you need know about it

समस्याओं को खत्म करने के लिए हमारे साधन का प्रयास करें

कोड को समझना: एक परीक्षक का परिप्रेक्ष्य

Term रिफैक्टरिंग ’शब्द का उपयोग मुख्य रूप से आवश्यक कोड क्लीनअप / रिडिजाइन को दर्शाने के लिए किया जाता है।

इस ट्यूटोरियल में, हम रीफैक्टरिंग की परिभाषा को समझेंगे, कोड रीफैक्टरिंग की आवश्यकता पर चर्चा करेंगे, और विभिन्न प्रोजेक्ट टीम के सदस्यों पर रिफैक्टिंग कोड के प्रभाव की समीक्षा करेंगे। हम सबसे महत्वपूर्ण प्रश्न के उत्तर पर भी चर्चा करेंगे - एक परीक्षक के रूप में, आपको रिफैक्टरिंग के बारे में जानने की आवश्यकता क्यों है?

इसके अतिरिक्त, हम अवधारणा को स्पष्ट करने के लिए कुछ केस स्टडी पर भी चर्चा करेंगे।

कोड रिफलेक्टरिंग

आप क्या सीखेंगे:

रिफैक्टरिंग का परिचय

शुरुआत करने के लिए, आइए हम पहले यह समझें कि वास्तव में रिफैक्टिंग क्या है।

मौजूदा कार्यक्षमता को बनाए रखते हुए कोड और / या डेटाबेस में सुधार के लिए रिफैक्टिंग अनिवार्य रूप से एक अभ्यास या प्रक्रिया है। विचार अक्षम और अधिक जटिल कोड को अधिक कुशल, अधिमानतः सरल और आसान कोड में बदलना है।

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

कोड रिफैक्टिंग की आवश्यकता

यदि हम एप्लिकेशन या मॉड्यूल की मूल कार्यक्षमता बनाए रख रहे हैं, तो एक सवाल यह उठता है कि हम रिफैक्टरिंग को क्यों परेशान करते हैं? खैर, ऐसे कई कारण हैं जिनके लिए किसी विशेष मॉड्यूल या कोड के टुकड़े को फिर से भरना पड़ सकता है, जैसे:

  1. कोड बदबू आ रही है
  2. तकनीकी ऋण
  3. चंचल सॉफ्टवेयर विकास दृष्टिकोण, आदि।

हम इन बिंदुओं पर विस्तार से निम्नलिखित अनुभागों में चर्चा करेंगे।

# 1) कोड गंध:

हम सभी यह समझ सकते हैं कि जब भोजन से बदबू आने लगती है तो यह इंगित करता है कि यह सबसे खराब होने की संभावना है - यह कोड के लिए भी सही है! कोड बदबू संकेत है कि एक बहुत गंभीर समस्या कोड में मौजूद हो सकती है।

निम्नलिखित कुछ सामान्य कोड गंध हैं:

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

समय बीतने के साथ कोड की गंध अधिक स्पष्ट हो जाती है। जैसे-जैसे एप्लिकेशन या सिस्टम बढ़ता है, अंततः ये कोड बदबू कोड विकास, रखरखाव और यहां तक ​​कि चरम परिदृश्यों में प्रदर्शन को प्रभावित करते हैं।

# 2) तकनीकी ऋण:

एक सॉफ्टवेयर विकसित करते समय, उपलब्ध सीमित समय और संसाधनों के दौरान, हम अक्सर वांछित परिणाम प्राप्त करने के लिए शॉर्टकट ले सकते हैं।

एक ऐसी सुविधा पर विचार करें जिसे मौजूदा मॉड्यूल में जोड़ने की आवश्यकता है। चर्चा के बाद, टीम इस सुविधा को जोड़ने के लिए 2 दृष्टिकोण नीचे बताती है। दृष्टिकोण ए, वितरित करने के लिए 2 स्प्रिंट लेता है, अनुमोदित दीर्घकालिक दृष्टिकोण होगा। दृष्टिकोण बी को वितरित करने में केवल 5 दिन लगते हैं एक गड़बड़ हार्ड-कोडेड हैक है जो केवल अल्पावधि में मॉड्यूल को सेवा देने के लिए डिज़ाइन किया गया है।

यदि टीम सीमित समय के भीतर सुविधा देने के लिए दबाव में है, तो वे अभी के लिए दृष्टिकोण बी का पालन करने के लिए सहमत हो सकते हैं और भविष्य के लिए बैकलॉग में दृष्टिकोण ए जोड़ सकते हैं। ऐसा करके, इस टीम ने सिर्फ अपने लिए तकनीकी ऋण का निर्माण किया।

सरल शब्दों में, सॉफ़्टवेयर डेवलपमेंट में तकनीकी ऋण का अर्थ है, अतिरिक्त सुधार या ओवरहेड की आवश्यकता होती है, जो उचित फ़िक्सेस को 'सही तरीके से' करने के लिए आवश्यक हो।

लीगेसी सिस्टम्स समय के साथ भारी तकनीकी ऋण प्राप्त करते हैं जो बदले में आवेदन को विफलता और समर्थन और बनाए रखने में मुश्किल बना सकते हैं।

अधिक पढ़ें=> तकनीकी विभाग क्या है

# 3) एगाइल सॉफ्टवेयर डेवलपमेंट दृष्टिकोण के बाद:

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

इस संबंध को नीचे दिए गए चित्र में दर्शाया गया है

चंचल सॉफ्टवेयर विकास दृष्टिकोण

अनुशंसित पढ़ें => शीर्ष कोड विश्लेषण उपकरण

क्यों एक क्यूए की जरूरत के बारे में पता करने के लिए Refactoring?

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

फिर, हम सॉफ्टवेयर परीक्षण सहायता समुदाय में इस असंबंधित अवधारणा पर चर्चा क्यों कर रहे हैं? इस प्रश्न के उत्तर के लिए इस ट्यूटोरियल के बाकी हिस्सों को पढ़ना जारी रखें।

(1) यूनिट टेस्टर / डेवलपर्स के लिए

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

# 2) परीक्षकों के लिए

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

  • एक परीक्षक के रूप में, कोड का फिर से भरना लगभग = में गहराई से परीक्षण + प्रतिगमन परीक्षण का अनुवाद करता है। गहराई से परीक्षण करने के लिए सभी मौजूदा उपयोगकर्ता प्रवाह को शामिल करने की आवश्यकता है ताकि यह सुनिश्चित हो सके कि सभी कार्यात्मकता पहले की तरह काम कर रही है। प्रतिगमन परीक्षण पूरे आवेदन (या प्रभावित क्षेत्रों) को यह सुनिश्चित करने के लिए आवश्यक है कि एक मॉड्यूल का उन्नयन अनजाने में अन्य मॉड्यूल की कार्यक्षमता को नहीं तोड़ता है।
  • उपयोगकर्ता स्वीकृति परीक्षण महत्वपूर्ण होंगे और इन परीक्षणों को रिलीज से पहले तैयार होने से पहले पारित करने की आवश्यकता है।
  • इसके अतिरिक्त, लोड परीक्षण जैसे किसी भी अन्य परीक्षण की आवश्यकता है, सुरक्षा परीक्षण आदि को भी आवश्यकतानुसार लागू करना होगा।

# 3) ऑटोमेशन टेस्ट इंजीनियर्स

कोड को फिर से भरने के कारण कार्यात्मक और गैर-कार्यात्मक स्वचालन स्क्रिप्ट विफल हो सकती हैं।

यह निम्नलिखित कारणों से हो सकता है:

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

यह अनुशंसा की जाती है कि कार्यात्मक स्वचालन परीक्षण केवल एक बार एक सुविधा के स्थिर होने पर स्थापित किया जाना चाहिए, अन्यथा यह परिणामस्वरूप बहुत सारे rework होगा क्योंकि यह सुविधा विकसित होती है।

स्वचालन परीक्षणों के डेवलपर होने के नाते, स्वचालन परीक्षण इंजीनियरों को भी एक डेवलपर की तरह सोचने और कोड को बनाए रखने के लिए एक स्वच्छ और आसान बनाने का लक्ष्य चाहिए। ज्यादातर IDE जैसे IntelliJ IDEA, Eclipse इत्यादि में आसान संदर्भ के लिए आमतौर पर उपयोग किए जाने वाले रीफैक्टरिंग विधियों के साथ इन-बिल्ट रीफैक्टरिंग मेनू शामिल हैं।

नीचे IntelliJ IDEA (सामुदायिक संस्करण) में रिफैक्टिंग मेनू का स्क्रीनशॉट है।

एक सूची बनाने के लिए जावा

रीफैक्टिंग मेनू

# 4) टेस्ट लीड्स / क्यूए लीड्स के लिए

  • टेस्ट लीड्स / क्यूए लीड्स को डेवलपर्स, उत्पाद विश्लेषक और शायद हितधारकों सहित टीम के बाकी सदस्यों के साथ मिलकर काम करने की आवश्यकता हो सकती है, ताकि यह सुनिश्चित हो सके कि ऐसी परियोजनाओं के लिए टेस्ट प्लानिंग सावधानी से की जाए।
  • मौजूदा कार्यक्षमता को समझना महत्वपूर्ण है। मौजूदा कार्यक्षमता के आधार पर, व्यावसायिक मामलों, उपयोगकर्ता प्रवाह और उपयोगकर्ता स्वीकृति परीक्षणों को प्रलेखित किया जाना चाहिए। जब एक रिफलेक्टेड कोड का परीक्षण किया जा रहा है, तो इन सभी परिदृश्यों को मान्य करने की आवश्यकता है, साथ ही प्रभावित क्षेत्रों के प्रतिगमन परीक्षण के साथ।
  • परीक्षण दृष्टिकोण की योजना बनाते समय सक्रिय रहें और परीक्षण की योजना । यदि आप कई परीक्षण वातावरण या नए परीक्षण उपकरण की आवश्यकता का अनुमान लगाते हैं, तो कृपया परीक्षण चरण शुरू होने पर किसी भी देरी को रोकने के लिए जल्दी से अनुरोध भेजें।
  • परीक्षण में योगदान करने के लिए गैर-परियोजना टीम के सदस्यों या अंतिम उपयोगकर्ताओं को शामिल करने में संकोच न करें।

मामले का अध्ययन

अब हम कुछ वास्तविक जीवन के उन अध्ययनों पर चर्चा करेंगे जिनमें मुझे प्रत्यक्ष रूप से काम करने या परोक्ष रूप से योगदान करने का अवसर मिला।

केस स्टडी # 1

कार्य: चर के साथ हार्ड-कोडित मूल्यों को बदलने और नए स्वचालित तकनीकी प्रलेखन पीढ़ी उपकरण के लिए टिप्पणियां जोड़ने के लिए एक मॉड्यूल को रिफ्लेक्टर करें।

चुनौतियों :कोई बड़ी चुनौती नहीं। मॉड्यूल नया था, कार्यात्मक और उपयोगकर्ता स्वीकृति आवश्यकताओं, उपयोगकर्ता प्रवाह और परीक्षण मामलों का दस्तावेजीकरण किया था। प्रारंभिक परीक्षण के दौरान ही यूनिट परीक्षण किए गए थे।

परीक्षण दृष्टिकोण :मॉड्यूल के परीक्षण के मामलों को फिर से शुरू किया गया और अपेक्षाकृत प्रभावित क्षेत्रों को निष्पादित किया गया। रिलीज से पहले किसी भी दोष को रिपोर्ट किया गया और हल किया गया।

केस स्टडी # 2

टास्क :आवेदन पैमाने को सुविधाजनक बनाने के लिए रिफैक्टर मौजूदा संग्रहीत प्रक्रिया।

इस परिदृश्य में संग्रहीत कार्यविधि एक पुरानी संग्रहीत कार्यविधि थी जिसे कुछ साल पहले डिज़ाइन किया गया था, इस आवश्यकता को ध्यान में रखते हुए कि अनुप्रयोग 10 से कम समवर्ती सत्रों के साथ आंतरिक अनुप्रयोग के रूप में अपनी संग्रहीत प्रक्रिया का उपयोग कर रहा था।

अब कंपनी इस एप्लिकेशन को सॉफ्टवेयर के रूप में सेवा (सास) के रूप में विपणन करना चाहती थी, जिसमें शुरुआत में 300 समवर्ती सत्रों की अपेक्षित मात्रा थी।

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

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

चुनौतियां:

(1) प्रोजेक्ट मैनेजर / उत्पाद विश्लेषक

  • आवश्यक भीड़ जुटना - चूंकि यह संग्रहित प्रक्रिया एक विरासत कोड थी, इसलिए जब मॉड्यूल पहली बार डिजाइन किया गया था, तो इसके लिए कोई दस्तावेज की आवश्यकता नहीं थी। पिछले कुछ वर्षों में किए गए पुनरावृत्तियों के लिए, व्यापार नियमों और तर्क को मॉड्यूल से जोड़े या हटाए जाने का संकेत करने के लिए कोई परिवर्तन लॉग नहीं था।
  • परियोजना अनुसूची - चूंकि आवश्यकताओं को स्पष्ट रूप से परिभाषित नहीं किया गया था और कोड निर्भरता अभी तक पूरी तरह से पहचानी नहीं गई थी, इसलिए अस्थायी अनुसूची को संवाद करना मुश्किल था।

# 2) डेवलपर्स के लिए

  • स्पष्ट आवश्यकताओं और व्यावसायिक नियमों का अभाव।
  • अपनी कार्यक्षमता को खोए बिना कोड को साफ करना।
  • अज्ञात प्रभावित क्षेत्र और / या कोड निर्भरता।
  • ठोस विकास समय अनुमान प्रदान करने में असमर्थ।
  • नई यूनिट टेस्ट बनाने की जरूरत है।

# 3) परीक्षकों के लिए

  • स्पष्ट आवश्यकताओं और व्यावसायिक नियमों का अभाव परीक्षण योजना को प्रभावित करता है।
  • अज्ञात प्रभावित क्षेत्र परीक्षण योजना को प्रभावित करते हैं, विशेष रूप से प्रतिगमन परीक्षणों के लिए।
  • ठोस परीक्षण अनुमान प्रदान करने में असमर्थ।

# 4) हितधारकों

  • स्पष्ट प्रलेखित आवश्यकताओं की कमी और / या उपयोगकर्ता प्रवाह + तंग समय सीमा = विफलता का उच्च जोखिम।

जोखिमों को कम करने और चुनौतियों के आसपास काम करने के लिए टीम द्वारा पीछा किया गया दृष्टिकोण :

(i) टीम ने आवश्यकताओं को इकट्ठा करने के लिए एक सहयोगी दृष्टिकोण का पालन किया : प्रोजेक्ट मैनेजर / उत्पाद विश्लेषक और परीक्षकों ने प्रमुख कार्यक्षमता और उपयोगकर्ता प्रवाह को समझने और दस्तावेज करने के लिए आंतरिक अंत उपयोगकर्ताओं के साथ मिलकर काम किया।

डेवलपर्स ने भी कोड की समीक्षा की और आवश्यकताओं के दस्तावेज़ में प्रासंगिक जानकारी जोड़ी। यह स्प्रिंट स्टार्ट डे से पहले किया गया था।

(ii) लागू किए जा रहे परिवर्तन का परीक्षण करने के लिए वैकल्पिक परीक्षण वातावरण बनाया गया था : आओ हम इन वातावरणों को गामा और ती के रूप में पुकारें। गामा के पास पुराना कोड होगा और Phi में हर समय तैनात नवीनतम रिफैक्टेड संग्रहित प्रक्रिया होगी।

समानांतर में 2 परीक्षण वातावरण होने के बाद, लगभग - और - दृष्टिकोण के बाद से पहले, टीम ने इन 2 परीक्षण वातावरणों में व्यवहार की तुलना करके अधिक गहराई और खोजपूर्ण परीक्षण करने की अनुमति दी, वे संभावित कीड़े की पहचान करने में सक्षम थे।

टीम ने वैकल्पिक परीक्षण वातावरण के लिए आवश्यकताओं को प्रदान किया जो स्प्रिंट शुरू होने की तारीख से पहले प्रदान किया गया था।

(iii) अंतिम उपयोगकर्ताओं और हितधारकों के परीक्षण में शामिल होना : किसी भी स्पष्ट मुद्दे को पकड़ा गया और टीम को अधिक समय देने और आवश्यक फिक्स का परीक्षण करने की अनुमति देने पर जल्दी रिपोर्ट किया गया।

(iv) निकास मानदंड को परिभाषित करना और उसका पालन करना: प्रारंभिक नियोजन चरणों में निकास मानदंड निर्धारित किए गए थे - 80% उपयोगकर्ता प्रवाह परीक्षण किए गए, कोई महत्वपूर्ण बग अनसुलझे नहीं है, रिलीज से पहले हितधारकों से डेमो और साइन ऑफ करें।

(v) एक अस्थायी रिलीज की तारीख निर्धारित करना: एक रिलीज की तारीख की स्थापना की और टीम को एक सामान्य समापन बिंदु की ओर काम करने के लिए प्रेरित किया। परियोजना के दायरे के आधार पर, टीम द्वारा यह सिफारिश की गई थी कि टीम को परियोजना को निष्पादित करने के लिए पर्याप्त समय की अनुमति देने के लिए नियमित 2-सप्ताह के स्प्रिंट के बजाय 3 सप्ताह के स्प्रिंट का पालन किया जाना चाहिए।

निष्कर्ष

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

कोड की बदबू, तकनीकी ऋण या फुर्तीले सॉफ्टवेयर विकास के दृष्टिकोण के कारण किसी विशेष मॉड्यूल या कोड के टुकड़े को फिर से भरना पड़ सकता है।

परीक्षकों के लिए, कोड का फिर से भरना लगभग = में गहराई से परीक्षण + प्रतिगमन परीक्षण का अनुवाद करता है।

सभी मौजूदा उपयोगकर्ता प्रवाह का परीक्षण करने के लिए इन-डेप्थ परीक्षण की आवश्यकता है ताकि यह सुनिश्चित किया जा सके कि सभी कार्यशीलता पहले की तरह काम कर रही है या नहीं। संपूर्ण एप्लिकेशन (या प्रभावित क्षेत्रों) का प्रतिगमन परीक्षण यह सुनिश्चित करने के लिए आवश्यक है कि एक मॉड्यूल का उन्नयन अनजाने में अन्य मॉड्यूल की कार्यक्षमता को तोड़ नहीं पाए।

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

लेखक के बारे में: यह जानकारीपूर्ण ट्यूटोरियल नेहा बी द्वारा लिखा गया है। वह वर्तमान में एक गुणवत्ता आश्वासन प्रबंधक के रूप में काम कर रही है और इन-हाउस और ऑफ़शोर क्यूए टीमों का नेतृत्व और प्रबंधन करने में माहिर है।

क्या आपने एक चुनौतीपूर्ण परियोजना पर काम किया है जिसमें कोड या मॉड्यूल / अनुप्रयोग को फिर से शामिल करना शामिल है? यदि हाँ, तो हमारे साथी परीक्षकों के लिए टिप्पणी अनुभाग में अपने अनुभव साझा करने के लिए स्वतंत्र महसूस करें।

अनुशंसित पाठ

^