अभ्यासकर्ता की तीन प्रवृत्तियाँ अपनाएँ - आधिकारिक दस्तावेज़ से मिलान करें, खुद टेस्ट करें, मतिभ्रम के संकेत खोजें - कुछ भी शामिल करने से पहले।
इस पाठ को Kodokon में खोलेंमतिभ्रम कोई बेतुका जवाब नहीं है: यह एक प्रशंसनीय और गलत जवाब है - एक ऐसी विधि जो होनी तो चाहिए पर है नहीं, दो संस्करण पहले नाम बदली गई कोई ऑप्शन, कोई पलट दिया गया डिफ़ॉल्ट व्यवहार। ठीक यही चीज़ सक्षम डेवलपरों को कमज़ोर बनाती है: मतिभ्रम वाला कोड मुहावरेदार होता है, अच्छे नाम वाला होता है, इकोसिस्टम के अनुरूप होता है। यह सही दिखता है। कुछ भी शामिल करने से पहले तीन गैर-समझौता-योग्य प्रवृत्तियाँ: अपने इस्तेमाल किए संस्करण के लिए आधिकारिक दस्तावेज़ से मिलान करें, किसी न्यूनतम संदर्भ में कोड खुद टेस्ट करें, और जवाब का ऑडिट करवाएँ - खुद मॉडल से भी।
अपना पिछला जवाब लो और उसका ऐसे ऑडिट करो जैसे वह किसी और से आया हो।
1. हर सत्यापन-योग्य तकनीकी दावा गिनाओ: API या फ़ंक्शन का नाम, बताया गया व्यवहार, डिफ़ॉल्ट मान, संस्करण संख्या।
2. हर एक के लिए, अपना आत्मविश्वास स्तर बताओ: निश्चित / संभावित / सत्यापित करना है।
3. हर "सत्यापित करना है" के लिए, ठीक-ठीक बताओ कि आधिकारिक दस्तावेज़ में क्या देखना है: संबंधित पृष्ठ, फ़ंक्शन या मॉड्यूल का नाम।
4. जो कुछ भी संस्करण या प्लेटफ़ॉर्म पर निर्भर हो सकता है उसे इंगित करो, और अगर तुम्हें पता हो तो बताओ कि यह किस संस्करण से लागू होता है।
अपने आप पर मुझसे ज़्यादा सख्त रहो: "निश्चित" के रूप में ज़्यादा आँका गया कोई दावा मुझे कम आँके गए दावे से ज़्यादा महँगा पड़ता है।यह स्व-ऑडिट कुछ साबित नहीं करता - मॉडल आत्मविश्वासी और गलत हो सकता है - पर यह धाराप्रवाह गद्य को सत्यापन-योग्य तथ्यों की सूची में बदल देता है, हर एक के साथ दस्तावेज़ में उसका प्रवेश-द्वार। सत्यापन आप ही करते हैं; AI ने बस ज़मीन तैयार की। लाल झंडे पहचानना भी सीखें: आपकी ज़रूरत पर बिल्कुल फ़िट कटी हुई कोई API (सच होने के लिए बहुत अच्छी), एक ही स्निपेट में अलग-अलग संस्करणों की परिपाटियों का मिश्रण, बिल्कुल एक-समान आत्मविश्वास - असली विशेषज्ञता कहती है "यह निर्भर करता है"; मतिभ्रम कभी नहीं - और किसी सीमा या किनारे के मामले के ज़िक्र की पूरी अनुपस्थिति। कोई एक संकेत प्रमाण नहीं है, पर हर एक को एक सत्यापन शुरू करा देना चाहिए।
तुमने अभी दावा किया कि [सत्यापित करने योग्य सटीक दावा]।
1. इसे खुद सत्यापित करने के लिए सबसे छोटा संभव टेस्ट डिज़ाइन करने में मेरी मदद करो: बनाने के लिए न्यूनतम फ़ाइल, चलाने के लिए सटीक कमांड, अगर तुम सही हो तो मुझे जो सटीक नतीजा दिखना चाहिए - और अगर तुम गलत हो तो उसके बजाय मुझे क्या दिखेगा।
2. फिर शैतान का वकील बनो: किन मामलों में तुम्हारा दावा गलत होगा? संस्करण, प्लेटफ़ॉर्म, विन्यास, सख्त मोड या नहीं - सब खँगाल डालो।
टेस्ट मैं खुद चलाऊँगा: मुझसे अपनी बात यूँ ही मान लेने को मत कहो, मुझे तुम्हें गलत साबित करने के साधन दो।यह प्रॉम्प्ट रोज़मर्रा के काम पर एक वैज्ञानिक सिद्धांत लागू करता है: कोई दावा तभी कुछ मायने रखता है जब वह खंडनीय हो - जब आप जानते हों कि अगर वह गलत निकले तो आपको क्या दिखेगा। किसी फेंकने लायक फ़ाइल में दस लाइनें और एक बार चलाना हर घोषित आत्मविश्वास स्तर से बेहतर है। दस्तावेज़ से मिलान के लिए, तीन आदतें: अपने संस्करण के दस्तावेज़ में सत्यापित करें (मॉडल किसी API के अलग-अलग युगों को बेधड़क मिला देते हैं), जब व्यवहार बदला हुआ लगे तो चेंजलॉग जाँचें, और हर वक़्त एक REPL या स्क्रैच फ़ाइल खुली रखें - सत्यापन की लागत इतनी कम होनी चाहिए कि इस कदम को छोड़ने का आपके पास कभी कोई बहाना न हो।