नमस्ते 👋
क्या आप यहाँ इसलिए आए हैं क्योंकि आपने Exercism को बेहतर बनाने का कोई सुझाव दिया था, और किसी ने इसके जवाब में आपको यह पोस्ट पढ़ने के लिए भेजा है?
आपके विचार पर समय लगाने से पहले हमारी टीम चाहती है कि आप यह पोस्ट पढ़ें और सोचें कि कहीं यह विचार पहले भी सोचा जा चुका है या नहीं, और उसमें कौन-कौन सी आम गलतियाँ छिपी हो सकती हैं।
अगर आप अपने सुझाव में इन बातों और संभावित आम गलतियों का उल्लेख करें, और यह भी सोचें कि आपका विचार अब तक लागू क्यों नहीं किया गया, तो आपको जवाब जल्दी और ज़्यादा सकारात्मक मिलने की संभावना है।
तो "चेस्टरटन का बाड़" का मतलब क्या है?
चेस्टरटन का बाड़ एक विचार है, जो लेखक जी.के. चेस्टरटन की 1929 की किताब The Thing के एक अंश से प्रेरित है।
जॉन एफ. कैनेडी ने इसे उद्धृत किया, और इसी से यह बहुत प्रसिद्ध हो गया।
यह मूल अंश है:
ऐसी स्थिति में कोई संस्था या कानून होता है; मान लीजिए, सरलता के लिए, सड़क के आर-पार खड़ा कोई बाड़ या फाटक।
आधुनिक किस्म का सुधारक खुशी-खुशी उसके पास जाता है और कहता है, "मुझे इसमें कोई उपयोग नहीं दिखता; चलिए इसे हटा दें।"
इस पर समझदार किस्म का सुधारक यही कहेगा: "अगर आपको इसका उपयोग नहीं दिखता, तो मैं आपको इसे हटाने नहीं दूँगा। जाइए और सोचिए। फिर जब आप लौटकर मुझे बता सकें कि आपको इसका उपयोग दिखता है, तब मैं शायद इसे तोड़ने की अनुमति दूँ।"
चेस्टरटन के बाड़ का विचार यह है कि अगर आपको यह समझ नहीं आता कि कोई चीज़ वहाँ क्यों है, तो शायद आपको यह भी समझ नहीं आता कि उसे हटाया क्यों जाना चाहिए।
इसी तरह, अगर आपको यह समझ नहीं आता कि कोई चीज़ वहाँ क्यों नहीं है, तो शायद आपको यह भी समझ नहीं आता कि उसे छोड़ा क्यों गया है।
याद रखने का एक आसान नियम है: "जब तक आपको यह पता न चले कि बाड़ पहली जगह लगाया ही क्यों गया था, तब तक उसे न हटाइए।"
यह विचार Exercism के लिए कैसे मायने रखता है?
Exercism पर हमारा सौभाग्य है कि बहुत से लोग लगातार हमारे समुदाय से जुड़ते हैं और अपने विचार और सुझाव साझा करते हैं।
इनमें से बहुत से विचार नए, नवीन और रोमांचक होते हैं, और हमारी सोच को आगे बढ़ाते हैं।
इसलिए अगर आपके पास कोई विचार या सुझाव है, तो हम उसका स्वागत करते हैं!
लेकिन अक्सर लोग ऐसे विचार पोस्ट करते हैं जिन पर पहले कई बार चर्चा हो चुकी होती है।
ऐसे विचारों का जवाब देने में, और अपने निर्णयों को बार-बार समझाने या उन्हें फिर से सही ठहराने में हमारी टीम का बहुत समय और ऊर्जा लगती है।
यह लेख उस समय और ऊर्जा को बचाने में मदद करना चाहता है।
Exercism को हज़ारों बेहद प्रतिभाशाली लोगों ने मिलकर डिज़ाइन किया, बनाया और विकसित किया है।
यह बहुत सोच-समझकर बनाया गया प्रोडक्ट है। जो चीज़ें इसमें हैं, वे इसलिए हैं क्योंकि उन्हें वहाँ रखने की योजना बनाई गई थी; और बहुत सी चीज़ें जानबूझकर छोड़ दी गई हैं क्योंकि उन्हें छोड़ने की योजना बनाई गई थी।
Exercism से जुड़ी लगभग हर चीज़ पर कई-कई बार बहस, चर्चा और फिर से काम हुआ है।
इसलिए अपना विचार पोस्ट करने से पहले खुद से पूछिए कि कहीं हम इस पर पहले ही विचार कर चुके हैं या नहीं, और यह कि हमने आपके सुझाव से अलग तरीका क्यों अपनाया होगा।
और याद रखिए, आपका विचार जितना स्पष्ट लगता है, उतनी ही ज़्यादा संभावना है कि उस पर पहले कई बार चर्चा और बहस हो चुकी है। इसलिए जब आप उसे पेश करें, तो साथ में संभावित चेतावनियाँ और आम गलतियाँ भी रखिए।
अगर आपका मन कहता है कि "क्यों न बस यह कर लिया जाए...", तो वह लगभग निश्चित रूप से इसी श्रेणी में आता है।
पोस्ट करने से कभी डरिए मत, लेकिन पहले हर बात अच्छी तरह सोच-समझ लीजिए!
कोई उदाहरण है?
एक आम निराशा यह है कि छात्र मेंटर को ऐसा कोड भेजते हैं जो टेस्ट पास नहीं करता।
उतना ही आम सुझाव यह होता है: "क्यों न कोड सबमिट करने से पहले CLI में टेस्ट अपने आप चला लिए जाएँ?"
यह बहुत अच्छा विचार लगता है। CLI बस एक कमांड चलाकर टेस्ट चला सकता है, और अगर टेस्ट फेल हो रहे हों तो छात्र को सबमिट करने ही नहीं देता।
तो सबसे पहले, "बस एक कमांड चलाकर टेस्ट चलाना" का मतलब क्या है?
इसका मतलब है Exercism की सभी 52 भाषाओं के लिए एक स्क्रिप्ट लिखना, जो टेस्ट चला सके और नतीजा जाँच सके।
यह थोड़ी मेहनत का काम है, लेकिन हो सकता है।
लेकिन इसका यह भी मतलब है कि वह स्क्रिप्ट ऐसी लिखनी होगी जो Windows, MacOSX और Linux पर चले, और वह भी हर संभव वर्शन और कॉन्फ़िगरेशन में। यह काम बहुत बड़ा है, और हो सकता है इसका कोई अंत ही न हो।
आप पूछ सकते हैं, "यह हर कॉन्फ़िगरेशन में क्यों चलना ज़रूरी है?"
क्योंकि अगर कोई इस स्क्रिप्ट को चला नहीं सकता, तो आप उसे Exercism इस्तेमाल करने से सीधे रोक रहे हैं।
इसका मतलब यह भी है कि यह स्क्रिप्ट कभी फेल नहीं होनी चाहिए।
अगर किसी वजह से स्क्रिप्ट नहीं चली, तो छात्र पूरी तरह रुक जाता है।
उन 52*3*n स्क्रिप्ट में से किसी एक में बग का मतलब है कि उस OS पर कोई छात्र उस ट्रैक का इस्तेमाल नहीं कर पाएगा।
ऐसी स्थिति की जाँच आप कैसे करेंगे?
कर ही नहीं सकते।
लेकिन आप कहेंगे कि बस एक --skip-tests फ्लैग जोड़ दीजिए।
यह अच्छा सुझाव है, लेकिन इससे हम वहीं लौट आते हैं जहाँ से शुरू किया था: लोग जब चाहें, टेस्ट छोड़ सकते हैं।
फर्क बस इतना है कि अब ऐसा कम होता है कि फेल होते टेस्ट सबमिट किए जाएँ, इसलिए मेंटर भी इसकी उम्मीद कम रखते हैं। और जब टेस्ट सचमुच फेल होते हैं, तो यह ज़्यादा चौंकाने वाला और उलझाने वाला लगता है।
आप कह सकते हैं, "लेकिन आम तौर पर लोग ऐसा नहीं करेंगे।" यह सच है, उन भाषाओं के लिए जहाँ टेस्ट चलाने में 0.5 सेकंड लगते हैं। लेकिन जिन भाषाओं में टेस्ट चलाने में 20 सेकंड लगते हैं, उनमें सबमिट करने के लिए 20 सेकंड अतिरिक्त इंतज़ार करना छात्रों के लिए बेहद निराशाजनक होता है, और इसलिए आखिरी टेस्ट छोड़ देना आम बात हो जाएगी।
यह बातचीत चाहे कहीं भी पहुँचे, यह साफ़ है कि इसमें पहली नज़र में लगने से कहीं ज़्यादा जटिलता है। यहाँ तकनीकी चुनौतियाँ हैं जिन पर विचार करना है, वर्कफ्लो की दिक्कतें हैं जिन्हें सोचना है, और यह एहसास भी है कि ट्रैक एक-दूसरे से इतने अलग हैं कि जो चीज़ एक के लिए तेज़ और आसान है, वही दूसरे के लिए कठिन बन जाती है।
तो "सबमिट करने से पहले टेस्ट क्यों न चला लिए जाएँ" का सुझाव देने के बजाय, चलिए एक सवाल पूछते हैं: "लोग ऐसे हल क्यों पोस्ट करते हैं जो टेस्ट पास नहीं करते?"
और तब बात दिलचस्प हो जाती है।
आम जवाब यह है कि वे अटके हुए या उलझे हुए हैं।
और उन्हें मदद चाहिए।
इसका मतलब है कि फेल होते टेस्ट सबमिट करना मेंटर के लिए एक बहुत ज़रूरी संकेत होता है कि इस छात्र को मदद की ज़रूरत है।
हाँ, यह निराशाजनक है क्योंकि मेंटर को तुरंत पता नहीं चलता कि कोड "सही" है या नहीं। लेकिन वे कोड डाउनलोड करके चला सकते हैं और जाँच सकते हैं (ज़्यादातर मेंटर जटिल हलों पर ऐसा ही करते हैं), और फिर 100% निश्चय के साथ जान सकते हैं कि यह सही है या नहीं।
और जो छात्र अटके हुए हैं और जिन्हें मदद चाहिए, वे और ज़्यादा अटककर और ज़्यादा मदद माँगते हुए नहीं रह जाते, बल्कि ऐसे मेंटर तक पहुँच जाते हैं जो उनकी गलतियाँ जल्दी देखकर सुधार सुझा सकता है।
नोट: हम सचमुच इस समस्या को सर्वर पर टेस्ट चलाकर हल कर रहे हैं। यह बड़ा और महँगा काम है, लेकिन छात्रों के बेहतर अनुभव के लिए, और सबसे ज़रूरी बात, अपने मेंटरों का समय और ऊर्जा बचाने के लिए यह मेहनत के लायक है।
और कुछ?
तीन बातें:
-
Second Order Thinking में यह लेख पढ़ने लायक है। "जब तक आपको यह पता न चले कि बाड़ पहली जगह लगाया ही क्यों गया था, तब तक उसे न हटाइए" वाला अंश इसी पोस्ट से है।
- जी.के. चेस्टरटन की किताब The Thing यहाँ उपलब्ध है: https://archive.org/details/G.K.ChestertonTheThing.
- हो सकता है आपका विचार सचमुच नया और शानदार हो। इसे सुझाने में डरिए या झिझकिए मत!
