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

1. तैयार होने तक बैकएंड प्रतिक्रियाओं का मजाक उड़ाना

एक मानक सॉफ्टवेयर विकास प्रक्रिया में, जब व्यवसाय से एक नई सुविधा का अनुरोध आता है, तो इसे कई टीमों के बीच वितरित किया जाता है: फ्रंट-एंड, बैक-एंड और मोबाइल ऐप डेवलपमेंट।

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

बैकएंड एक अड़चन बन जाता है।

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

समाधान: बैक-एंड टीम के साथ एक अनुबंध पर सहमत हों और सभी अनुरोधों का मज़ाक उड़ाएँ।

1. समापन बिंदुओं और संस्थाओं पर बैक-एंड टीम के साथ समन्वय करें।

2ए। स्टब प्रतिक्रियाओं के साथ बैकएंड एपीआई लागू करें। Faker लाइब्रेरी नमूना डेटा जनरेशन में मदद कर सकती है।

2बी। या दृश्यपटल पर स्टब्स लागू करें। यह सीधे कोड में डेटा वाला ऑब्जेक्ट हो सकता है। उदाहरण के लिए, Node.js में, आप गतिशील आयात का उपयोग करके इसे कुशलतापूर्वक कार्यान्वित कर सकते हैं और बंडल आकार बढ़ाने से बच सकते हैं:

 getUser() { return import('../../assets/mocks/users') .then(data => data.userById) .then(deserializeUser); };

यह एक नकली HTTP सेवा भी हो सकती है जो वास्तविक अनुरोध करने के बजाय JSON फ़ाइलों को संपत्तियों से प्राप्त करती है।

3. फ़ीचर फ़्लैग के पीछे फ़ीचर छिपाएँ।

   
   

4. जब बैकएंड तैयार हो, तो वास्तविक एपीआई पर स्विच करें यदि आपने फ्रंट-एंड स्टब्स दृष्टिकोण का उपयोग किया है, और सत्यापित करें कि सब कुछ अपेक्षित रूप से काम करता है। और इस फीचर को ऑन कर दें।

2. फीचर फ्लैग

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

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

कोड में, यह काफी सरल दिखता है:

1. प्रोजेक्ट में, हम सभी सक्रिय फ़ीचर फ़्लैग प्राप्त करते हैं। हुड के तहत, Gitlab अनलिश (फीचर टॉगल सर्विस) पर आधारित है, हम इसके आधिकारिक क्लाइंट का उपयोग करते हैं।
2. और फिर, कोड में केवल if features.YOUR_FEATURE डालें, जिसे छुपाने की आवश्यकता है।
3. आप फीचर फ़्लैग में विभिन्न मान जोड़कर उपयोग के मामलों का विस्तार कर सकते हैं। उदाहरण के लिए, रंग मान या छूट मान जोड़कर।

3. एक उत्पादन वातावरण में ट्रैकिंग मुद्दों के लिए त्रुटियों की निगरानी करना

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

व्यर्थ त्रुटियां

