चार सबसे आम कार्य: कोडबेस एक्सप्लोर करना, बग फिक्स करना, रीफैक्टरिंग, टेस्ट लिखना
📚 सीरीज़ नेविगेशन: पिछला लेख [15 कैसे प्रश्न पूछें और निर्देश दें] आपको सिखाता है कि "बात कैसे की जाए" — अस्पष्ट मांगों (requirements) को सटीक निर्देशों (instructions) में कैसे तोड़ा जाए। यह लेख दृष्टिकोण बदलता है: दैनिक काम का 80% हिस्सा केवल चार प्रकार का होता है, और मैं आपको प्रत्येक प्रकार के लिए एक निर्देश टेम्पलेट (instruction template) दूँगा जिसे सीधे कॉपी किया जा सकता है, और बस रिक्त स्थान भरकर उपयोग किया जा सकता है।
दोस्तों, आज हम कुछ बहुत ही व्यावहारिक बात करने जा रहे हैं।
ज़रा सोचिए, आप रोज़ाना अपने कोड के साथ क्या करते हैं? सरल शब्दों में कहें तो, हम बार-बार चार ही काम करते हैं: एक ऐसे प्रोजेक्ट को समझना जो हमारी समझ से बाहर है, एक अजीबोगरीब बग (bug) को फिक्स करना, एक गंदे कोड को साफ़ करने के लिए रीफैक्टर (refactor) करना, या किसी फ़ंक्शन के लिए टेस्ट (test) लिखना। निश्चित रूप से अन्य आवश्यकताएं भी होती हैं, लेकिन ये चार काम हमारे दैनिक समय का सबसे बड़ा हिस्सा ले लेते हैं।
पिछले लेख में "बोलने के कौशल (speaking skills)" पर चर्चा की गई थी, इस लेख में हम विशिष्ट परिदृश्यों पर ध्यान देंगे — इन चार प्रकार के कार्यों का अपना एक मानक तरीका (standard approach) होता है, और इसके पैटर्न तय होते हैं। Claude Code का लंबे समय तक उपयोग करने के बाद, चार टेम्पलेट बच जाते हैं, जिन्हें आप अपने नोट्स में सेव कर सकते हैं और आवश्यकता पड़ने पर सीधे उपयोग कर सकते हैं।
इसे इस तरह समझिए: सामान्य कौशल आपके आधारभूत कौशल (inner strength) हैं, और ये चार टेम्पलेट आपके हथियार (moves) हैं। आपने आधारभूत कौशल का अभ्यास कर लिया है, आज मैं आपको हथियार दे रहा हूँ।
इस लेख को पढ़ने के बाद, आपको मिलेगा:
- चार उच्च-आवृत्ति कार्यों (खोज / बग फिक्स / रीफैक्टरिंग / टेस्ट लिखना) में से प्रत्येक के लिए सीधे कॉपी करने योग्य निर्देश टेम्पलेट (instruction template)
- प्रत्येक श्रेणी के लिए महत्वपूर्ण तर्क कि "ऐसा क्यों टाइप करें", ताकि आप सिर्फ टेम्पलेट को रटें नहीं
- चार प्रकार के कार्यों के लिए एक त्वरित संदर्भ कार्ड (quick reference card), जिसे आप सहेज सकते हैं और कभी भी उपयोग कर सकते हैं
- एक पूर्ण व्यावहारिक अभ्यास (हैंड्स-ऑन) जिसे आप रन करके देख सकते हैं और जिसका अपेक्षित आउटपुट दिया गया है (हम एक वास्तविक बग को फिक्स करने की प्रक्रिया से गुजरेंगे)
01 पहले यह पहचानें: चार प्रकार के काम, चार उपकरण
शुरू करने से पहले, इन चार प्रकार के कार्यों की "प्रकृति (nature)" को स्पष्ट रूप से समझना होगा। वे Claude से अलग-अलग चीजें मांगते हैं, यदि आप गलत पैटर्न का उपयोग करते हैं, तो परिणाम बहुत खराब होंगे।
उपमा: आपके टूलबॉक्स में चार उपकरण हैं, प्रत्येक के उपयोग को पहचानें। पेचकस (screwdriver) का उपयोग पेंच कसने के लिए किया जाता है, रिंच (wrench) का उपयोग नट कसने के लिए किया जाता है, यदि आप पेंच कसने के लिए रिंच का उपयोग करेंगे तो यह अजीब लगेगा। अन्वेषण (Exploration), बग फिक्स, रीफैक्टरिंग, टेस्ट लिखना, ये चार अलग-अलग उपकरण हैं — मुख्य बात यह नहीं है कि "Claude का उपयोग कैसे करें", बल्कि यह है कि "इस काम के लिए कौन सा उपकरण निकालें"।
उनके बीच सबसे मुख्य अंतर एक ही आयाम पर निर्भर करता है: क्या यह कार्य आपके कोड को बदलता है (modify)?
| काम | क्या कोड बदलता है? | Claude मुख्य रूप से क्या करता है? | आपको किस पर सबसे ज्यादा ध्यान देना चाहिए? |
|---|---|---|---|
| कोडबेस एक्सप्लोर करना | नहीं बदलता (केवल पढ़ने के लिए) | फ़ाइलें पढ़ता है, आपको समझाता है | क्या वह सही समझा रहा है |
| बग फिक्स करना | बदलता है | मूल कारण (root cause) खोजना + फिक्स करना | क्या मूल कारण सही मिला, क्या रिग्रेशन टेस्ट (regression test) है |
| रीफैक्टरिंग | बदलता है (लेकिन व्यवहार नहीं बदलता) | समतुल्य पुनर्लेखन (Equivalent rewrite) | क्या बदलाव के बाद व्यवहार (behavior) बदल गया है |
| टेस्ट लिखना | फ़ाइल जोड़ता है | टेस्ट जेनरेट करना + सीमा स्थितियों (edge cases) को कवर करना | क्या सीमा स्थितियों (edge cases) को पूरी तरह कवर किया गया है |
क्या आपने पैटर्न देखा? अन्वेषण (Exploration) शून्य-जोखिम (zero-risk) है (यह केवल पढ़ता है, लिखता नहीं है), इसलिए आप निडर होकर पूछ सकते हैं; बग फिक्स करना और रीफैक्टरिंग कोड को बदलते हैं (surgery), इसलिए काम शुरू करने से पहले इसे स्पष्ट रूप से समझाना होगा; टेस्ट लिखना इन दोनों के बीच का है, यह नई फ़ाइलें बनाता है और आपके मौजूदा कोड को नहीं छूता है, लेकिन आपको यह सुनिश्चित करना होगा कि यह केवल "सामान्य (normal)" स्थितियों का परीक्षण करने में आलस न करे।
इस टेबल के निर्णय तर्क को याद रखें, निम्नलिखित चार अनुभाग बताएंगे कि प्रत्येक उपकरण को कैसे पकड़ना है।
💡 संक्षेप में: चार प्रकार के कार्यों को पहले इस आधार पर अलग करें कि वे "कोड बदलते हैं या नहीं" — अन्वेषण (Exploration) शून्य-जोखिम है इसलिए स्वतंत्र रूप से पूछें, जिन कार्यों में कोड में बदलाव होता है, उनके लिए पहले उसे समझाएं और फिर उसे बदलने दें।
02 अपरिचित कोडबेस को एक्सप्लोर करना: बड़े से छोटे की ओर, तीन स्तरों पर पूछें
आइए सबसे उच्च-आवृत्ति वाले परिदृश्य से शुरू करें: आप एक पूरी तरह से अपरिचित प्रोजेक्ट को हाथ में लेते हैं, और पहली बात यह है कि इसे समझना है।
पहले यह काम कैसे किया जाता था? फ़ोल्डर खोलें, दर्जनों डायरेक्टरीज़ को देखकर भ्रमित हों, एक-एक करके उन पर क्लिक करें, दो घंटे देखने के बाद भी कुछ समझ न आएं। अब आपको ऐसा करने की आवश्यकता नहीं है — Claude Code वर्तमान डायरेक्टरी को एक कार्यक्षेत्र (workspace) के रूप में मानता है, यह संपूर्ण प्रोजेक्ट को पढ़ सकता है, आपको बस प्रश्न पूछने हैं।
उपमा: किसी नई कंपनी में शामिल होने पर, आप सीधे किसी मॉड्यूल के सोर्स कोड में गोता नहीं लगाते, बल्कि आप पुराने कर्मचारियों से तीन स्तरों पर पूछते हैं। पहला स्तर: "हमारी कंपनी कुल मिलाकर क्या करती है, बड़ा आर्किटेक्चर कैसा है?"; दूसरा स्तर: "भुगतान (payment) को संभालने वाला कोड कहाँ है?"; तीसरा स्तर: "ऑर्डर देने से लेकर पैसे कटने तक, कोड का फ्लो कैसे चलता है?"। बड़े से छोटे की ओर, सतह से बिंदु की ओर, यह अन्वेषण (exploration) की मानक लय है।
आधिकारिक दस्तावेज़ के प्रदर्शन के अनुसार, ये तीन स्तर तीन प्रकार के प्रश्नों के अनुरूप हैं:
मुझे इस कोडबेस का समग्र अवलोकन (overall overview) दें, इसके मुख्य आर्किटेक्चरल पैटर्न (architectural patterns) बताएंयूजर ऑथेंटिकेशन (user authentication) के लिए जिम्मेदार कोड किन फ़ाइलों में है? ये फ़ाइलें एक साथ कैसे काम करती हैं?लॉगिन फ्लो (login flow) को ट्रेस (trace) करें, फ्रंटएंड (frontend) से लेकर डेटाबेस (database) तक यह कैसे चलता हैएक सुरक्षित आदत यह है कि पहले दो स्तरों को हमेशा Plan Mode (योजना मोड) में पूछें — यानी, शुरू करने से पहले Shift+Tab को दो बार दबाकर प्लान मोड (Plan Mode) में स्विच करें (पहली बार acceptEdits में जाएगा, दूसरी बार plan में जाएगा)। ऐसा क्यों? क्योंकि एक्सप्लोर करने के चरण में हम केवल चाहते हैं कि वह पढ़े और समझाए, हम नहीं चाहते कि वह उत्साहित हो जाए और फ़ाइलों को बदलना शुरू कर दे। Plan Mode के तहत, यह आपके सोर्स कोड (source code) को नहीं छुएगा, चाहे आप कितना भी पूछें, यह आपके कोड की एक लाइन भी नहीं बदलेगा।
उदाहरण के लिए, 30,000 लाइनों वाले एक पुराने Go प्रोजेक्ट को लेने पर, आप पहले दिन ऐसा कर सकते हैं: पहले यह जानने के लिए कि इसे कितनी सेवाओं (services) में विभाजित किया गया है, "समग्र अवलोकन (overall overview)" पूछें, फिर "X के लिए जिम्मेदार कोड कहाँ है" पूछकर एक-एक करके पता लगाएँ, और अंत में "यह रिक्वेस्ट (request) कैसे चलती है" ट्रेस करने के लिए कोर लिंक्स (core links) चुनें। आधे दिन में आपको समझ आ जाएगा, जबकि पहले इसमें दो से तीन दिन लग जाते थे।
यहाँ आपको सीधे अन्वेषण (Exploration) टेम्पलेट दिया गया है, बस कीवर्ड (keywords) भरें और इसका उपयोग करें:
मैंने अभी इस प्रोजेक्ट को हाथ में लिया है, इसे जल्दी से समझने में मेरी मदद करें। इसे तीन चरणों में करें:
1. मुझे समग्र आर्किटेक्चर अवलोकन (overall architecture overview) दें, मुख्य मॉड्यूल (modules) और उनकी जिम्मेदारियों को स्पष्ट करें
2. [वह सुविधा जिसकी आप परवाह करते हैं, जैसे 'ऑर्डर पेमेंट'] के लिए जिम्मेदार कोड किन फ़ाइलों में है
3. [एक विशिष्ट कोर फ्लो, जैसे 'ऑर्डर बनाने से लेकर भुगतान तक'] के संपूर्ण निष्पादन पथ (execution path) को ट्रेस करें
इसे इस तरह समझाएं जिसे एक शुरुआती समझ सके, अभी कोई कोड न बदलें।💡 संक्षेप में: अन्वेषण (Exploration) की केवल एक लय है — बड़े आर्किटेक्चर (architecture) से लेकर विशिष्ट फ़ाइलों तक और फिर एग्जीक्यूशन लिंक (execution link) तक, बड़े से छोटे की ओर तीन स्तरों पर पूछें, पहले दो स्तरों को Plan Mode में पूछना सबसे सुरक्षित है।
03 बग (Bug) फिक्स करना: एरर पेस्ट करें → मूल कारण खोजें → फिक्स करें → रिग्रेशन टेस्ट (regression test) जोड़ें
बग फिक्स करना एक और उच्च-आवृत्ति वाला काम है, और यह वह काम भी है जिसमें गड़बड़ी होने का खतरा सबसे ज्यादा होता है।
इसमें गड़बड़ी होने की संभावना क्यों है? क्योंकि शुरुआती लोग अक्सर जो गलती करते हैं वह यह है: एक एरर पेस्ट कर देते हैं और "इसे फिक्स करने में मदद करें" कह देते हैं, और फिर Claude आपको एक ऐसा फिक्स (fix) दे देता है "जिससे एरर गायब हो जाता है"। ध्यान दें, "एरर गायब होना" का मतलब "समस्या का हल होना" नहीं है — बहुत बार यह सिर्फ लक्षणों (symptoms) को छिपा देता है, मूल कारण (root cause) अभी भी वहीं रहता है, और अगली बार यह फिर से उभर आता है।
उपमा: शरीर में दर्द होने पर डॉक्टर के पास जाना। आप क्लिनिक में जाकर यह नहीं कहते, "मुझे कुछ दर्द निवारक दवाएँ दे दो", आप स्पष्ट करते हैं कि "कहाँ दर्द है, यह कब शुरू हुआ, और कौन सी हरकतों से यह बदतर हो जाता है", ताकि डॉक्टर पहले कारण का निदान करे, और फिर दवा लिखे। बग फिक्स करना भी बिल्कुल वैसा ही है — पहले उसे मूल कारण खोजने दें, उसे जल्दी से "दर्द निवारक" देने के लिए मत कहें।
आधिकारिक सर्वोत्तम अभ्यास (best practices) में बार-बार एक सुनहरे नियम (iron rule) पर जोर दिया गया है, जिसे आपको याद रखना चाहिए:
इसे फिक्स करें और पुष्टि करें कि बिल्ड (build) सफल है। मूल कारण (root cause) को हल करें, एरर को दबाएं नहीं।
इसलिए, बग को फिक्स करने का सही फ्लो (flow) चार चरणों वाला है, जिनमें से एक भी छूट नहीं सकता:
- एरर पेस्ट करें + स्टेप्स टू रिप्रोड्यूस (steps to reproduce): पूर्ण एरर संदेश, स्टैक ट्रेस (stack trace), और साथ में "मैंने ऐसा क्या किया जिससे यह ट्रिगर हुआ"
- उसे मूल कारण (root cause) ढूँढने दें: उसे तुरंत कोड बदलने मत दें, उसे समझाने दें कि "यह क्यों फेल हुआ"
- फिक्स (fix) प्रदान करें: जब मूल कारण सही हो, तभी उसे फिक्स लागू करने दें
- रिग्रेशन टेस्ट (regression test) जोड़ें: एक ऐसा टेस्ट जोड़ें जो इस बग को रिप्रोड्यूस कर सके, यह सुनिश्चित करने के लिए कि यह फिर कभी न हो
चौथा चरण वह है जिसे शुरुआती लोग सबसे आसानी से भूल जाते हैं, लेकिन यह सबसे मूल्यवान चरण है। आधिकारिक सुझाव बहुत शानदार है: Claude से "एक ऐसा फेलिंग टेस्ट (failing test) लिखने के लिए कहें जो समस्या को रिप्रोड्यूस करे, और फिर उसे फिक्स करें" — इस तरह, जब फिक्स लागू हो जाता है, तो टेस्ट अपने आप हरा (green) हो जाता है, जिसका मतलब है कि आपने इस बग पर एक ताला लगा दिया है। अगर भविष्य में कोई गलती से इसे फिर से बदल देता है, तो टेस्ट तुरंत आपको अलर्ट कर देगा।
कई लोगों ने इससे नुकसान उठाया है। उदाहरण के लिए, एक डेट-पार्सिंग (date-parsing) बग को फिक्स करना, उस समय Claude ने इसे जल्दी से ठीक कर दिया, और जब एरर गायब हो गया, तो इसे कमिट (commit) कर दिया गया। दो हफ्ते बाद, एक अन्य सहकर्मी ने रीफैक्टरिंग (refactoring) के दौरान उस लाइन को वापस बदल दिया, और वही बग फिर से ज़िंदा हो गया — क्योंकि शुरू में कोई टेस्ट नहीं जोड़ा गया था, इसलिए किसी को नहीं पता था कि उस लाइन को नहीं छुआ जाना चाहिए। इसलिए, किसी भी बग को फिक्स करते समय चौथा चरण शामिल होना चाहिए।
यहाँ आपको सीधे बग फिक्स टेम्पलेट दिया गया है:
मुझे एक बग का सामना करना पड़ा है।
एरर मैसेज: [एरर और स्टैक (stack) को पूरी तरह पेस्ट करें]
पुनरुत्पादन के चरण (Steps to reproduce): [मैंने इसे ट्रिगर करने के लिए क्या किया, क्या यह कभी-कभार होता है या हमेशा होता है]
कृपया आप:
1. पहले मूल कारण (root cause) का पता लगाएँ, समझाएँ कि एरर क्यों हुआ, अभी कोड में बदलाव न करें
2. मुझे एक फिक्स (fix) प्रदान करें जो मूल कारण को हल करे, केवल एरर को छुपाए नहीं
3. बदलाव करने के बाद, एक रिग्रेशन टेस्ट (regression test) जोड़ें जो इस बग को रिप्रोड्यूस कर सके, और पुष्टि करने के लिए इसे रन करें कि यह पास हो गया है💡 संक्षेप में: बग फिक्स करने के चार चरण — एरर और रिप्रोड्यूस स्टेप्स पेस्ट करें, पहले मूल कारण ढूँढें, फिर बदलाव करें, और अंत में रिग्रेशन टेस्ट जोड़ें; रिग्रेशन टेस्ट के इस ताले के बिना, वही बग कभी न कभी फिर से ज़िंदा हो जाएगा।
04 रीफैक्टरिंग (Refactoring): पहले वर्तमान स्थिति समझाएं → लक्ष्य निर्धारित करें → छोटे-छोटे बदलाव करें → बदलाव से पहले और बाद में टेस्ट करें
रीफैक्टरिंग का काम, सबसे ज़्यादा जोखिम भरा होता है, क्योंकि यह "ऐसे कोड को बदलता है जो टूटा नहीं है"।
बग फिक्स करने में कम से कम एक स्पष्ट "यह फिक्स हो गया" मानक (standard) होता है — एरर चला गया, टेस्ट हरे (green) हो गए। रीफैक्टरिंग में ऐसा कोई मानक नहीं है, रीफैक्टरिंग का लक्ष्य है "कोड साफ़ हो, लेकिन व्यवहार (behavior) में एक भी शब्द का बदलाव नहीं होना चाहिए"। एक बार जब व्यवहार बदल जाता है, तो इसका मतलब है कि आप चुपके से रीफैक्टरिंग के नाम पर एक बग पेश कर रहे हैं, यह सबसे खतरनाक प्रकार का बग है, क्योंकि कोई भी ऐसे कोड का परीक्षण करने नहीं जाएगा जिसे "केवल साफ़ किया गया है"।
उपमा: किसी ऐसे घर का नवीनीकरण (renovation) करना जिसमें लोग रह रहे हों, लेकिन निवासियों को बाहर निकाले बिना। आपको यह सुनिश्चित करना होगा कि पानी और बिजली सामान्य रूप से काम करें, लोग वहीं रहें, और आप बस दीवारों को पेंट करें और तारों को व्यवस्थित करें। रीफैक्टरिंग "रहने वालों के साथ नवीनीकरण करना" है — सुविधा (कार्यक्षमता) पूरी प्रक्रिया के दौरान अप्रभावित रहनी चाहिए।
इसलिए, रीफैक्टरिंग का सुरक्षित तरीका चार चरणों वाला है, जिसका मुख्य आधार यह है कि "व्यवहार को टेस्ट (tests) के साथ लॉक कर दें":
- पहले इसे वर्तमान स्थिति समझाने दें: समझें कि यह कोड वास्तव में अभी क्या कर रहा है, और इसके छिपे हुए व्यवहार (hidden behaviors) क्या हैं
- रीफैक्टरिंग लक्ष्य (Refactoring goal) स्पष्ट करें: क्या आप "फ़ंक्शन को विभाजित करना चाहते हैं", "आधुनिक सिंटैक्स (syntax) का उपयोग करना चाहते हैं", या "डुप्लिकेट (duplicates) हटाना चाहते हैं"? विशिष्ट रहें
- छोटे-छोटे बदलाव करें: आधिकारिक तौर पर स्पष्ट रूप से "छोटे, परीक्षण योग्य वृद्धिशील (incremental) बदलावों के साथ रीफैक्टरिंग" की सिफारिश की जाती है, उसे एक ही बार में सब कुछ दोबारा लिखने (rewrite) न दें
- बदलाव से पहले और बाद में दोनों टेस्ट पास होने चाहिए: रीफैक्टरिंग से पहले एक आधार (baseline) के रूप में एक बार टेस्ट रन करें, फिर बदलाव के बाद फिर से रन करें, दोनों परिणाम बिल्कुल समान होने चाहिए
चौथा चरण रीफैक्टरिंग का जीवनरक्षक (lifeblood) है। यदि इस कोड का अभी कोई टेस्ट नहीं है, तो रीफैक्टरिंग का पहला चरण इसे बदलना नहीं है, बल्कि पहले टेस्ट जोड़ना है — "वर्तमान व्यवहार" का स्नैपशॉट (snapshot) लेने के लिए टेस्ट का उपयोग करें, रीफैक्टरिंग के बाद, इसकी तुलना स्नैपशॉट से करें, और यदि व्यवहार नहीं बदला है, तभी इसे सफल माना जाता है। यह आधिकारिक सर्वोत्तम अभ्यास (best practices) के बिल्कुल अनुरूप है: Claude को अपने काम को सत्यापित करने का एक तरीका दें, अन्यथा "सही दिखना" ही एकमात्र संकेत रह जाएगा, और एक रीफैक्टरिंग जो सही दिखती है, उसमें सबसे आसानी से छिपे हुए खतरे हो सकते हैं।
यहाँ एक सख्त नियम है जिसका पालन किया जाना चाहिए: बिना टेस्ट कवरेज वाले कोड को Claude को सीधे रीफैक्टर करने न दें। ज़रा उस परिदृश्य की कल्पना करें जहाँ आप जल्दी में हैं और उसे बिना टेस्ट वाले उपयोगिता फ़ंक्शन (utility function) को रीफैक्टर करने के लिए कहते हैं, वह एक बाउंड्री ब्रांच (boundary branch) को "अनुकूलित (optimize)" कर देता है — वह ब्रांच बेकार कोड (dead code) की तरह दिखती है, लेकिन वास्तव में एक दुर्लभ इनपुट (rare input) को हैंडल करती है। यह उत्पादन (production) में जा कर ही फटेगा। हमेशा रीफैक्टरिंग से पहले टेस्ट जोड़ें, इसमें थोड़ा अधिक समय लगता है, लेकिन आप फिर कभी दुर्घटना का शिकार नहीं होंगे।
यहाँ आपको सीधे रीफैक्टरिंग टेम्पलेट दिया गया है:
मैं [फ़ाइल / फ़ंक्शन का नाम] को रीफैक्टर (refactor) करना चाहता हूँ।
रीफैक्टरिंग लक्ष्य: [विशिष्ट रहें, जैसे "छोटे फ़ंक्शन्स में विभाजित करें", "आधुनिक सिंटैक्स में बदलें", "डुप्लिकेट हटाएं"]
आवश्यकताएँ:
1. पहले समझाएँ कि यह कोड वर्तमान में क्या कर रहा है, जिसमें आसानी से छूट जाने वाली सीमा स्थितियाँ (edge cases) भी शामिल हों
2. यदि इसका अभी कोई टेस्ट नहीं है, तो पहले मौजूदा व्यवहार को कवर करने वाला टेस्ट (test) जोड़ें
3. छोटे-छोटे चरणों में रीफैक्टरिंग करें, बाहरी व्यवहार को पूरी तरह से अपरिवर्तित (unchanged) रखें
4. रीफैक्टरिंग से पहले और बाद में टेस्ट रन करें, और पुष्टि करें कि परिणाम सुसंगत (consistent) हैं💡 संक्षेप में: रीफैक्टरिंग का जीवनरक्षक यह है कि "व्यवहार नहीं बदलना चाहिए" — पहले वर्तमान स्थिति को समझाएं, फिर लक्ष्य निर्धारित करें, छोटे-छोटे बदलाव करें, और व्यवहार को लॉक करने के लिए ऐसे टेस्ट का उपयोग करें जो बदलाव से पहले और बाद में दोनों पास हों; यदि कोई टेस्ट नहीं है, तो काम शुरू करने से पहले टेस्ट जोड़ें।
05 टेस्ट लिखना: मुख्य बात यह है कि इसे सीमा स्थितियों (edge cases) को कवर करने के लिए मजबूर किया जाए
अंतिम प्रकार: कोड में टेस्ट (tests) जोड़ना।
टेस्ट लिखने का काम Claude के लिए वास्तव में बहुत आसान है — वह आपके मौजूदा टेस्ट फ़ाइलों को देखेगा, और आपके द्वारा पहले से उपयोग किए जा रहे फ्रेमवर्क (framework) और असर्शन (assertion) शैली का पालन करते हुए लिखेगा, शैली स्वचालित रूप से मेल खाएगी, आपको उसे सिखाने की आवश्यकता नहीं है। लेकिन एक बात आपको जाननी चाहिए: यदि आप विशेष रूप से नहीं बताते हैं, तो वह डिफ़ॉल्ट रूप से केवल "सामान्य (normal)" स्थितियों का परीक्षण करेगा।
केवल सामान्य स्थितियों का परीक्षण करने का क्या मतलब है? उदाहरण के लिए, एक विभाजन (division) फ़ंक्शन, यह परीक्षण करेगा कि "6 को 2 से भाग देने पर 3 आता है" — यह सही है, लेकिन 0 से भाग देने पर क्या होगा? नकारात्मक (negative) संख्या पास करने पर क्या होगा? यदि आप शून्य (null) पास करते हैं तो क्या होगा? ये "सीमा स्थितियाँ (edge cases)" वे जगहें हैं जहाँ वास्तव में बग होते हैं, और जहाँ टेस्ट को सबसे अधिक कवर करना चाहिए।
उपमा: यदि आप किसी उत्पाद की गुणवत्ता (quality) की जांच करने के लिए किसी को काम पर रखते हैं, तो आप उसे केवल "सामान्य संचालन" का परीक्षण करने के लिए नहीं कह सकते। वास्तव में मूल्यवान गुणवत्ता निरीक्षण वह है जो उन इनपुट (input) का परीक्षण करता है जो "गड़बड़" कर सकते हैं — खाली, बहुत लंबा, नकारात्मक, और अजीब वर्ण (characters)। समस्याएं हमेशा सीमाओं (boundaries) पर आती हैं, सामान्य पथ (normal path) पर नहीं। टेस्ट लिखने का मूल आधार Claude को इन सीमाओं का परीक्षण करने के लिए मजबूर करना है।
इसलिए टेस्ट लिखने के टेम्पलेट की कुंजी केवल एक वाक्य है: इसे स्पष्ट रूप से सीमा स्थितियों (edge cases) को कवर करने के लिए कहें। आधिकारिक सर्वोत्तम अभ्यास (best practices) में यह अच्छा संकेत (prompt) दिया गया है — स्पष्ट रूप से बताएं कि "किस फ़ंक्शन का परीक्षण करना है, किन परिदृश्यों का परीक्षण करना है, और क्या मॉक (mock) करना है":
foo.py के लिए एक टेस्ट लिखें, जिसमें उस सीमा स्थिति (edge case) को कवर किया गया हो जहाँ उपयोगकर्ता लॉग आउट हो चुका है। मॉक (mock) करने से बचें।
दो पूछने के तरीकों की तुलना करें, और अंतर स्पष्ट है:
| ❌ अस्पष्ट तरीका | ✅ सटीक तरीका |
|---|---|
| "इस फ़ंक्शन के लिए टेस्ट लिखें" | "divide फ़ंक्शन के लिए टेस्ट लिखें, 0, नकारात्मक संख्या, और गैर-संख्या इनपुट (non-number input) जैसी सीमा स्थितियों को कवर करने पर ध्यान दें" |
| यह केवल सामान्य पथ (normal path) का परीक्षण करता है, जिससे कवरेज (coverage) कृत्रिम रूप से उच्च (artificially high) हो जाता है | यह वास्तव में उन सभी स्थानों का परीक्षण करता है जो टूट (break) सकते हैं |
एक और छोटी सी तरकीब: @ का उपयोग करके उस लक्ष्य फ़ाइल (target file) को सीधे पॉइंट करें (जैसे @src/utils/math.py), यह काम शुरू करने से पहले पूरी फ़ाइल पढ़ेगा, जो कि आपके द्वारा "उस मैथ (math) फ़ाइल में मौजूद डिवाइड (divide) फ़ंक्शन" शब्दों में समझाने से कहीं अधिक सटीक है। @ का संदर्भ (reference) पिछले अध्यायों में समझाया गया था, और यह यहाँ बहुत काम आता है।
यहाँ आपको सीधे टेस्ट लिखने का टेम्पलेट दिया गया है:
@[फ़ाइल का पथ (File path)] में [फ़ंक्शन का नाम (Function name)] के लिए टेस्ट (test) लिखें।
आवश्यकताएँ:
1. प्रोजेक्ट में मौजूदा टेस्ट फ्रेमवर्क (test framework) और असर्शन (assertion) शैली का पालन करें
2. सीमा स्थितियों (edge cases) को कवर करने पर ध्यान दें: [वे स्थितियां जो आप सोच सकते हैं, जैसे "खाली इनपुट, शून्य, नकारात्मक संख्या, बहुत बड़ा मूल्य, गलत प्रकार" सूचीबद्ध करें]
3. मुझे यह सोचने में भी मदद करें कि ऐसी कौन सी सीमा स्थितियां हो सकती हैं जो मैंने सूचीबद्ध नहीं की हैं, और उनका भी परीक्षण करें
4. लिखने के बाद इसे एक बार रन करें, और यदि यह फेल हो जाता है तो इसे पास होने तक ठीक (fix) करेंतीसरा बिंदु एक अतिरिक्त तरकीब (trick) है — सक्रिय रूप से उसे छूटे हुए टेस्ट खोजने के लिए कहें। आधिकारिक दस्तावेज़ में यह भी उल्लेख किया गया है कि Claude कोड पथ (code paths) का विश्लेषण कर सकता है और उन सीमाओं को खोज सकता है जिन्हें आप भूल गए होंगे। जब आप टेस्ट लिखते हैं तो यह वाक्य लगभग हमेशा शामिल होना चाहिए, वह अक्सर उन इनपुट संयोजनों (input combinations) को ढूंढता है जिनके बारे में आपने सोचा भी नहीं था, जो अकेले सूचीबद्ध करने से कहीं अधिक है।
💡 संक्षेप में: टेस्ट लिखते समय केवल "टेस्ट लिखें" न कहें — स्पष्ट रूप से उसे सीमा स्थितियों (जैसे खाली मान, शून्य, नकारात्मक संख्या, प्रकार त्रुटियां) को कवर करने के लिए मजबूर करें, और फिर उसे आपके लिए उन सीमाओं को खोजने दें जिनके बारे में आपने नहीं सोचा था, सामान्य पथ (normal path) वास्तव में सबसे कम महत्वपूर्ण है।
06 हैंड्स-ऑन: एक वास्तविक बग (bug) लें और फिक्सिंग प्रक्रिया को चलाएं
केवल टेम्पलेट देखने से आप इसे नहीं सीख पाएंगे, आपको इसे एक बार चलाना होगा। नीचे, हम हैंड्स-ऑन अभ्यास के लिए "बग फिक्स (bug fix)" का उपयोग करेंगे — इसके चार चरण सबसे पूर्ण (complete) हैं, यदि आप इसे सफलतापूर्वक चलाते हैं, तो आप स्वाभाविक रूप से अन्य तीन को लागू करना जान जाएंगे। यहाँ विशेष रूप से आपके लिए एक वास्तविक बग (bug) डाला गया है जिसे आपको फिक्स करना है।
पहला कदम: एक बग के साथ एक टॉय प्रोजेक्ट (toy project) बनाएं (Mac / Linux)
mkdir bug-demo
cd bug-demo
echo 'def average(numbers):
return sum(numbers) / len(numbers)' > calc.pyWindows उपयोगकर्ता: mkdir और cd वैसा ही टाइप करें, calc.py को नोटपैड का उपयोग करके बनाएं, और उसमें उपरोक्त दो पंक्तियों (Python) को पेस्ट करें।
यह average फ़ंक्शन औसत (average) की गणना करता है, और इसमें कोई समस्या नहीं लगती — लेकिन यदि आप एक खाली सूची (empty list) पास करते हैं, तो यह 0 से विभाजित होगा और क्रैश हो जाएगा। यही वह बग है जिसे हमें फिक्स करना है।
अपेक्षित परिणाम: bug-demo फ़ोल्डर में एक calc.py फ़ाइल होगी, जिसमें average फ़ंक्शन की दो पंक्तियाँ होंगी।
दूसरा कदम: Claude Code शुरू करें
claudeअपेक्षित परिणाम: एक वेलकम स्क्रीन (welcome screen) दिखाई देगी, जिसके नीचे एक इनपुट बॉक्स होगा।
तीसरा कदम: बग फिक्स टेम्पलेट का उपयोग करें, एरर पेस्ट करें और उसे इसे फिक्स करने के लिए कहें
इनपुट बॉक्स में टाइप करें (यह अध्याय 03 में दिए गए टेम्पलेट को भरा हुआ रूप है):
मुझे एक बग का सामना करना पड़ा है।
एरर मैसेज: average([]) को कॉल करने पर यह एरर मिलता है: ZeroDivisionError: division by zero
पुनरुत्पादन के चरण (Steps to reproduce): calc.py में average फ़ंक्शन को एक खाली सूची पास करने पर यह हमेशा होता है
कृपया आप:
1. पहले मूल कारण (root cause) का पता लगाएँ, समझाएँ कि एरर क्यों हुआ, अभी कोड में बदलाव न करें
2. मुझे एक फिक्स (fix) प्रदान करें जो मूल कारण को हल करे, केवल एरर को छुपाए नहीं
3. बदलाव करने के बाद, एक रिग्रेशन टेस्ट (regression test) जोड़ें जो इस बग को रिप्रोड्यूस कर सके, और पुष्टि करने के लिए इसे रन करें कि यह पास हो गया हैअपेक्षित परिणाम: Claude पहले आपको मूल कारण बताएगा — खाली सूची होने पर len(numbers) 0 होता है, और 0 से विभाजित करने पर यह क्रैश हो जाता है; फिर वह आपको एक diff देगा (उदाहरण के लिए खाली सूची होने पर 0 वापस करना या एक स्पष्ट एक्सेप्शन (exception) देना), और आपके अप्रूवल (approval) का इंतज़ार करेगा; अप्रूवल देने के बाद, यह एक नई टेस्ट फ़ाइल भी बनाएगा (जैसे test_calc.py), जिसमें एक टेस्ट केस होगा जो विशेष रूप से खाली सूची का परीक्षण करेगा।
चौथा कदम: परिवर्तनों को स्वीकार (Approve) करें, और इसे टेस्ट रन करते हुए देखें
diff को समझने के बाद, "Agree / Yes" चुनें। Claude फिर नया लिखा गया टेस्ट चलाएगा।
अपेक्षित परिणाम: टर्मिनल में आपको टेस्ट परिणाम दिखाई देंगे, कुछ इस तरह:
test_calc.py::test_average_empty_list PASSED
test_calc.py::test_average_normal PASSEDसारे टेस्ट का हरा (green) होना = यह बग फिक्स हो गया है, और इस पर ताला लग गया है — अगर भविष्य में कोई इस लाइन को वापस बदलता है, तो टेस्ट तुरंत लाल (red) होकर चेतावनी देगा।
पाँचवाँ कदम: बाहर निकलें, और पुष्टि करें कि फ़ाइलें वास्तव में बदल गई हैं
Claude से बाहर निकलें (टर्मिनल में exit टाइप करें या Ctrl+D दबाएं), और टर्मिनल में देखें:
cat calc.py(Windows PowerShell के लिए type calc.py का उपयोग करें)
अपेक्षित परिणाम: calc.py में average फ़ंक्शन में खाली सूची को हैंडल करने वाला लॉजिक (logic) जोड़ दिया गया है, और डायरेक्टरी में एक नई टेस्ट फ़ाइल भी आ गई है। यह उस diff से मेल खाता है जिसे आपने अप्रूव (approve) किया था = बग फिक्स की पूरी प्रक्रिया सफलतापूर्वक चल गई, बधाई हो!
⚠️ ध्यान दें: यदि तीसरे चरण में Claude ने खुद से टेस्ट नहीं लिखा, तो संभवतः आपके टेम्पलेट से तीसरा बिंदु हट गया है। उस वाक्य को न छोड़ें — रिग्रेशन टेस्ट (regression test) का यह ताला ही एक शुरुआती (beginner) और अनुभवी (expert) के बीच का अंतर है।
💡 संक्षेप में: बग फिक्स की पूरी प्रक्रिया को अपने हाथों से चलाएं — एक वास्तविक बग डालें, टेम्पलेट का उपयोग करके उसे पहले मूल कारण ढूंढने और फिर फिक्स करने के लिए कहें, और फिर देखें कि वह टेस्ट कैसे जोड़ता है और उन्हें रन करता है, यदि आप इसे समझ गए हैं, तो आप अन्य तीन को भी आसानी से कर लेंगे।
07 सारांश
इस लेख में आपके रोज़मर्रा के काम के 80% हिस्से को चार श्रेणियों में बाँटा गया है, प्रत्येक श्रेणी के लिए एक निश्चित तरीका और एक कॉपी करने योग्य टेम्पलेट दिया गया है:
| काम | टेम्पलेट का एक वाक्य में सार | सबसे महत्वपूर्ण बात जिस पर ध्यान देना है |
|---|---|---|
| कोडबेस एक्सप्लोर करना | "समग्र आर्किटेक्चर → X के लिए जिम्मेदार कोड कहाँ है → किसी फ्लो को ट्रेस करें" | बड़े से छोटे की ओर तीन स्तरों पर पूछें, पहले दो स्तर Plan Mode में |
| बग फिक्स करना | "एरर और रिप्रोड्यूस स्टेप्स पेस्ट करें → पहले मूल कारण ढूँढें → फिक्स करें → रिग्रेशन टेस्ट जोड़ें" | मूल कारण को हल करें लक्षणों को नहीं, रिग्रेशन टेस्ट को न छोड़ें |
| रीफैक्टरिंग (Refactoring) | "वर्तमान स्थिति बताएं → लक्ष्य निर्धारित करें → छोटे-छोटे बदलाव करें → बदलाव से पहले और बाद में टेस्ट करें" | व्यवहार नहीं बदलना चाहिए, अगर टेस्ट नहीं है तो पहले टेस्ट जोड़ें |
| टेस्ट लिखना | "टेस्ट लिखें, खाली/शून्य/नकारात्मक/प्रकार त्रुटि को कवर करने पर ध्यान दें" | स्पष्ट रूप से उसे सीमा (boundaries) का परीक्षण करने के लिए कहें, और फिर उसे छूटे हुए खोजने दें |
अब आपको यह करने में सक्षम होना चाहिए: जब भी आपको कोई उच्च-आवृत्ति वाला काम मिले, तो खाली कर्सर को घूरते हुए भ्रमित न हों — सीधे उपयुक्त टेम्पलेट निकालें, उसमें रिक्त स्थान भरें, और जानें कि प्रत्येक चरण में Claude को क्या करने के लिए कहना है, और आपको किस पर नज़र रखनी है। ये चार टेम्पलेट आपके भविष्य के अधिकांश कार्यों के लिए एक नींव (scaffold) की तरह हैं; जैसे-जैसे आप इनके अभ्यस्त होते जाएंगे, आप पाएंगे कि सबसे जटिल कार्य भी इन्हीं चार प्रकारों का संयोजन (combination) और श्रृंखला (chaining) मात्र हैं।
ये चार टेम्पलेट रोज़मर्रा के इस्तेमाल की कसौटी पर खरे उतरते हैं — कोई काम कितना भी जटिल क्यों न हो, वह अंततः इन्ही चार तरीकों (approaches) पर वापस आ जाता है।
अगला लेख 17 "छवियाँ (Images) और मल्टीमॉडल (Multimodal)" — अब तक सब कुछ "निर्देश टाइप करने" के बारे में था, लेकिन कुछ बातें टेक्स्ट से समझाना मुश्किल होता है: एक एरर का स्क्रीनशॉट, एक डिज़ाइन, या एक डेटाबेस स्कीम (schema) आरेख (diagram)। अगला लेख आपको सिखाएगा कि सीधे Claude को छवियाँ कैसे दें, ताकि वह छवि देखकर काम कर सके। ज़रा सोचिए: यदि आप उस एरर स्क्रीनशॉट को सीधे उसके पास फेंक सकते हैं जिसने आपको सिरदर्द दे रखा है, तो क्या यह आसान नहीं होगा?