08 दिस॰ 2025·8 मिनट
Claude Code के लिए कोडबेस ऑनबोर्डिंग: आपके ऐप का नक्शा बनाने वाले प्रॉम्प्ट
Claude Code के लिए कोडबेस ऑनबोर्डिंग: Q&A प्रॉम्प्ट्स से मॉड्यूल, प्रमुख फ्लो और जोखिम मैप करें, फिर नोट्स को एक छोटा ऑनबोर्डिंग डॉक बनाएं।
Claude Code के लिए कोडबेस ऑनबोर्डिंग: Q&A प्रॉम्प्ट्स से मॉड्यूल, प्रमुख फ्लो और जोखिम मैप करें, फिर नोट्स को एक छोटा ऑनबोर्डिंग डॉक बनाएं।
बेतरतीब फाइलें पढ़ना धीमा लगता है क्योंकि ज़्यादातर कोडबेस कहानी जैसी व्यवस्थित नहीं होते। आप कोई फ़ोल्डर खोलते हैं, दस नाम दिखते हैं जो महत्वपूर्ण लगते हैं, एक पर क्लिक करते हैं और अंत में हेल्पर्स, कॉन्फ़िग और एज केस में पहुँच जाते हैं। एक घंटे बाद आपके पास कई विवरण होते हैं पर फिर भी आप समझा नहीं पाते कि ऐप कैसे काम करता है।
ऑनबोर्डिंग के दौरान Claude Code का बेहतर लक्ष्य एक सरल मेन्टल मैप बनाना है। उस मैप को तीन सवालों का जवाब देना चाहिए:
1–2 दिनों में "पर्याप्त अच्छा" ऑनबोर्डिंग यह नहीं है कि आप हर क्लास समझा सकें। यह इस के करीब है:
कुछ चीज़ें बाद में कर सकती हैं। गहरी रिफैक्टरिंग, हर एब्स्ट्रैक्शन की परफ़ेक्ट समझ, और पुराना कोड पढ़ना जिसे कोई छूता ही नहीं — ये अक्सर सबसे तेज़ उपयोगी नहीं होते।
ऑनबोर्डिंग को सड़कों को याद करने की बजाय नक्शा बनाने की तरह सोचें। आपके प्रॉम्प्ट्स को बार-बार यह याद दिलाना चाहिए: "मैं सिस्टम में कहाँ हूँ, आगे क्या होता है, और यहाँ क्या गलत हो सकता है?" एक बार यह होने पर, विवरण माँगने पर सीखना आसान हो जाता है।
प्रश्न पूछना शुरू करने से पहले, वे बुनियादी बातें इकट्ठा करें जो आप आमतौर पर पहले दिन चाहिए होती हैं। Claude Code तब सबसे अच्छा काम करता है जब वह असली फाइलों, असली कॉन्फ़िग और असली व्यवहार पर प्रतिक्रिया दे सके जिसे आप पुनरुत्पादित कर सकते हैं।
सुरुआत एक्सेस और एक काम करने वाली रन से करें। सुनिश्चित करें कि आप रिपो को क्लोन कर सकते हैं, डिपेंडेंसीज़ इंस्टॉल कर सकते हैं, और ऐप (या कम से कम एक छोटा हिस्सा) स्थानीय रूप से चला सकते हैं। अगर लोकल सेटअप कठिन है, तो स्टेजिंग एन्वायरनमेंट और जहाँ लॉग रहते हैं वहाँ एक्सेस लें, ताकि आप सत्यापित कर सकें कि कोड वास्तविक में क्या करता है।
अगला, "source of truth" डॉक्स खोजें। आप उन डॉक्स की तलाश कर रहे हैं जिन्हें टीम वास्तव में बदलाव होने पर अपडेट करती है: README, छोटा आर्किटेक्चर नोट, ADR फ़ोल्डर, रनबुक, या डिप्लॉयमेंट नोट। भले ही वे गंदे हों, वे मॉड्यूल और फ्लोज़ के नाम देते हैं, जो Q&A को कहीं अधिक सटीक बनाते हैं।
स्कोप जल्दी तय करें। कई रिपोज़ में कई ऐप्स, सेवाएँ और साझा पैकेज होते हैं। सीमाएँ चुनें जैसे "केवल API और billing worker" या "केवल वेब ऐप और उसका auth फ्लो।" स्पष्ट स्कोप अनंत भटकाव को रोकता है।
उन मान्यताओं को लिखें जिन्हें आप असिस्टेंट से अनुमान न लगाने के लिए रोकना चाहते हैं। यह छोटा लग सकता है, लेकिन बाद में गलत मानसिक मॉडल रोकता है जो घंटों बर्बाद कर देता है।
यहाँ एक सरल तैयारी चेकलिस्ट है:
अगर कुछ गायब है, तो उसे टीममेट के लिए एक प्रश्न के रूप में कैप्चर करें। "घरेलू" अनुमान के साथ मिसिंग संदर्भ को "वर्क-अराउंड" न करें।
मेन्टल मैप एक छोटा नोट सेट है जो यह बताता है: इस ऐप के मुख्य हिस्से कौन से हैं, वे कैसे एक दूसरे से बात करते हैं, और कहाँ चीज़ें गलत हो सकती हैं। अच्छा किया जाए तो, ऑनबोर्डिंग फ़ाइलों ब्राउज़ करने से कम और एक दोहराने योग्य चित्र बनाने के बारे में अधिक बन जाती है।
अपने आउटपुट को परिभाषित करने से शुरू करें। आप एक मॉड्यूल सूची चाहते हैं जो व्यावहारिक हो, परफ़ेक्ट न हो। हर मॉड्यूल के लिए यह पकड़ें कि यह क्या करता है, किसका मालिक है (टीम या व्यक्ति अगर पता हो), और इसकी मुख्य निर्भरताएँ (अन्य मॉड्यूल, सेवाएँ, डेटाबेस, बाहरी APIs)। एंट्री पॉइंट्स भी नोट करें: UI रूट्स, API endpoints, बैकग्राउंड जॉब्स, और शेड्यूल किए गए टास्क।
इसके बाद, कुछ उपयोगकर्ता यात्राएँ चुनें जो मायने रखती हैं। तीन से पाँच पर्याप्त हैं। ऐसे फ्लोज़ चुनें जो पैसे, अनुमतियाँ, या डेटा परिवर्तन को छूते हों। उदाहरण: साइनअप और ईमेल वेरिफिकेशन, भुगतान योजना या खरीद बनाना, कोई एडमिन कार्रवाई जो उपयोगकर्ता एक्सेस बदलती है, और एक महत्वपूर्ण दैनिक-उपयोग का फ्लो जिस पर अधिकांश उपयोगकर्ता निर्भर करते हैं।
शुरू करने से पहले जोखिम कैसे लेबल करेंगे तय करें। श्रेणियाँ सरल रखें ताकि आप बाद में स्कैन कर सकें। एक उपयोगी सेट है: security, data integrity, uptime, और cost। जब आप किसी चीज़ को जोखिमपूर्ण निशान लगाएँ, तो एक वाक्य जोड़ें कि क्यों, और क्या साबित करेगा कि यह सुरक्षित है (एक टेस्ट, एक लॉग, एक permission check)।
नोट्स को एक जैसा फॉर्मेट दें ताकि आप बिना सब कुछ फिर से लिखे उन्हें ऑनबोर्डिंग डॉक में बदल सकें:
उदाहरण: अगर Checkout Billing को कॉल करता है जो payments और invoices पर लिखता है, तो उसे data integrity और cost के रूप में टैग करें। फिर नोट करें कि retries कहाँ होते हैं और डबल-चार्जिंग को क्या रोकता है।
जब आप नए रिपो में जुड़ते हैं, तो तेज़ ओरिएंटेशन चाहिए, परफ़ेक्ट समझ नहीं। ये प्रॉम्प्ट्स आपको छोटे, सुरक्षित चरणों में मेन्टल मैप बनाने में मदद करते हैं।
शुरू करें असिस्टेंट को रिपो ट्री (या पेस्ट किया गया सबसेट) दे कर और टूर माँगकर। हर राउंड को केंद्रित रखें, फिर अंत में एक प्रश्न के साथ समाप्त करें जो बताये कि आगे क्या पढ़ना है।
1) Repo tour
"Here is the top-level folder list: <paste>. Explain what each folder likely contains and which ones matter for core product behavior."
2) Entry points
"Find the app entry points and boot process. What files start the app, set up routing, configure DI/env, and start background jobs? Name the exact files and what they do."
3) Module index
"Create a module index: module name, purpose, key files, and important external dependencies. Keep it to the modules that affect user-facing behavior."
4) Data model hints
"Based on migrations/models, list the key tables/entities, critical fields, and relationships. Call out fields that look security-sensitive or used for billing/permissions."
5) Flow trace
"Trace this flow end-to-end: <flow>. Where does the request/event start, where does it end, and what does it call in between? List the main functions/files in order."
6) Next inspection
"What should I inspect next and why? Give me 3 options: fastest clarity, riskiest area, and best long-term payoff."
एक ठोस उदाहरण: अगर आप "user signs up and creates their first project" को मैप कर रहे हैं, तो API route handler, validation, DB write, और कोई async job जो ईमेल भेजता है या संसाधन प्रोविजन करता है माँगें। फिर "user deletes project" के लिए फ्लो ट्रेस फिर चलाएँ ताकि क्लीनअप गैप्स दिखाई दें।
उत्तरों को कार्य-योग्य रखने के लिए, विशिष्ठ आर्टिफैक्ट माँगें, न कि सिर्फ सारांश:
सबसे बड़ा ऑनबोर्डिंग जीत बिखरे Q&A को ऐसे नोट्स में बदलना है जिसे कोई और उपयोग कर सके। अगर नोट्स केवल आपके लिए समझ में आते हैं, तो आप वही खुदाई फिर से करेंगे।
सरल संरचना लंबी फाइलों से बेहतर है। हर एक्सप्लोरेशन सेशन के बाद, उत्तरों को पाँच छोटे आर्टिफैक्ट्स में सहेजें (एक फ़ाइल या डॉक ठीक है): एक मॉड्यूल तालिका, एक शब्दावली, प्रमुख फ्लोज़, अज्ञात, और एक जोखिम रजिस्टर।
यहाँ एक कॉम्पैक्ट टेम्प्लेट जो आप अपने नोट्स में पेस्ट कर सकते हैं और जैसे-जैसे भरते जाएँ:
Module table
- Module:
Owns:
Touches:
Entry points:
Glossary
- Term:
Meaning:
Code name(s):
Key flow (name)
1.
2.
3.
Unknowns
- Question:
Best person to ask:
Where to look next:
Risk register
- Risk:
Location:
Why it matters:
How to verify:
क्योंकि की फ्लोज़ को छोटा रखने का उद्देश्य है। उदाहरण: 1) user signs in, 2) backend creates a session, 3) client loads the dashboard, 4) API fetches data, 5) UI renders and handles errors. यदि आप किसी फ्लो को पाँच स्टेप्स में फिट नहीं कर पा रहे हैं, तो उसे अलग करें (login बनाम dashboard load)।
Claude Code का उपयोग करते समय हर उत्तर में एक लाइन जोड़ें: "How would I test this?" यह एकल लाइन निष्क्रिय नोट्स को एक चेकलिस्ट में बदल देती है जिसे आप बाद में चला सकते हैं, विशेषकर जब अज्ञात और जोखिम ओवरलैप होने लगते हैं।
यदि आप Koder.ai (koder.ai) जैसे vibe-coding प्लेटफ़ॉर्म पर बना रहे हैं, तो यह तरह का नोट-लेना भी मदद करता है यह देखने में कि जेनरेट किए गए परिवर्तन किन साइड-इफेक्ट्स का कारण बन सकते हैं। कई टचपॉइंट वाले मॉड्यूल परिवर्तन आकर्षित करते हैं।
कोडबेस में जोखिम साधारणतः यादृच्छिक नहीं होता। यह वहाँ क्लस्टर करता है जहाँ ऐप तय करता है कि आप कौन हैं, डेटा बदलता है, अन्य सिस्टम्स से बात करता है, या बैकग्राउंड में काम चलाता है। आप लक्षित प्रश्नों और कुछ केंद्रित सर्च से उनमें से अधिकांश पा सकते हैं।
पहले identity से शुरू करें। पूछें कि ऑथेन्टिकेशन कहाँ होता है (login, session, tokens) और authorization निर्णय कहाँ होते हैं (role checks, feature flags, ownership rules)। एक सामान्य जाल यह है कि चेक्स UI, API हैंडलर्स, और DB क्वेरीज़ में बिखरे होते हैं बिना किसी single source of truth के।
इसके बाद, write paths मैप करें। उन endpoints या फ़ंक्शन्स को खोजें जो रिकॉर्ड क्रिएट, अपडेट, या डिलीट करते हैं, साथ ही migrations जो समय के साथ डेटा को बदलते हैं। बैकग्राउंड जॉब्स को भी शामिल करें। कई रहस्यमय बग्स async workers से आते हैं जो अनुरोध खत्म होने के काफी बाद अनपेक्षित मान लिखते हैं।
जोखिम जल्दी उजागर करने वाले प्रॉम्प्ट्स:
फिर कॉन्फ़िग और सीक्रेट्स हैंडलिंग चेक करें। env vars, runtime config फाइलें, और default fallbacks खोजें। डिफ़ॉल्ट्स उपयोगी हैं, पर जब वे मिसकॉनफिगरेशन छिपाते हैं तब जोखिमपूर्ण होते हैं (उदा., किसी वैल्यू के गायब होने पर प्रोड में dev key इस्तेमाल होना)।
एक त्वरित उदाहरण: एक Go बैकएंड और PostgreSQL में, आप एक "send email" जॉब पा सकते हैं जो फेल होने पर_retry_ करता है। यदि यह idempotency key के बिना retries करता है, तो उपयोगकर्ताओं को डुप्लिकेट ईमेल मिल सकते हैं। अगर फेल्यर्स केवल वॉर्निंग लॉग करते हैं और कोई अलर्ट नहीं है, तो यह चुपचाप टूट जाता है। यह एक उच्च-जोखिम क्षेत्र है जिसे जल्दी दस्तावेज़ बनाना और टेस्ट करना चाहिए।
अपने पहले end-to-end थ्रेड को सिस्टम के माध्यम से बनाने के लिए एक वास्तविक फ्लो का उपयोग करें। Login एक अच्छा स्टार्ट है क्योंकि यह routing, validation, sessions/tokens, और DB reads को छूता है।
परिदृश्य: एक React वेब ऐप एक Go API को कॉल करता है, और API PostgreSQL को पढ़ता/लिखता है। आपका लक्ष्य हर फाइल समझना नहीं है। यह जवाब देना है: "जब एक यूज़र Login पर क्लिक करता है, तब आगे कौन सा कोड चलता है, कौन सा डेटा मूव होता है, और क्या गलत हो सकता है?" यही आउनबोर्डिंग को ठोस बनाता है।
UI से शुरू करें और आगे एक हॉप करके आगे बढ़ते जाएँ। विशिष्ट फाइल नाम, फ़ंक्शन, और request/response शैप माँगें।
हर उत्तर के बाद अपनी मेन्टल मैप में एक छोटी लाइन लिखें: "UI component -> API endpoint -> handler -> service -> DB query -> response." केवल "कुछ फ़ंक्शन" नहीं, नाम शामिल करें।
एक बार जब आपके पास पथ हो, तो इसे एक छोटे टेस्ट रन से सत्यापित करें। आप जांच रहे हैं कि जो कोड पथ आपने मैप किया है वही ऐप वास्तव में उपयोग करता है।
ब्राउज़र dev tools में नेटवर्क रिक्वेस्ट देखें (path, status code, response body)। हैंडलर और DB कॉल के आसपास सर्वर लॉग्स जोड़ें (request ID यदि उपलब्ध हो)। PostgreSQL में अपेक्षित बदलावों के लिए क्वेरी करें (login के लिए, शायद last_login_at, sessions, या audit rows)। एक विफलता ज़बरदस्ती करें (गलत पासवर्ड, फ़ील्ड गायब) और नोट करें कि त्रुटि संदेश कहाँ बनता है और कहाँ दिखता है। सफलता और विफलता के लिए अपेक्षित उत्तर (status codes और महत्वपूर्ण फ़ील्ड्स) रिकॉर्ड करें, ताकि अगला डेवलपर जल्दी से सैनीटी-चेक कर सके।
यह एकल फ्लो अक्सर मालिकाना सीमाएँ उजागर करता है: UI किस पर भरोसा करता है, API क्या लागू करता है, और त्रुटियाँ कहाँ गायब या डबल-हैंडल होती हैं।
एक बार जब आपके पास एक ठीक-ठाक मेन्टल मैप हो, तो उसे 1–2 पेज के नोट में फ्रीज़ कर दें। लक्ष्य पूरा होना नहीं है। लक्ष्य यह है कि अगले डेवलपर यह जवाब दे सके: यह ऐप क्या है, पहले कहाँ देखना है, और सबसे अधिक क्या टूट सकता है।
यदि आप Claude Code का उपयोग कर रहे हैं, तो डॉक को अपने Q&A के आउटपुट के रूप में ट्रीट करें: स्पष्ट, ठोस, और स्कैन करने में आसान।
डोक को पूर्वानुमेय रखें ताकि लोग तेज़ी से चीज़ें ढूँढ सकें। एक अच्छा स्ट्रक्चर है:
"Where things live" के लिए इशारे दें जैसे "Auth X में शुरू होता है, session लॉजिक Y में है, UI routes Z में हैं।" पूरा ट्री डंप करने से बचें। केवल वही चुनें जिसे लोग छुएँगे।
"Key flows" के लिए हर फ्लो को 4–7 स्टेप्स में लिखें: trigger, controller/handler, core module, DB call, और बाहरी प्रभाव (ईमेल भेजा गया, स्टेट अपडेट हुआ, जॉब कतार में गया)। हर स्टेप पर फाइल नाम जोड़ें।
"Risky areas" के लिए failure mode और सबसे तेज़ सुरक्षा जांच (एक विशेष टेस्ट, स्मोक रन, या लॉग जिसे देखना है) नामित करें।
अंत में एक छोटा पहला-टास्क सूची दें ताकि कोई सुरक्षित रूप से योगदान कर सके:
असिस्टेंट को बेकार करने का सबसे तेज़ तरीका है "पूरे रिपो की पूरी व्याख्या दें" माँगना। आपको एक लंबा सारांश मिलता है जो आत्मविश्वास से भरा लगता है पर अस्पष्ट रहता है। इसके बजाय, एक छोटा स्लाइस चुनें जो मायने रखता है (एक मॉड्यूल और एक यूज़र फ्लो), फिर धीरे-धीरे बाहर बढ़ें।
दूसरी सामान्य गलती यह है कि कौन सी यात्राएँ मायने रखती हैं, यह नामित न करना। यदि आप "checkout", "login", या "admin edit" नहीं कहते, तो उत्तर सामान्य आर्किटेक्चर बातों में भटक जाते हैं। हर सत्र की शुरुआत एक ठोस लक्ष्य के साथ करें: "signup फ्लो end-to-end समझाने में मदद करें, validation, error states, और डेटा कहाँ स्टोर होता है सहित।"
एक और आम जाल है असिस्टेंट को अनुमान लगाने देना। जब कुछ अस्पष्ट हो, तो उसे अनिश्चितता टैग करने के लिए मजबूर करें। उसे बताने के लिए कहें कि वह क्या कोड से साबित कर सकता है और क्या वह अनुमान लगा रहा है।
अपने नोट्स में एक सरल नियम उपयोग करें: हर दावा इन में से एक टैग होना चाहिए।
नोट्स तब भी बिखर जाते हैं जब उन्हें बिना स्ट्रक्चर के इकट्ठा किया जाता है। चैट स्निपेट्स का ढेर मेन्टल मैप में बदलना मुश्किल है। एक सुसंगत टेम्पलेट रखें: शामिल मॉड्यूल, एंट्री पॉइंट, मुख्य फ़ंक्शन्स और फाइलें, डेटा छुआ गया, साइड-इफेक्ट्स, एरर पाथ, और चलाने के लिए टेस्ट।
Claude Code के साथ भी, आउटपुट को ड्राफ्ट के रूप में लें। प्रमुख फ्लोज़ को रनिंग ऐप में सत्यापित करें, खासकर वे हिस्से जो प्रोडक्शन तोड़ सकते हैं: auth, payments, permissions, background jobs, और migrations।
एक व्यवहारिक उदाहरण: यदि असिस्टेंट कहता है "password reset ईमेल X के माध्यम से भेजता है," तो इसे dev एन्वायरनमेंट में ट्रिगर करके लॉग या ईमेल सैंडबॉक्स से पुष्टि करें। यह वास्तविकता जांच आपको उस कहानी में ऑनबोर्ड होने से रोकता है जो सच्ची नहीं है।
आपको रिपो याद रखने की ज़रूरत नहीं है। आपको इतना आत्मविश्वास चाहिए कि आप एक सुरक्षित बदलाव कर सकें, एक असली issue डिबग कर सकें, और सिस्टम अगले व्यक्ति को समझा सकें।
ऑनबोर्डेड कहने से पहले सुनिश्चित करें कि आप बिना अनुमान के इनका उत्तर दे सकते हैं:
यदि आप एक आइटम गायब पाएँ, तो व्यापक खोज करने की बजाय एक छोटा केंद्रित पास करें। एक फ्लो चुनें, उसे DB सीमा तक फ़ॉलो करें, फिर रुकें और जो सीखा उसे लिखें। जब कुछ अस्पष्ट हो, उसे एक प्रश्न के रूप में कैप्चर करें, न कि एक पैरा के रूप में। "Role X कहाँ बनता है?" "auth भ्रमित है" से ज्यादा उपयोगी है।
एक अच्छा अंतिम टेस्ट: कल्पना करें कि आपको एक फ़ीचर फ्लैग के पीछे एक छोटा फीचर जोड़ने के लिए कहा गया है। अगर आप फाइलें नाम दे सकते हैं जिन्हें आप छूएँगे, चलाने वाले टेस्ट बता सकते हैं, और वो failure modes जिन्हें आप देखेंगे, तो आप पर्याप्त रूप से ऑनबोर्डेड हैं ताकि जिम्मेदारी से योगदान कर सकें।
एक मेन्टल मैप तभी उपयोगी है जब वह वास्तविकता से मेल खाता हो। इसे एक जीवन्त आर्टिफैक्ट की तरह इलाज करें, एक बार करने वाला काम नहीं। इसे वास्तविक रखने का सबसे आसान तरीका है कि जिन परिवर्तनों से व्यवहार प्रभावित होता है, उनके तुरंत बाद इसे अपडेट करें।
एक हल्का रूटीन बड़े रिवाइट्स से बेहतर है। उन कामों से अपडेट जोड़ें जो आप पहले से कर रहे हैं:
ऑनबोर्डिंग डॉक को कोड के पास रखें और उसी अनुशासन के साथ वर्शन करें जैसे कोडबेस। छोटे डिफ़ पढ़े जाते हैं। बड़े डॉक रिवाइट्स अक्सर स्किप हो जाते हैं।
जब डिप्लॉयस जोखिमपूर्ण हों, तो लिखें कि अगले व्यक्ति को तेज़ी से कैसे recover करना है: क्या बदला, क्या देखना है, और कैसे रोलबैक करें। अगर आपकी प्लेटफ़ॉर्म snapshots और rollback को सपोर्ट करती है, तो स्नैपशॉट नाम, कारण, और फिक्स के बाद "ठीक" क्या दिखता है जोड़ें।
अगर आप Koder.ai (koder.ai) के साथ बनाते हैं, तो planning mode आपकी Q&A से एक सुसंगत मॉड्यूल मैप और ऑनबोर्डिंग नोट ड्राफ्ट करने में मदद कर सकता है, और source code export समीक्षकों को परिणाम को सत्यापित करने का साफ़ तरीका देता है।
अंत में, अगले डेवलपर के लिए एक हैंडऑफ़ चेकलिस्ट परिभाषित करें जिसे उसे अनुमान न लगाना पड़े:
अच्छी तरह किया जाए तो, Claude Code कोडबेस ऑनबोर्डिंग के लिए एक आदत बन जाता है: हर परिवर्तन अगले व्यक्ति के लिए एक स्पष्ट मैप छोड़ता है।
उपयोगी मेन्टल मैप के लिए प्रयास करें, न कि हर चीज़ का पूरा समझना।
एक मजबूत 1–2 दिन का आउटपुट होना चाहिए:
उसे ठोस आर्टिफैक्ट दें ताकि वह अनुमान लगाने की बजाय असली कोड पर इशारा कर सके:
एक स्पष्ट बाउंड्री के साथ एक संकीर्ण हिस्सा चुनें。
एक अच्छा डिफ़ॉल्ट स्कोप है:
स्पष्ट रूप से जो आउट-ऑफ-स्कोप है उसे लिखें (अन्य सर्विसेज, लेगेसी मॉड्यूल, कम प्रयोग वाले फीचर्स) ताकि असिस्टेंट भटक न जाए।
पहचान से शुरू करें, फिर आगे बढ़ें:
फाइल पाथ और फ़ंक्शन नाम क्रम में माँगें, और अंत में पूछें: “इसे जल्दी कैसे टेस्ट करूँ?”
सिस्टम जहाँ निर्णय लेता है या स्टेट बदलता है वहाँ जोखिम होता है:
एक साधारण लेबल सिस्टम इस्तेमाल करें और एक प्रमाण स्टेप जोड़ें।
उदाहरण फॉर्मेट:
असिस्टेंट को विवरणों का अनुमान लगाने से रोकें।
मांगें कि वह हर दावे को टैग करे:
जब कुछ unknown हो, तो उसे टीममेट के लिए प्रश्न में बदल दें (“Role X कहाँ पर परिभाषित है?”) बजाय इसके कि खाली जगह को अनुमान से भर दें।
एक हल्का नोट फ़ाइल रखें जिसमें पांच सेक्शन हों:
एक त्वरित, वास्तविक जाँच पर डिफ़ॉल्ट रखें:
यह सुनिश्चित करता है कि आपने जो पथ मैप किया है वही असल में उपयोग हो रहा है।
प्लेटफ़ॉर्म फीचर्स का उपयोग blast radius घटाने और परिवर्तनों को reviewable रखने के लिए करें:
व्यवहारिक डिफ़ॉल्ट्स:
फिर पूछें: “कौन सी चीज़ चुपचाप टूट सकती है, और हमें कैसे पता चलेगा?”
संक्षिप्त रखें ताकि आप इसे वास्तव में अपडेट कर सकें।
हर फ्लो में एक लाइन जोड़ें: “इसे कैसे टेस्ट करूँ?” ताकि यह चेकलिस्ट बन जाए।
यह ऑनबोर्डिंग टास्क जैसे “एक गार्डरेल जोड़ें”, “वैलिडेशन कड़ा करें”, या “एक एरर पाथ सुधारें” के लिए खासकर अच्छा काम करता है।