API डॉक्स आपको बताएंगे कि API का उपयोग कैसे करें। लेकिन जब चीजें गलत हो जाती हैं, तो आप अपने दम पर रह सकते हैं। त्रुटि संदेश अक्सर अधूरे, भ्रामक, या अनुपयोगी होते हैं। और वैसे भी NoMethodError: undefined method '[]' for nil:NilClass के साथ आप क्या करने वाले हैं?
जब आप एक API, फ्रेमवर्क, या लाइब्रेरी सीखते हैं, तो आप केवल यह नहीं सीख सकते कि जब चीजें ठीक चल रही हों तो इसका उपयोग कैसे करें। आपको यह भी पता लगाना होगा कि जब यह आपको एक त्रुटि वापस देता है तो क्या करना है।
आप कोड को कैसे तोड़ते हैं?
यह सीखने का एक आसान तरीका है कि जब आप जिस API का उपयोग कर रहे हैं वह टूट जाए तो क्या करना है। इसे स्वयं तोड़ें!
उदाहरण के लिए, मैं:
-
गलत प्रकार का डेटा पास करें। आप एक स्ट्रिंग के बजाय एक सिंबल पास कर सकते हैं, एक सरणी के बजाय एक स्ट्रिंग, एक सरणी के बजाय एक हैश, ऐसी चीजें।
-
अधूरा डेटा पास करें। आप
nilपास कर सकते हैं, कुछ फील्ड भरे बिना हैश, और ऑब्जेक्ट जिन्हें अभी आरंभ किया गया है। -
यदि API को नेटवर्क एक्सेस की आवश्यकता है, तो वाईफाई से डिस्कनेक्ट करें या नेटवर्क केबल खींच लें। क्या यह सिर्फ टाइम आउट होता है, या क्या यह आपको बताता है कि यह किस सेवा तक नहीं पहुंच सका?
-
यदि API आपको एक ब्लॉक पास करने की अनुमति देता है, तो ब्लॉक के अंदर अपवाद फेंकें, या गलत प्रकार का डेटा वापस करें।
एक बेहतरीन API आपको बताएगा कि आपने क्या गलत किया। एक उत्कृष्ट API आपको बताएगा कि इसे कैसे ठीक किया जाए। लेकिन ज्यादातर बार, आप एक रूबी NoMethodError, अप्रत्याशित nils, या, बदतर, पूरी तरह से विचित्र रिटर्न मानों में फंस जाएंगे।
कोड क्यों तोड़ें?
यह सब बुरा नहीं है। यदि आप एक ओपन-सोर्स जेम के साथ खेल रहे हैं, तो आप यह समझने के लिए समय निकाल सकते हैं कि वह अप्रत्याशित व्यवहार कहां से आया और क्यों हुआ। आप डिबग कर सकते हैं और लाइब्रेरी या API कैसे काम करता है, इसके बारे में बहुत कुछ जानने के लिए थोड़ा सा कोड पढ़ सकते हैं।
एक बार जब आप पता लगा लेते हैं कि NoMethodError कहां से आ रहा है, तो आप एक कदम आगे जा सकते हैं। आप अगले व्यक्ति के लिए त्रुटि संदेश को ठीक कर सकते हैं जो वास्तव में इस समस्या में फंसेगा! छोटे त्रुटि संदेश सुधार बेहतरीन ओपन-सोर्स योगदान और आसान पुल रिक्वेस्ट बनाते हैं। और वे पूरे रूबी इकोसिस्टम को बाकी सभी के लिए थोड़ा बेहतर बनाते हैं।
यहां तक कि अगर यह एक क्लोज्ड-सोर्स REST API है, तो आप अभी भी इस अभ्यास से कुछ प्राप्त कर सकते हैं। API से मिलने वाली विभिन्न त्रुटियों को देखने के बाद, जब आप वास्तव में किसी त्रुटि में फंसेंगे तो आपके लिए समस्या को ठीक करना आसान होगा।
एक बार जब आप अपने आसपास के कोड में त्रुटियों को देखने और ठीक करने में अधिक सहज हो जाते हैं, तो आप टूटे हुए कोड को एक पहेली के रूप में देखेंगे जिसे हल किया जाना है। जब आप स्क्रीन पर डंप किए गए एक अपवाद और बैकट्रेस देखते हैं तो आप स्वचालित रूप से नहीं घबराएंगे। इसके बजाय, आप उन्हें उस सिस्टम के बारे में अधिक जानने के अवसर के रूप में देखेंगे जिसके साथ आप काम कर रहे हैं।
अंत में, आप जानेंगे कि जब कोड टूटता है, तो आप इसे फिर से जोड़ पाएंगे। आप नई लाइब्रेरी और API आज़माने में अपने आत्मविश्वास में सुधार करेंगे। और वह साहस नई चीजें सीखने की आपकी दर को बढ़ाएगा।