Claude Code के साथ बग ट्रायज एक दोहराने योग्य लूप है: रीप्रोड्यूस, टेस्ट केस मिनिमाइज़, संभावित कारण पहचानें, रिग्रेशन टेस्ट जोड़ें, और चेक्स के साथ एक संकुचित फिक्स शिप करें।
हर रिपोर्ट एक अलग पहेली लगने लगे तो बग यादृच्छिक महसूस होते हैं। आप कोड में टटोलते हैं, कुछ आइडियाज़ आज़माते हैं, और उम्मीद करते हैं कि समस्या गायब हो जाएगी। कभी-कभी हो भी जाता है, पर सीख कम मिलती है और वही मामला किसी अलग रूप में फिर से दिखता है।
बग ट्रायज इसका उलटा है। यह अनिश्चितता कम करने का तेज़ तरीका है। लक्ष्य सब कुछ तुरंत ठीक करना नहीं है। लक्ष्य एक अस्पष्ट शिकायत को एक स्पष्ट, परखने योग्य बयान में बदलना है, और फिर वह सबसे छोटा बदलाव करना है जो सिद्ध करे कि वह बयान अब गलत है।
इसीलिए लूप मायने रखता है: रीप्रोड्यूस करें, मिनिमाइज़ करें, संभावित कारण प्रमाण के साथ पहचानें, रिग्रेशन टेस्ट जोड़ें, संकुचित फिक्स लागू करें, और वैलिडेट करें। हर कदम एक खास तरह की अटकल घटाता है। कदम छोड़ोगे तो बाद में आपको बड़े फिक्स, साइड-इफेक्ट्स, या “फिक्स्ड” बग मिलेंगे जो असल में ठीक नहीं हुए होते।
एक यथार्थवादी उदाहरण: एक यूजर कहता है: “Save बटन कभी-कभी कुछ नहीं करता।” बिना लूप के आप UI कोड में खोजना शुरू कर देंगे—टाइमिंग बदलना, स्टेट, या नेटवर्क कॉल्स बदलना। लूप के साथ आप पहले “कभी-कभी” को ऐसे शर्तों में बदलते हैं कि वह हर बार हो: “टाइटल एडिट करने के बाद, फिर जल्दी टैब बदलने पर, Save डिसेबल रहता है।” वह एक वाक्य पहले से ही प्रोग्रेस है।
Claude Code सोचने के काम को तेज़ कर सकता है: रिपोर्ट्स को सटीक हाइपोथेसिस में बदलना, कहाँ देखना चाहिए का सुझाव देना, और एक न्यूनतम टेस्ट प्रस्तावित करना जो असफल होना चाहिए। यह कोड, लॉग और हालिया डिफ़्स स्कैन करके जल्दी संभाव्य कारण निकालने में खास तौर पर मददगार है।
फिर भी आपको जो मायने रखता है उसे सत्यापित करना होगा। पुष्टि करें कि बग आपके वातावरण में असली है। अच्छे-लगने वाली कहानी के बजाय सबूत (लॉग, ट्रेस, फेलिंग टेस्ट) को प्राथमिकता दें। फिक्स को जितना संभव हो छोटा रखें, उसे एक रिग्रेशन टेस्ट से साबित करें, और स्पष्ट चेक्स से वैलिडेट करें ताकि आप एक बग के बदले दूसरा न दे दें।
इनाम एक छोटा, सुरक्षित फिक्स है जिसे आप समझा और बचा सकते हैं और जो फिर से नहीं लौटेगा।
अच्छे फिक्स एक साफ़ वर्कस्पेस और एक स्पष्ट समस्या बयान से शुरू होते हैं। Claude से कुछ पूछने से पहले एक रिपोर्ट चुनें और उसे इस तरह लिखें:
“जब मैं X करता/करती हूँ, तो मुझे Y चाहिए, पर मुझे Z मिलता है।”
यदि आप यह वाक्य नहीं लिख पा रहे, तो आपके पास अभी बग नहीं है—आपके पास एक रहस्य है।
बुनियादी बातें पहले ही इकट्ठा कर लें ताकि बार-बार वही बात पूछने न पड़े। ये विवरण सुझावों को अस्पष्ट की बजाय परखने योग्य बनाते हैं: ऐप वर्शन या कमिट (और यह लोकल, स्टेजिंग या प्रोडक्शन है), एनवायरनमेंट (OS, ब्राउज़र/डिवाइस, फीचर फ़्लैग्स, रीजन), सटीक इनपुट्स (फॉर्म फील्ड, API पेलोड, यूजर एक्शन्स), कौन देखता है (सब, किसी रोल, एक अकाउंट/टेनेंट), और “expected” का क्या मतलब है (कॉपी, UI स्टेट, स्टेटस कोड, बिज़नेस रूल)।
फिर सबूत बनाये रखें जब वह ताज़ा हो। एक सिंगल टाइमस्टैम्प घंटों बचा सकता है। इवेंट के आस-पास के लॉग कैप्चर करें (क्लाइंट और सर्वर अगर संभव हो), स्क्रीनशॉट या छोटा रिकॉर्डिंग, रिक्वेस्ट या ट्रेस IDs, सटीक टाइमस्टैम्प (टाइमज़ोन के साथ), और वह सबसे छोटा डेटा स्निपेट जो इश्यू ट्रिगर करता हो।
उदाहरण: एक Koder.ai-generated React ऐप़ “Payment succeeded” दिखाता है पर ऑर्डर “Pending” ही रहता है। यूज़र रोल, सटीक ऑर्डर ID, API रिस्पांस बॉडी, और उस रिक्वेस्ट ID के लिए सर्वर लॉग लाइनें नोट करें। अब आप Claude से एक फ्लो पर फोकस करने के लिए कह सकते हैं बजाय हवा में हाथ हिलाने के।
आख़िर में एक स्टॉपिंग रूल सेट करें। कोड लिखने से पहले तय करें कि क्या चीज़ फिक्स मानने के लिए गिनती होगी: एक विशिष्ट टेस्ट पास होना, UI स्टेट बदल जाना, लॉग में एरर का गायब होना, साथ में एक छोटा वैलिडेशन चेकलिस्ट जिसे आप हर बार चलाएंगे। इससे आप सिम्पटम फिक्स कर के नया बग शिप करने से बचेंगे।
एक गन्दा बग रिपोर्ट आमतौर पर तथ्य, अटकलें और झुंझलाहट मिलाकर रखती है। मदद मांगने से पहले उसे ऐसे साफ़ करें कि Claude सबूत के साथ जवाब दे सके।
एक वाक्य का सारांश लिखें जो फीचर और फेल्योर का नाम ले। अच्छा: “ड्राफ्ट सेव करने पर कभी-कभी मोबाइल पर टाइटल डिलीट हो जाता है।” बुरा: “ड्राफ्ट्स टूटे हुए हैं।” वह वाक्य संपूर्ण ट्रायज थ्रेड का एंकर बन जाएगा।
फिर जो आप ने देखा उसे जो अपेक्षा थी उससे अलग कर दें। उबाऊ और ठोस रहें: आपने कौन सा बटन दबाया, स्क्रीन पर कौन सा मैसेज आया, कौन सी लॉग लाइन, टाइमस्टैम्प, डिवाइस, ब्राउज़र, ब्रांच, कमिट। यदि यह सब नहीं है तो कह दें।
एक सरल संरचना जिसे आप पेस्ट कर सकते हैं:
यदि विवरण गायब हैं, तो उन्हें हाँ/नहीं सवालों के रूप में पूछें ताकि लोग जल्दी जवाब दे सकें: क्या यह फ्रेश अकाउंट पर होता है? केवल मोबाइल पर? केवल रिफ्रेश के बाद? क्या यह आखिरी रिलीज़ के बाद शुरू हुआ? क्या आप incognito में रीप्रोड्यूस कर पा रहे हैं?
Claude को आप “रिपोर्ट क्लीनर” के रूप में भी इस्तेमाल कर सकते हैं। मूल रिपोर्ट (स्क्रीनशॉट से कॉपी किया टेक्स्ट, लॉग, चैट स्निपेट सब) पेस्ट करें और कहें:
“इसे एक संरचित चेकलिस्ट के रूप में दोबारा लिखें। विरोधाभास फ्लैग करें। टॉप 5 गायब तथ्यों को हाँ/नहीं सवाल के रूप में लिस्ट करें। अभी कारणों का अनुमान न लगाएँ।”
अगर किसी सहकर्मी ने कहा “यह रैंडमली फेल होता है,” तो उसे टेस्टेबल बनाओ: “iPhone 14, iOS 17.2 पर Save दो बार जल्दी टैप करने पर 2/10 बार फेल होता है।” अब आप जानबूझ कर इसे रीप्रोड्यूस कर सकते हैं।
यदि आप बग को मांग पर नहीं पैदा कर सकते, तो अगला हर कदम अटकलों पर होगा।
सबसे छोटे वातावरण से शुरू करें जो अभी भी समस्या दिखा सके: लोकल देव बिल्ड, एक मिनिमल ब्रांच, छोटा डेटासेट, और जितनी कम सर्विसेस उतनी कम चालू रखें।
सटीक स्टेप्स लिखें ताकि कोई और बिना सवाल पूछे उन्हें फॉलो कर सके। इसे कॉपी-पेस्ट फ्रेंडली बनाएं: कमांड्स, IDs, और सैंपल पेलोड्स बिल्कुल वैसे ही शामिल करें जैसे उपयोग हुए थे।
एक सरल कैप्चर टेम्पलेट:
फ़्रीक्वेंसी आपकी रणनीति बदल देती है। “Always” बग तेज़ इटरेशन के लिए शानदार हैं। “Sometimes” आमतौर पर टाइमिंग, कैशिंग, रेस कंडीशन, या छिपे स्टेट की तरफ इशारा करते हैं।
एक बार जब आपके पास रीप्रोडक्शन नोट्स हों, तो Claude से ऐसे त्वरित प्रोज़ पर पूछें जो बिना ऐप को फिर से लिखे अनिश्चितता घटाएँ। अच्छे प्रॉब्स छोटे होते हैं: फेलिंग बाउंडरी के आसपास एक लक्षित लॉग लाइन (इनपुट्स, आउटपुट्स, की स्टेट), किसी एक कंपोनेंट के लिए डिबग फ़्लैग, डिटर्मिनिस्टिक बिहेवियर के लिए तरीका (फिक्स्ड रैंडम सीड, फिक्स्ड टाइम, सिंगल वर्कर), एक छोटा सीड डेटासेट या एक सिंगल फेलिंग रिक्वेस्ट/रिस्पॉन्स पेयर को रीप्ले करना।
उदाहरण: साइनअप फ्लो कभी-कभी फेल होता है। Claude सुझा सकता है कि generated user ID, email normalization रिज़ल्ट, और unique constraint एरर डिटेल्स लॉग करें, फिर वही पेलोड 10 बार चलाएँ। अगर फेल पहला रन के बाद ही होता है तो यह माइग्रेशन, कैश वार्मअप, या मिसिंग सीड डेटा की ओर संकेत देता है।
अच्छा रिप्रो उपयोगी है। एक मिनिमल रिप्रो पावरफुल है। यह बग को समझना तेज़ बनाता है, डिबग आसान करता है, और गलती से “फिक्स” होने की संभावना घटाता है।
जो अनिवार्य नहीं है उसे हटा दें। अगर बग लंबे UI फ्लो के बाद आता है, तो सबसे छोटा पाथ खोजें जो अभी भी ट्रिगर करे। ऑप्शनल स्क्रीन, फ़ीचर फ़्लैग्स और अनरिलेटेड इंटीग्रेशन हटा दें जब तक कि बग गायब न हो जाए (जिसका मतलब था आपने कुछ जरुरी हटा दिया) या बना रहे (आपने शोर हटाया)।
फिर डेटा सिकोड़ें। अगर बग को बड़े पेलोड की जरूरत है, तो सबसे छोटा पेलोड खोजें जो अभी भी टूटे। अगर 500 आइटम की लिस्ट चाहिए, तो देखें क्या 5, फिर 2, फिर 1 काम करता है। फ़ील्ड्स एक-एक करके हटाएँ। लक्ष्य सबसे कम मूविंग पार्ट्स है जो बग को फिर भी रीप्रोड्यूस करता हो।
व्यवहारिक तरीका “आधे में काटो और रिटेस्ट करो” है:
उदाहरण: चेकआउट पेज कभी-कभी क्रैश करता है जब कूपन लागू किया जाता है। आप पता करते हैं कि यह केवल तभी होता है जब कार्ट में कम-से-कम एक डिस्काउंटेड आइटम हो, कूपन लोअरकेस में हो, और शिपिंग “pickup” हो। यही आपका मिनिमल केस है: एक डिस्काउंटेड आइटम, एक लोअरकेस कूपन, एक पिकअप ऑप्शन।
एक बार मिनिमल केस स्पष्ट हो जाए, Claude से कहें कि वह इसे एक छोटा रेप्रोडक्शन स्कैफोल्ड में बदले: फेल करने वाले फ़ंक्शन को न्यूनतम इनपुट्स के साथ कॉल करने वाला टेस्ट, एक छोटा स्क्रिप्ट जो एक एन्डपॉइंट को रिड्यूस्ड पेलोड के साथ हिट करे, या एक छोटा UI टेस्ट जो एक ही रूट पर जाता है और एक एक्शन करता है।
एक बार जब आप प्रॉब्लम रीप्रोड्यूस कर सकते हैं और आपके पास छोटा टेस्ट केस है, तो अनुमान लगाना बंद कर दें। लक्ष्य संभाव्य कारणों की एक छोटी लिस्ट पर आकर हर एक को प्रमाणित या अस्वीकार करना है।
एक उपयोगी नियम है: इसे तीन हाइपोथेसिस तक रखें। इससे ज़्यादा हो तो संभवतः आपका टेस्ट केस अभी भी बहुत बड़ा है या अवलोकन बहुत अस्पष्ट है।
जो आप देखते हैं उसे उस जगह में ट्रांसलेट करें जहाँ यह हो सकता है। UI लक्षण हमेशा UI बग का संकेत नहीं होते।
उदाहरण: React पेज “Saved” टोस्ट दिखाता है, पर रिकॉर्ड बाद में गायब है। इसका संकेत हो सकता है (1) UI स्टेट, (2) API बिहेवियर, या (3) डेटाबेस राइट पाथ।
Claude से सामान्य भाषा में संभाव्य फेल्योर मोड समझाने को कहें, फिर हर एक के लिए वह सबूत क्या होगा बताने को कहें। लक्ष्य है “शायद” को “इसको चेक करो” में बदलना।
तीन सामान्य हाइपोथेसिस और इकट्ठा करने वाले सबूत:
नोट्स को तंग रखें: लक्षण, हाइपोथेसिस, सबूत, निर्णय। जब एक हाइपोथेसिस तथ्यों से मेल खा जाए, तो आप रिग्रेशन टेस्ट लॉक कर सकते हैं और सिर्फ ज़रूरी हिस्सा ठीक कर सकते हैं।
एक अच्छा रिग्रेशन टेस्ट आपका सुरक्षा बेल्ट है। यह साबित करता है कि बग मौजूद था और यह बताता है कि आपने सचमुच उसे फिक्स किया है या नहीं।
सबसे पहले वही सबसे छोटा टेस्ट चुनें जो असल फेल्योर से मेल खाता हो। अगर बग तभी आता है जब कई पार्ट्स साथ काम करते हैं, तो यूनिट टेस्ट मिस कर सकता है।
जब एक फ़ंक्शन गलत वैल्यू लौटाए तो यूनिट टेस्ट का उपयोग करें। जब पार्ट्स के बीच बॉउंड्री समस्या हो (API हैंडलर + DB, या UI + स्टेट) तो इंटीग्रेशन टेस्ट का उपयोग करें। केवल वही समय end-to-end उपयोग करें जब पूरा यूज़र फ्लो आवश्यक हो।
Claude से कुछ भी लिखवाने से पहले मिनिमाइज़्ड केस को एक सख्त अपेक्षित व्यवहार के रूप में दोहराएं। उदाहरण: “जब यूज़र खाली टाइटल सेव करता है, API को 400 और message 'title required' लौटाना चाहिए।” अब टेस्ट का स्पष्ट लक्ष्य है।
फिर Claude से पहले एक फेलिंग टेस्ट ड्राफ्ट करवाएँ। सेटअप मिनिमल रखें और केवल वही डेटा कॉपी करें जो बग ट्रिगर कर रहा है। टेस्ट का नाम उपयोगकर्ता के अनुभव पर रखें, न कि आंतरिक फ़ंक्शन पर।
एक त्वरित पास खुद करें:
जब टेस्ट सही कारण के लिए फेल हो रहा हो, तब आप Narrow fix लागू करने के लिए तैयार हैं।
एक बार जब आपके पास छोटा रिप्रो और फेलिंग रिग्रेशन टेस्ट हो, तो "साफ़-सफाई" करने की लालसा से बचें। लक्ष्य वह सबसे छोटा बदलाव करना है जो टेस्ट को सही कारण से पास करवाए।
एक अच्छा संकुचित फिक्स सबसे कम सरफेस एरिया बदलता है। अगर फेल्योर एक फ़ंक्शन में है, उस फ़ंक्शन को ठीक करें, पूरे मॉड्यूल को नहीं। अगर बॉउंड्री चेक गायब है तो चेन में पूरे हिस्से पर नहीं, बल्कि बॉउंड्री पर चेक जोड़ें।
अगर आप Claude से मदद ले रहे हैं, तो दो फिक्स ऑप्शन माँगें और स्कोप व रिस्क के हिसाब से तुलना करें। उदाहरण: React फॉर्म फील्ड खाली होने पर क्रैश करता है—आपको मिल सकते हैं:
ऑप्शन A आमतौर पर ट्रायज का चुनाव होता है: छोटा, रिव्यू में आसान, और टूटने की संभावना कम।
फिक्स संकुचित रखने के लिए जितनी कम फ़ाइलें छुएँ उतना बेहतर, लोकल फिक्स को प्रेफर करें, जहां खराब वैल्यू आती है वहां गार्ड/वैलिडेशन जोड़ें, और बिहेवियर चेंज को एक स्पष्ट before/after के साथ रखें। कारण स्पष्ट न हो तो ही कमेंट जोड़ें।
ठोस उदाहरण: एक Go API एन्डपॉइंट तब पैनिक कर रहा है जब एक ऑप्शनल क्वेरी पैरामीटर गायब है। संकुचित फिक्स है हैंडलर बॉउंड्री पर खाली स्ट्रिंग संभालना (डिफ़ॉल्ट के साथ पार्स करें, या 400 और साफ़ मैसेज लौटाएँ)। शेयर्ड पार्सिंग यूटिलिटीज़ बदलने से बचें जब तक रिग्रेशन टेस्ट यह साबित न करे कि समस्या शेयर्ड कोड में है।
बदलाव के बाद फेलिंग टेस्ट और पास-पास के एक-दो टेस्ट दोबारा चलाएँ। यदि आपका फिक्स कई unrelated टेस्ट बदलने पर मजबूर कर रहा है, तो यह संकेत है कि बदलाव बहुत व्यापक है।
वैलिडेशन वह जगह है जहाँ आप छोटे, आसानी से छूट जाने वाले समस्याओं को पकड़ते हैं: ऐसा फिक्स जो एक टेस्ट पास करवा देता है पर पास-पास के रास्ते तोड़ देता है, एरर मैसेज बदल देता है, या धीमा क्वेरी जोड़ देता है।
सबसे पहले आप जो रिग्रेशन टेस्ट जोड़ा था उसे दोहराएँ। अगर वह पास हो गया तो नज़दीकी पड़ोस के टेस्ट (उसी फाइल, उसी मॉड्यूल, और जो समान इनपुट को कवर करते हैं) चलाएँ। बग अक्सर साझा हेल्पर्स, पार्सिंग, बॉउंड्री चेक्स या कैशिंग में छिपा होता है, इसलिए सबसे प्रासंगिक फेलर आमतौर पर पास-पास दिखते हैं।
फिर मूल रिपोर्ट स्टेप्स के साथ एक छोटा मैनुअल चेक करें। संक्षेप और सटीक रखें: वही एनवायरनमेंट, वही डेटा, वही क्लिक या API कॉल्स। रिपोर्ट अगर ढीली थी तो उसी सीनारियो का परीक्षण करें जिसे आपने रीप्रोड्यूस करने के लिए इस्तेमाल किया था।
अगर आप फोकस में बने रहना चाहते हैं, Claude से अपने चेंज और फेलिंग सीनारियो के आधार पर छोटा वैलिडेशन प्लान माँगें। बताइए आपने किस फ़ाइल को बदला, आप क्या बदलना चाहते थे, और क्या प्रभावित हो सकता है। सबसे अच्छे प्लान छोटे और क्रियान्वित होते हैं: 5–8 चेक जिन्हें आप मिनटों में कर सकें, हर एक का स्पष्ट पास/फेल होना।
आख़िरकार, PR या नोट्स में यह कैप्चर करें कि आपने क्या वैलिडेट किया: कौन से टेस्ट रन हुए, कौन से मैनुअल स्टेप्स आज़माए गए, और क्या लिमिटेशन्स थीं (उदा., “मोबाइल टेस्ट नहीं किया”)। इससे फिक्स पर भरोसा करना आसान होता है और बाद में उसे फिर से देखने पर मदद मिलती है।
सबसे तेज़ समय बर्बाद करने का तरीका है बिना रिप्रो करते ही “फिक्स” को मान लेना। अगर आप इसे भरोसेमंद तरीके से फेल नहीं करवा सकते, तो आप नहीं जान पाएँगे कि वास्तव में क्या सुधरा।
एक व्यावहारिक नियम: फिक्स मांगने से पहले एक रिपीटेबल सेटअप वर्णन करें (सटीक स्टेप्स, इनपुट, एनवायरनमेंट, और क्या "गलत" दिखता है)। अगर रिपोर्ट अस्पष्ट है तो पहले उसे एक चेकलिस्ट में बदलने में अपने पहले मिनट बिताएँ जिसे आप दो बार चला कर वही नतीजा पा सकें।
रीप्रोड्यूसिबल केस के बिना फिक्स करना। एक न्यूनतम “हरेक बार फेल” स्क्रिप्ट या स्टेप्स की मांग करें। अगर यह केवल "कभी-कभी" होता है, तो टाइमिंग, डाटा साइज, फीचर फ़्लैग्स, और लॉग कैप्चर करें जब तक यह रैंडम न रह जाए।
बहुत जल्दी मिनिमाइज़ करना। यदि आप मूल फेल्योर की पुष्टि किए बिना केस को बहुत छोटा कर देते हैं, तो सिगनल खो सकता है। पहले बेसलाइन रीप्रोड्यूस लॉक करें, फिर एक-एक बदलाव करके सिकोड़ें।
Claude को अनुमान लगाने देना। Claude संभावित कारण सुझा सकता है, पर आपको अभी भी सबूत चाहिए। 2–3 हाइपोथेसिस माँगें और हर एक को कन्फर्म/रिजेक्ट करने के लिए बिल्कुल वही ऑब्ज़र्वेशन माँगें (एक लॉग लाइन, एक ब्रेकपॉइंट, एक क्वेरी रिजल्ट)।
गलत कारण के लिए पास होने वाले रिग्रेशन टेस्ट। एक टेस्ट इसलिए पास हो सकता है कि वह कभी फेल करने वाले पाथ पर ही नहीं पहुँचता। परीक्षण यह पक्का करें कि फिक्स से पहले टेस्ट फेल कर रहा था, और सही मेसेज या असर्शन के साथ फेल हो रहा था।
सिम्पटम को ठीक करना बजाय ट्रिगर को। यदि आप एक नल चेक जोड़ देते हैं पर असली समस्या यह है कि “यह वैल्यू कभी नल नहीं होनी चाहिए,” तो आप गहरी बग छिपा सकते हैं। जहां संभव हो, उस स्थिति को बनती ही रोकें न कि उसे बस संभाल लें।
नया रिग्रेशन टेस्ट और मूल रीप्रोड्यूस स्टेप्स अपने चेंज से पहले और बाद में चलाएँ। अगर चेकआउट बग केवल तब आता है जब प्रोमो कोड शिपिंग बदलने के बाद लागू किया गया, तो वह पूरा सिक्वेंस अपना “सत्य” रखें, भले ही मिनिमाइज़्ड टेस्ट छोटा हो।
यदि आपकी वैलिडेशन “अब ठीक लग रहा है” पर निर्भर है, तो एक ठोस चेक जोड़ें (एक लॉग, एक मीट्रिक, या एक सटीक आउटपुट) ताकि अगला व्यक्ति जल्दी से सत्यापित कर सके।
जब समय कम हो, एक छोटा, दोहराने वाला लूप ही हीरोइक डीबगिंग से बेहतर होता है।
अंतिम निर्णय कुछ पंक्तियों में लिखें ताकि अगला व्यक्ति (अक्सर भविष्य का आप) उस पर भरोसा कर सके। एक उपयोगी फॉर्मेट है: “Root cause: X. Trigger: Y. Fix: Z. Why safe: W. What we did not change: Q.”
अगले कदम: जो कुछ ऑटोमेट किया जा सकता है उसे ऑटोमेट करें (एक सेव्ड रिप्रो स्क्रिप्ट, एक स्टैंडर्ड टेस्ट कमांड, रूट-कारण नोट्स के लिए एक टेम्पलेट)।
अगर आप Koder.ai (koder.ai) से ऐप बनाते हैं, तो Planning Mode मदद कर सकता है कि आप कोड छुए बिना चेंज का आउटलाइन बनाएं, और snapshots/rollback आपको सुरक्षित रूप से एक्सपेरीमेंट करने की आज़ादी देते हैं जब आप किसी पेचीदा रीप्रो पर काम कर रहे हों। फिक्स वैलिडेट होने के बाद आप सोर्स को एक्सपोर्ट कर सकते हैं या अपडेटेड ऐप को डिप्लॉय कर के होस्ट कर सकते हैं, ज़रूरत पड़ने पर कस्टम डोमेन के साथ।
बग ट्रायज का मतलब है एक अस्पष्ट रिपोर्ट को एक स्पष्ट, परखने योग्य बयान में बदलना, और फिर सबसे छोटा ऐसा बदलाव करना जिससे वह बयान अब सही न रहे।
यह "सब कुछ ठीक कर दो" के बारे में नहीं है, बल्कि अनिश्चितता को चरण दर चरण कम करने के बारे में है: रीप्रोड्यूस करें, मिनिमाइज़ करें, सबूत-आधारित हाइपोथेसेस बनाएं, रिग्रेशन टेस्ट जोड़ें, संकुचित फिक्स करें और वैलिडेट करें।
क्योंकि हर कदम अलग तरह की अटकलों को हटाता है।
इसे ऐसे लिखें: “जब मैं X करता/करती हूँ, तो मुझे Y चाहिए, पर मुझे Z मिलता है.”
फिर सिर्फ़ इतना कॉन्टेक्स्ट इकट्ठा करें जो टेस्ट करने लायक बनाए:
सबसे पहले पुष्टि करें कि आप इसे उस सबसे छोटे वातावरण में रीप्रोड्यूस कर सकते हैं जो अभी भी समस्या दिखाता हो (अक्सर लोकल देव और छोटा डेटासेट)।
अगर यह "कभी-कभी" आता है, तो इसे डिटर्मिनिस्टिक बनाने की कोशिश करें:
जब तक आप इसे मांग पर फेल करवा न सकें, आगे न बढ़ें।
मिनिमाइज़ करने का मतलब है जो आवश्यक नहीं उसे हटाना, पर बग बरकरार रखना।
एक व्यावहारिक तरीका "आधे में काटो और रिटेस्ट करो":
स्टेप्स (छोटी यूज़र फ्लो) और डेटा (छोटा पेलोड, कम आइटम) दोनों को सिकोड़ें जब तक आपके पास सबसे छोटा रिप्रो ट्रिगर न आ जाए।
Claude Code से मदद लें पर अनुमान न होने दें।
अच्छे रिक्वेस्ट ऐसे दिखते हैं:
फिर आप खुद वेलिडेट करें: लोकल रीप्रोड्यूस करें, लॉग/ट्रेस चेक करें, और पक्का करें कि टेस्ट सही कारण से फेल हो रहा है।
इसे तीन पर रखें। इससे ज्यादा हो तो आमतौर पर आपका रिप्रो अभी भी बहुत बड़ा है या अवलोकन अस्पष्ट हैं।
हर हाइपोथेसिस के लिए लिखें:
सबसे छोटा टेस्ट लेवल चुनें जो फेलर से मेल खाता हो:
एक अच्छा रिग्रेशन टेस्ट:
सबसे छोटा बदलाव करें जो फेलिंग रिग्रेशन टेस्ट को सही कारण से पास कर दे।
नियम:
एक छोटा चेकलिस्ट फॉलो करें जिसे आप तेज़ी से कर सकें:
किस-किस टेस्ट को रन किया और क्या नहीं किया, वो PR/नोट्स में लिख डालें ताकि अगला इंसान भरोसा कर सके।
यह प्रक्रिया प्रगति को ज़बरदस्त तरीके से आगे बढ़ाती है।