हुड के तहत, किसी भी अपठित अपवाद को ट्रैक किया जाएगा। जैसे-जैसे एप्लिकेशन और उपयोगकर्ताओं की संख्या बढ़ती है, त्रुटियों की संख्या इतनी अधिक हो सकती है कि वास्तव में महत्वपूर्ण कुछ भी नोटिस करना लगभग असंभव हो जाता है। यदि आप अनावश्यक सामग्री को फ़िल्टर नहीं करते हैं तो संतरी कूड़ेदान में बदल सकता है। उदाहरण के लिए, रद्द किए गए अनुरोध, कनेक्शन त्रुटियां और कनेक्टेड स्क्रिप्ट से त्रुटियां पूरी तरह से बेकार हैं और केवल सूचनाओं के साथ आपके कार्य ईमेल को स्पैम करेंगी। समाधान के रूप में, आप कॉन्फ़िगरेशन में फ़िल्टर जोड़ सकते हैं। ऐसा करने के लिए, बस beforeSend कॉलबैक को परिभाषित करें और इसे अपने sentryPackage.init में डालें। इस कॉलबैक में, आप प्रत्येक पकड़ी गई त्रुटि का विश्लेषण कर सकते हैं और यदि यह अनुपयोगी है तो इसे त्याग दें (शून्य लौटाकर)। यहां एक ऐसे फ़िल्टर का उदाहरण दिया गया है जो अनावश्यक त्रुटियों को बाहर करता है:

 function beforeSend(event, hint) { const error = hint.originalException; const externalScripts = [ 'gtm.js', // Google Tag Manager 'watch.js', // X Analytics ].join('|'); const errorsToIgnore = [ AxiosError.ERR_NETWORK, AxiosError.ECONNABORTED, AxiosError.ETIMEDOUT ]; if (axios.isCancel(error) || errorsToIgnore.includes(error.code) || error.stack?.match(externalScripts)) { return null; } return event; }

बेहतर डिबगिंग के लिए अधिक डेटा शामिल करें

डिफ़ॉल्ट रूप से, संतरी त्रुटि रिपोर्ट में अनुरोध और प्रतिक्रिया की सामग्री को शामिल नहीं कर सकता है। इस जानकारी के बिना, उचित डिबगिंग असंभव है। सौभाग्य से, beforeSend हैंडलर में, हम इस जानकारी को शामिल कर सकते हैं।

 function beforeSend(event, hint) { const error = hint.originalException; if (error.isAxiosError) { const url = error.request?.responseURL; const response = error.response?.data; const request = error.config?.data; event.extra = { ...(event.extra || {}), url, response, request }; } return event; }

संवेदनशील जानकारी फ़िल्टर करें

त्रुटि सामग्री में पासवर्ड, ईमेल पते और कुंजियों जैसे डेटा को शामिल नहीं किया जाना चाहिए। इस प्रकार की जानकारी को छिपाने के लिए संतरी के पास एक अंतर्निहित तंत्र है। आप इसे सुरक्षा सेटिंग्स में कॉन्फ़िगर कर सकते हैं। इसके अलावा, आप beforeSend ईवेंट ऑब्जेक्ट में कुछ भी निकाल सकते हैं

स्टैंडअलोन समाधान

यदि आपके व्यवसाय की प्रकृति किसी अन्य सर्वर पर इस प्रकार के डेटा को संग्रहीत करने पर रोक लगाती है, तो संतरी आपके अपने सर्वर पर इसका उपयोग करने की क्षमता प्रदान करता है।

4. अनुरेखण

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

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

हमारे विशिष्ट कार्यान्वयन में, हमने Jaeger का उपयोग किया, जो OpenTracing API पर आधारित है।

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

5. प्रदर्शन अनुकूलन

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

इसलिए, मैंने इस तरह के प्रोजेक्ट लिंटर्स में जोड़ा और package.json को Why-did-you-render चलाने के लिए एक अतिरिक्त प्रारंभिक कॉन्फ़िगरेशन जोड़ा। संक्षेप में, यह प्लगइन एक चेतावनी जारी करता है अगर कुछ अनावश्यक रूप से फिर से प्रस्तुत किया जाता है और सुझाव देता है कि इससे कैसे बचा जाए। साथ ही, हमने हेडलेस मोड में लाइटहाउस चलाना भी शामिल किया। कुछ लोग कहते हैं कि समयपूर्व अनुकूलन खराब हैं, लेकिन मेरे लिए, यह एक सिद्धांत है: इसे शुरू से ही करें ।

6. सभी टीम परियोजनाओं के लिए परिभाषित कोड शैली

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

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

7. प्रतिगमन परीक्षण

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

निष्कर्ष

इस लेख को पढ़ने के लिए समय निकालने के लिए धन्यवाद! अंत में, यह लेख प्रमुख सॉफ्टवेयर इंजीनियरिंग प्रथाओं पर प्रकाश डालता है जो विकास प्रक्रियाओं और कोड की गुणवत्ता को बढ़ाते हैं। बैकएंड रिस्पांस मॉकिंग, फीचर फ्लैग्स, एरर मॉनिटरिंग, परफॉर्मेंस ऑप्टिमाइजेशन, कोड स्टाइल स्टैंडर्ड्स, रिग्रेशन टेस्ट और ट्रेसिंग जैसी तकनीकों को अपनाकर आप अधिक कुशल और विश्वसनीय सॉफ्टवेयर बना सकते हैं। आइए अपने सॉफ़्टवेयर में सुधार करना जारी रखें और संपर्क में रहें! :)