किसी भी सॉफ्टवेयर इंजीनियर से प्रोडक्शन कोड के प्रमुख हिस्सों की समीक्षा करने के लिए कहें, और अनिवार्य रूप से, वे तीन चीजों को इंगित करेंगे जिन्हें रीफैक्टर करने की आवश्यकता है। तो इतना खराब, भंगुर, या गलत समझा गया कोड प्रोडक्शन में क्यों चल रहा है?
उत्तर सरल है: इंजीनियर इसे छूने से डरते हैं। रीफैक्टरिंग कार्यों की पहचान की जाती है और बैकलॉग में जोड़ा जाता है, लेकिन शायद ही कभी वर्तमान स्प्रिंट में आते हैं।
इसके कई कारण हैं। कोड किसी ऐसे इंजीनियर द्वारा लिखा गया हो सकता है जो वर्षों पहले टीम छोड़ गया था, और कोई भी इसे पूरी तरह से नहीं समझता। अन्य मामलों में, क्षमता व्यवसाय के लिए महत्वपूर्ण है। कोई भी संभावित आउटेज या राजस्व हानि के लिए जिम्मेदार नहीं होना चाहता।
इस पोस्ट में, हम जांच करेंगे कि कैसे आप Scientist का उपयोग करके महत्वपूर्ण रूबी प्रोडक्शन कोड को आत्मविश्वास के साथ माइग्रेट, रीफैक्टर, और बदल सकते हैं।
लेकिन पहले, आप पूछ सकते हैं — क्या हम कोड मुद्दों को खोदने के लिए टेस्ट्स का उपयोग नहीं कर सकते?
यही रेल्स टेस्टिंग के लिए है, है ना?
हां, और नहीं। तैनाती से पहले कोड परिवर्तनों में पूर्ण विश्वास प्राप्त करना अक्सर मुश्किल होता है। यूनिट और सिस्टम टेस्ट पास होते हैं। यह जाने के लिए अच्छा है, है ना?
वास्तविकता यह है कि वास्तविक दुनिया, यानी प्रोडक्शन का कोई विकल्प नहीं है। क्या होगा यदि डेटा गुणवत्ता खराब है या टेस्ट गायब हैं? आप कैसे जान सकते हैं कि नया सॉफ्टवेयर प्रोडक्शन थ्रूपुट को संभालने के लिए पर्याप्त अच्छा प्रदर्शन करेगा?
सार्वजनिक सेवाओं वाली टीमें कभी-कभी पाती हैं कि उन्हें "बगवर्ड्स कम्पैटिबिलिटी" मुद्दों से निपटने की आवश्यकता है। जब एक बग कुछ समय के लिए प्रोडक्शन में मौजूद रहा है, तो क्लाइंट्स लगातार गलत व्यवहार पर निर्भर तरीके से कोड कर सकते हैं। ग्राहक अक्सर सॉफ्टवेयर का अप्रत्याशित तरीकों से उपयोग करते हैं।
Scientist के साथ रूबी और रेल्स में प्रोडक्शन परिवर्तनों का निरीक्षण करें
यदि प्रोडक्शन परिवर्तन में विश्वास हासिल करने के लिए सबसे अच्छी जगह है, तो विचार करें कि कोड वहां कैसे व्यवहार करता है। यह पहली बार में डरावना लग सकता है, क्योंकि "प्रोडक्शन में टेस्टिंग" का विचार क्लासिक सॉफ्टवेयर इंजीनियरिंग प्रथाओं का विरोधाभास करता है।
हालांकि, अच्छी खबर यह है कि रूबी और रेल्स में Scientist जेम का उपयोग करके ऐसा करना आसान और सुरक्षित है। Scientist का नाम दिए गए परिकल्पना को सत्यापित करने के लिए प्रयोग करने के वैज्ञानिक पद्धति पर आधारित है। इस मामले में, हमारी परिकल्पना यह है कि नया कोड काम करता है।
हम इस दृष्टिकोण को सुरक्षित रूप से अपना सकते हैं इसका कारण यह है कि प्रयोग अभी भी मौजूदा कोड के परिणाम का उपयोग करते हैं। नया कोड केवल अवलोकन और तुलना उद्देश्यों के लिए मूल्यांकन किया जाता है, दोनों सटीकता और प्रदर्शन के लिए। हम वास्तविक-विश्व डेटा और पैरामीटर्स का उपयोग करके प्रदर्शन का मूल्यांकन करके पहले चर्चा किए गए टेस्ट कवरेज चिंताओं को कम करते हैं। प्रयोग आमतौर पर प्रोडक्शन पर प्रभाव को कम करने के लिए अनुरोधों के चुने हुए नमूना दर का मूल्यांकन करते हैं। हालांकि, यदि वांछित हो तो आप हर अनुरोध का मूल्यांकन कर सकते हैं।
आइए अब देखें कि Scientist ब्रांच बाय अब्स्ट्रैक्शन तरीके से कैसे काम करता है।
रूबी के Scientist में ब्रांच बाय अब्स्ट्रैक्शन पैटर्न
Scientist का दृष्टिकोण मार्टिन फाउलर द्वारा वर्णित ब्रांच बाय अब्स्ट्रैक्शन पैटर्न से शुरू होता है जो "एक सॉफ्टवेयर सिस्टम में बड़े पैमाने पर परिवर्तन को क्रमिक तरीके से बनाने" के रूप में वर्णित है।
हम अपडेट किए जा रहे कोड को अलग करने के लिए एक अब्स्ट्रैक्शन लेयर पेश करते हैं। यह लेयर तय करती है कि किस कार्यान्वयन का उपयोग करना है ताकि प्रयोग शेष सिस्टम के लिए पारदर्शी हो। यह तकनीक फीचर फ्लैग का उपयोग करने से संबंधित है जो कोड पथ निर्धारित करता है।
Github से उत्पन्न Scientist जेम, एक प्रयोग का उपयोग करके इस पैटर्न को लागू करता है। मौजूदा कोड को कंट्रोल के रूप में संदर्भित किया जाता है, और नया कार्यान्वयन कैंडिडेट है। दोनों कोड पथ यादृच्छिक क्रम में चलाए जाते हैं, लेकिन केवल कंट्रोल परिणाम क्लाइंट को वापस किया जाता है।
Scientist का उपयोग करके रूबी सर्विस को रीफैक्टर करना
एक रूबी सर्विस पर विचार करें जो दी गई संख्या के लिए सबसे बड़ा अभाज्य गुणनखंड लौटाती है। मान लें कि हमने आवश्यक उम्मीदवारों के सेट को छंटनी करने के लिए अनुकूलन की पहचान की है, जिससे सर्विस तेज हो जाती है।
हालांकि, सर्विस मालिक यह सुनिश्चित करना चाहते हैं कि कोई बग पेश नहीं किया गया था। वे किसी भी प्रदर्शन सुधार का निरीक्षण भी करना चाहते हैं। निम्न कोड पेश करें, ग्राहकों को इस मेथड को कॉल करने के लिए संशोधित करें:
इस बिंदु पर, केवल use (कंट्रोल) एक्सप्रेशन आह्वान किया जाता है। प्रयोग को सार्थक बनाने के लिए, एक कस्टम Experiment क्लास परिभाषित करें ताकि इसे सक्षम किया जा सके (नीचे 100% समय) और परिणाम प्रकाशित किए जा सकें (इस मामले में, केवल लॉगिंग)। Scientist शानदार डेटा उत्पन्न करता है लेकिन डिफ़ॉल्ट रूप से इसके साथ कुछ नहीं करता। वह भाग आप पर छोड़ दिया गया है।
प्रयोग के परिणाम लॉग किए जाएंगे, और हम फीडबैक के आधार पर समय के साथ सुधार कर सकते हैं। एक बार जब नया कोड आवश्यकताओं को पूरा करता है और विश्वास उच्च होता है, तो साइंस कोड को नए कार्यान्वयन के डेलीगेशन के साथ प्रतिस्थापित करके नए कार्यान्वयन पर कटओवर पूरा करें।
LabTech रूबी ऑन रेल्स में Scientist प्रयोगों को सरल बनाता है
आप अपने रेल्स एप्लिकेशन में LabTech जेम का उपयोग करके Scientist को आसानी से कॉन्फ़िगर कर सकते हैं और परिणामों को संभाल सकते हैं।
AppSignal का उपयोग करने वाले एप्लिकेशन Appsignal.instrument कस्टम इंस्ट्रूमेंटेशन हेल्पर का उपयोग करके ट्रैक कर सकते हैं कि Scientist इवेंट्स को पूरा होने में कितना समय लगता है। इसे विभिन्न प्रयोग कोड ब्लॉक्स के चारों ओर लपेटें ताकि इवेंट्स प्रदर्शन टाइमलाइन में दिखाई दें।
अब, LabTech पर वापस — नीचे दिया गया वेब पेज केवल फैक्टर करने के लिए एक नंबर स्वीकार करता है।

शुरू करना आसान है बशर्ते आपके पास कंसोल तक पहुंच हो। पहले, अपने Gemfile में LabTech जेम जोड़ें और bundle install चलाएं।
टेबल्स परिणाम और प्रयोग कॉन्फ़िगरेशन स्टोर करते हैं, इसलिए डेटाबेस माइग्रेशन चलाएं।
अब्स्ट्रैक्शन लेयर वही है, सिवाय इसके कि LabTech मॉड्यूल का उपयोग किया जाता है। पूरा कोड GitHub पर उपलब्ध है।
इस बिंदु पर, प्रयोग अक्षम है, इसलिए कंसोल का उपयोग करके इसे सभी मामलों में या समय के प्रतिशत के लिए सक्षम करें।
हम अब टेस्ट चला सकते हैं और प्रयोग का मूल्यांकन किया जाएगा। परिणामों के टेक्स्टुअल व्यू के लिए, रेल्स कंसोल से निम्नलिखित में से किसी एक कमांड का उपयोग करें।
कुछ सफल रन और एक निर्मित एरर के बाद, यहां परिणाम सारांश कैसा दिखता है इसका एक उदाहरण है। सफलताओं और विफलताओं का अवलोकन, साथ ही प्रदर्शन अंतर दिखाने वाला ASCII चार्ट।
Blazer जेम परिणामों का आसानी से विश्लेषण करने का एक अच्छा तरीका प्रदान करता है। यह इंस्टॉल करना सरल है और टेबल्स के खिलाफ SQL क्वेरी चलाने की अनुमति देता है। यहां क्वेरी दिखाती है कि कैंडिडेट कार्यान्वयन मूल की तुलना में काफी तेज है।

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

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

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