दैनिक कोडिंग प्रक्रियाएं: विश्लेषण, बग फिक्स, रिफैक्टर और परीक्षण

📚 सीरीज नेविगेशन: पिछला लेख 13 · प्रॉम्प्ट (Prompt) लिखने की कला स्पष्ट और सटीक निर्देश लिखने की कला को समझाता है। यह लेख एक कदम आगे बढ़ता है: दैनिक कोडिंग के 80% कार्य इन्हीं चार श्रेणियों (विश्लेषण, बग फिक्स, रिफैक्टर और परीक्षण) में आते हैं, और यहाँ मैं आपको चारों के लिए एक-एक करके सटीक कार्य प्रवाह बताऊंगा जिनका आप सीधे उपयोग कर सकते हैं। अगला लेख 15 · अनुमतियाँ, सैंडबॉक्स और अनुमोदन के बारे में है।

पिछले सप्ताह Codex का उपयोग शुरू करने वाले एक सहकर्मी के साथ हुई बातचीत देखें:

सहकर्मी: "मैंने Codex से एक बग ठीक करने के लिए कहा, उसने एरर ठीक कर दी और मैंने कोड सबमिट कर दिया। लेकिन अगले दिन वही एरर दोबारा आ गई, ऐसा क्यों हुआ?"

मैं: "क्या तुमने कोडिंग से पहले उसे वास्तविक कारण (root cause) ढूंढने के लिए कहा था? क्या तुमने उस एरर के लिए टेस्ट फ़ाइल लिखी थी?"

सहकर्मी: "...अरे? बग ठीक करने का मतलब केवल एरर हटाना नहीं है क्या?"

यही गलती होती है। उन्होंने एरर का न दिखना ही एरर का ठीक होना मान लिया, और उस बग के दोबारा आने का कोई रास्ता नहीं रोका। वास्तव में, विश्लेषण, बग फिक्स, रिफैक्टर और परीक्षण, इन चारों कार्यों को करने के सटीक तरीके हैं—नियम सही होने पर Codex बहुत तेज़ी और सुरक्षा से काम करता है; नियम गलत होने पर कोड में बाद में एरर आ सकती है।

पिछला लेख निर्देशों के सामान्य नियमों पर था, और यह लेख कोडिंग के चार मुख्य परिदृश्यों पर आधारित है। मैंने अपने कोडिंग अनुभव के आधार पर ये चार कार्य प्रवाह तैयार किए हैं, जो Codex की कार्यशैली के अनुकूल हैं—जैसे वह आपके एडिटर की खुली फाइलों को देखता है, शेल में @ से फाइलों को संदर्भ में लेता है, और स्वतः सत्यापन (tests) चलाता है।

इस लेख को पढ़ने के बाद, आपको मिलेगा:

• चार मुख्य कोडिंग कार्यों (विश्लेषण / बग फिक्स / रिफैक्टर / परीक्षण) के लिए सीधे उपयोग किए जा सकने वाले कार्य प्रवाह (IDE और CLI दोनों के लिए)
• प्रत्येक कार्य प्रवाह के नियमों के पीछे का तार्किक कारण
• चारों कार्यों की तुलनात्मक तालिका
• एक वास्तविक बग फिक्स करने का चरण-दर-चरण अभ्यास

⚠️ कमांड्स,斜杠 कमांड्स और डिफ़ॉल्ट व्यवहार Codex के आधिकारिक दस्तावेज़ों पर आधारित हैं; मॉडल के नाम, सेटिंग्स बदल सकते हैं।

---

01 कोडिंग के चार कार्य

काम शुरू करने से पहले, इन चारों कार्यों के स्वभाव को समझें। ये Codex से अलग-अलग स्तर की अनुमतियाँ मांगते हैं:

सादृश्य: रसोई की चार अलग-अलग छुरियां। सब्जी काटने की छुरी अलग होती है और हड्डी काटने की अलग। यदि आप गलत छुरी का उपयोग करेंगे, तो वह खराब हो जाएगी।

चारों कार्यों का मुख्य अंतर: क्या यह कोड में बदलाव करता है?

कार्य	क्या कोड बदलता है	Codex का मुख्य काम	आपकी भूमिका
1. प्रोजेक्ट विश्लेषण	❌ नहीं (सिर्फ पढ़ना)	फ़ाइलें पढ़ना और समझाना	विश्लेषण की पुष्टि करना
2. बग फिक्स करना	✅ हाँ	एरर ढूंढना, कारण बताना और सुधारना	एरर लॉजिक और टेस्ट की जांच
3. रिफैक्टर करना	✅ हाँ (लॉजिक नहीं बदलता)	कोड को साफ और बेहतर बनाना	यह देखना कि पुराना काम प्रभावित तो नहीं हुआ
4. परीक्षण (tests) लिखना	✅ हाँ (नई फ़ाइलें जोड़ना)	टेस्ट फाइलों को बनाना	एरर कंडीशन्स की कवरेज जांचना

विश्लेषण में कोई जोखिम नहीं होता (वह केवल कोड पढ़ता है); बग फिक्स और रिफैक्टर में वह फाइलों को बदलता है, इसलिए पहले योजना समझना आवश्यक है; टेस्ट लिखने में वह नई फाइलें जोड़ता है, जहाँ आपको यह देखना होता है कि उसने सभी संभावित एरर कंडीशन्स के टेस्ट लिखे हैं या नहीं।

दस्तावेज़ों में लिखा बुनियादी नियम:

Codex तब अधिक सटीक परिणाम देता है जब वह अपने काम की जांच खुद कर सके। निर्देश में एरर चेक करने के कमांड्स, टेस्ट फाइलें और प्रोजेक्ट रूल्स शामिल करें ताकि वह काम की पुष्टि कर सके।

यह इन चारों कार्य प्रवाहों का मुख्य आधार है। नीचे हम समझेंगे कि प्रत्येक कार्य में Codex को स्वतः जांच का विकल्प कैसे दिया जाता है।

💡 संक्षेप में: चारों कार्यों को समझें—विश्लेषण पूरी तरह सुरक्षित है, कोडिंग बदलावों में पहले योजना समझें; और हमेशा कोडिंग के बाद टेस्ट चलाने का नियम सेट करें।

(आरेख की कोडिंग को मूल रूप में रहने दें)

---

02 प्रोजेक्ट विश्लेषण: बड़े से छोटे स्तर की खोज

सबसे सामान्य परिदृश्य: जब आपको एक नया और बिल्कुल अपरिचित प्रोजेक्ट मिलता है, और आपको उसे समझना होता है।

पहले आप एक-एक करके फाइलों को खोलते थे जिसमें बहुत समय नष्ट होता था। अब Codex आपके प्रोजेक्ट को वर्कस्पेस मानकर खुद पूरा कोड पढ़ सकता है, आपको बस प्रश्न पूछने होते हैं।

सादृश्य: नए मॉल में जाना। पहले आप मॉल का लेआउट मैप देखते हैं (आर्किटेक्चर), फिर उस दुकान का फ्लोर ढूंढते हैं (मॉड्यूल), और अंत में वहां जाने का रास्ता देखते हैं (फ्लो)। बड़े से छोटे स्तर की ओर बढ़ना, यही कोडिंग विश्लेषण का सही तरीका है।

यहाँ ध्यान रखें: IDE एक्सटेंशन और CLI में संदर्भ (context) लेने का तरीका अलग है:

IDE एक्सटेंशन स्वतः ही खुली फाइलों और सिलेक्टेड कोड को संदर्भ में ले लेता है; लेकिन CLI में आपको @ लगाकर फ़ाइल का पाथ स्पष्ट रूप से लिखना होता है।

IDE में कोडिंग विश्लेषण

मुख्य फाइलों को एडिटर में खोलें, कोड सिलेक्ट करें और चैट में निर्देश दें:

解释一下请求是怎么流过我选中的这段代码的。

请包含：
- 每个涉及的模块各自负责什么，简短说明
- 哪些数据被校验、在哪里校验
- 改这块时要小心的一两个「坑」

(चीनी निर्देश का अर्थ: "चयनित कोड में डेटा फ्लो समझाएं। प्रत्येक मॉड्यूल का कार्य, डेटा वैलिडेशन की जगह, और कोडिंग के मुख्य खतरे बताएं।")

विश्लेषण की पुष्टि के लिए आप यह भी जोड़ सकते हैं:

把这个请求流程总结成带编号的步骤列表，然后列出涉及的文件。

(चीनी निर्देश का अर्थ: "फ्लो को स्टेप्स में लिखें और संबंधित फाइलों की सूची दें")

CLI में कोडिंग विश्लेषण

सत्र शुरू करें:

codex

(कमांड को मूल रूप में रहने दें)

अब @ लगाकर फाइलें बताएं:

我要搞懂这个服务用的协议。读一下 @foo.ts @schema.ts，
讲讲它的数据结构和「请求 / 响应」流程，重点说清哪些字段必填、
消息格式，以及向后兼容的规则。

(चीनी निर्देश का अर्थ: "stats.ts और schema.ts को पढ़कर डेटा स्ट्रक्चर और रिक्वेस्ट-रिस्पॉन्स फ्लो समझाएं")

सुरक्षित उपयोग के लिए: विश्लेषण के दौरान अनुमति स्तर को /permissions लिखकर Read Only (सिर्फ पढ़ने का मोड) पर सेट कर लें, ताकि Codex गलती से भी कोई फ़ाइल न बदल सके।

पेमेंट प्रोजेक्ट को समझने के लिए मैंने इसी तरीके का उपयोग किया था, और कुछ ही घंटों में मुझे प्रोजेक्ट का पूरा फ्लो समझ आ गया।

विश्लेषण कार्य प्रवाह की तुलना:

चरण	IDE एक्सटेंशन	CLI
1. संदर्भ देना	फ़ाइल खोलें, कोड सिलेक्ट करें	@ के साथ फ़ाइल का पाथ लिखें
2. मुख्य आर्किटेक्चर	"प्रोजेक्ट का आर्किटेक्चर समझाएं"	कंबाइन फाइलों के साथ समान प्रश्न
3. मॉड्यूल खोजना	"पेमेंट मॉड्यूल किस फ़ाइल में है"	समान प्रश्न
4. फ्लो ट्रैक करना	"रजिस्ट्रेशन का फ्लो बताएं"	समान प्रश्न
5. फाइनल लिस्ट	स्टेप-बाय-स्टेप सारांश मांगें	समान प्रश्न
सुरक्षा	-	अनुमति स्तर को Read Only सेट करें

💡 संक्षेप में: कोडिंग विश्लेषण बड़े आर्किटेक्चर से शुरू होकर फाइलों और कोड फ्लो तक जाता है; IDE में फाइलों को खोलें और CLI में @ से क्रेडेंशियल्स दें।

---

03 बग फिक्स: एरर → रूट कॉज → बदलाव → टेस्ट

बग फिक्स करना बहुत सामान्य काम है, लेकिन इसमें गलतियों की संभावना अधिक होती है।

गलती क्या होती है: एरर लॉग देकर सीधे कहना "इसे ठीक करें", और Codex द्वारा एरर लाइन को डिलीट या ब्लॉक कर देना। एरर का न दिखना एरर का ठीक होना नहीं है।

सादृश्य: पाइप से पानी लीक होना। आप केवल लीक के नीचे बाल्टी नहीं रख सकते (एरर छिपाना)—आपको पानी के फ्लो को रोककर पाइप का फटा हिस्सा खोजना होगा (वास्तविक कारण), उसे बदलना होगा, और फिर पानी चालू करके चेक करना होगा (टेस्ट)।

बग फिक्स करने की प्रक्रिया:

1. एरर और क्रेडेंशियल्स देना: एरर लॉग, क्रेडेंशियल्स, और वे फाइलों के पाथ जिन पर संदेह हो।
2. कारण ढूंढना: निर्देश में कहें "पहले एरर का वास्तविक कारण ढूंढें, अभी कोड न बदलें"।
3. कोड बदलना: कारण स्पष्ट होने पर कोड बदलने के लिए कहें, और निर्देश दें "न्यूनतम आवश्यक कोड ही बदलें"।
4. टेस्ट चलाना: कोडिंग के बाद टेस्ट फ़ाइल अवश्य रन करवाएं ताकि पुष्टि हो सके।

दस्तावेज़ों में लिखा है:

修复之后，跑一遍 lint + 最小的相关测试套件。把用到的命令和结果报给我。

(चीनी निर्देश का अर्थ: "सुधार के बाद लिनटर और टेस्ट चलाकर परिणाम बताएं")

यह कोडिंग को सुरक्षित रखता है—यदि भविष्य में कोई और उस कोड को बदलेगा, तो टेस्ट फेल होने पर एरर तुरंत पता चल जाएगी।

IDE में बग फिक्स

संबंधित फाइलों को खोलें और निर्देश दें:

找出导致「显示已保存但没真正持久化」的 bug。
提出修复方案后，告诉我怎么在界面上验证它修好了。

(चीनी निर्देश का अर्थ: "सेव होने पर भी डेटा न दिखने का बग ढूंढें, सुधार बताएं और चेक करने की विधि बताएं")

CLI में बग फिक्स

प्रोजेक्ट डायरेक्टरी में Codex शुरू करें और यह निर्देश दें (इस ढांचे में एरर, टेस्ट और क्रेडेंशियल्स शामिल हैं):

codex

Bug：在设置页点「保存」，有时显示「已保存」但改动没真正生效。

复现：
1) 启动应用：npm run dev
2) 进入 /settings
3) 切换「开启提醒」开关
4) 点保存
5) 刷新页面：开关又弹回去了

约束：
- 不要改 API 的形态。
- 修复尽量小，可行的话补一个回归测试。

先在本地复现这个 bug，然后提出补丁并跑检查。

(कोड ब्लॉक के चीनी निर्देशों को ही रहने दें, इनका अर्थ क्रमशः: बग विवरण, एरर की क्रेडेंशियल्स, कोडिंग सीमाएं, और कार्य निर्देश)

बग फिक्स करने का प्रॉम्प्ट ढांचा:

Bug：[बग का विवरण]
复现：[एरर लाने के चरण - स्टेप 1, 2, 3]
约束：[कोडिंग की सीमाएं - एपीआई न बदलें आदि]
怀疑文件：[@ के साथ संदिग्ध फाइलें]
请你：先复现 → 定位根因（先别改）→ 给最小修复 → 跑 lint 和相关测试报结果。

💡 संक्षेप में: बग फिक्स करने का नियम—एरर लॉग और क्रेडेंशियल्स दें, कारण ढूंढने के बाद ही कोड बदलवाएं, और कोडिंग के बाद टेस्ट रन करवाएं।

---

04 रिफैक्टर: योजना → छोटे बदलाव → लॉजिक सुरक्षा → टेस्ट

रिफैक्टर करना जोखिम भरा काम है क्योंकि हम उस कोड को बदलते हैं जो पहले से सही काम कर रहा है।

उद्देश्य कोड को साफ और बेहतर बनाना होता है, लेकिन प्रोजेक्ट का पुराना लॉजिक बिल्कुल प्रभावित नहीं होना चाहिए। यदि रिफैक्टर के बाद लॉजिक बदल गया, तो वह अनपेक्षित एरर का कारण बन सकता है।

सादृश्य: चलती ट्रेन के पहिये बदलना। ट्रेन रुकनी नहीं चाहिए और यात्रियों को पता भी नहीं चलना चाहिए, बस नीचे के पहिये बदल जाने चाहिए।

बड़ी गलतियाँ दो हैं: पूरा कोड एक साथ बदलना (जांचना कठिन हो जाता है), और बिना टेस्ट फ़ाइल के रिफैक्टर करना (लॉजिक चेक करने का कोई रास्ता नहीं रहता)।

पहला चरण: योजना बनवाना

निर्देश दें कि Codex पहले रिफैक्टर करने की योजना बताए। यदि आपके पास $plan स्किल है, तो उसे कॉल करें (चैट में $plan टाइप करके), या सीधे चैट में कहें "पहले योजना बताएं, अभी कोड न बदलें":

$plan

我们要重构 auth 子系统，目标：
- 拆分职责（token 解析 / 会话加载 / 权限判断分开）
- 减少循环依赖
- 提升可测试性

约束：
- 对用户可见的行为不能变
- 公开 API 保持稳定
- 给一份分步迁移计划

(चीनी निर्देश को ही रहने दें)

योजना देखने के बाद उसे और स्पष्ट करें:

修改一下计划：
- 明确每个里程碑具体动哪几个文件
- 加一个回滚策略

(चीनी निर्देश को ही रहने दें)

इससे बड़ा काम छोटे-छोटे सुरक्षित चरणों में बट जाएगा।

दूसरा चरण: प्रत्येक चरण के बाद टेस्ट

योजना फाइनल होने पर एक-एक करके कोडिंग करवाएं, और हर बदलाव के बाद टेस्ट रन करवाएं।

नियम: बिना टेस्ट फ़ाइल वाले कोड को रिफैक्टर न करवाएं। यदि कोड में पहले से टेस्ट नहीं है, तो:

रिफैक्टर करने से पहले कोड के लिए टेस्ट लिखवाएं, ताकि पुराना लॉजिक सुरक्षित हो जाए, और फिर रिफैक्टर करें।

मैंने एक बार बिना टेस्ट वाले फ़ंक्शन को रिफैक्टर करवाया था, जिससे उसका नेगेटिव वैल्यू का कैलकुलेशन गड़बड़ हो गया और एरर आ गई। उसके बाद से मैं कोडिंग से पहले टेस्ट अवश्य लिखवाता हूँ।

रिफैक्टर कार्य प्रवाह:

चरण	क्या करना है	ध्यान दें
1. योजना	योजना बनवाना	लॉजिक न बदलने और एपीआई स्थिर रखने का नियम
2. रिफाइन	योजना को छोटे चरणों में बांटना	किस चरण में कौन सी फ़ाइल बदलेगी
3. टेस्ट	यदि टेस्ट नहीं है, तो पहले टेस्ट लिखना	पुराना लॉजिक सुरक्षित करना
4. कोडिंग	एक-एक चरण पूरा करना	एक साथ बड़ा कोड न बदलना
5. सत्यापन	हर चरण के बाद टेस्ट रन करना	परिणाम फेल होने पर तुरंत रोलबैक

💡 संक्षेप में: रिफैक्टर का नियम—लॉजिक नहीं बदलना चाहिए; पहले योजना बनवाएं, बिना टेस्ट के काम न शुरू करें, और हर छोटे बदलाव के बाद टेस्ट रन करें।

---

05 परीक्षण (Tests) लिखना: एरर कंडीशन्स की कवरेज

चौथा कार्य: प्रोजेक्ट के लिए टेस्ट लिखना।

Codex टेस्ट लिखने में बहुत कुशल है—दस्तावेज़ों में लिखा है कि वह प्रोजेक्ट के पुराने टेस्ट फाइलों के कोडिंग स्टाइल को खुद पहचान लेता है और उसी फॉर्मेट में नए टेस्ट लिखता है। लेकिन यहाँ ध्यान रखें:

यदि आप विशेष रूप से नहीं कहेंगे, तो वह केवल सामान्य कोडिंग (happy path - जब सब सही हो) के ही टेस्ट लिखेगा।

जैसे: यदि फ़ंक्शन लिस्ट को रिवर्स करता है, तो वह केवल [1, 2, 3] इनपुट का टेस्ट लिखेगा, लेकिन खाली लिस्ट, सिंगल वैल्यू, या null इनपुट जैसी कंडीशन्स छोड़ देगा, जहाँ वास्तविक एरर आती हैं।

सादृश्य: नई कार का क्रैश टेस्ट। टेस्ट कार को केवल सीधी और साफ सड़क पर चलाने के लिए नहीं होता, बल्कि उसे टकराने, अचानक ब्रेक लगाने (कठिन कंडीशन्स) के लिए होता है।

IDE में टेस्ट लिखना

फाइलें खोलें, फ़ंक्शन को सिलेक्ट करें, कमांड मेनू से "Add to Codex Thread" पर क्लिक करें और चैट में कहें:

给这个函数写单元测试。遵循其他测试里已有的约定。

(चीनी निर्देश का अर्थ: "इस फ़ंक्शन के लिए टेस्ट लिखें, प्रोजेक्ट के स्टाइल का पालन करें")

CLI में टेस्ट लिखना

फाइलों के पाथ @ से दें और एरर कंडीशन्स स्पष्ट रूप से लिखें:

给 @transform.ts 里的 invert_list 函数加测试。
覆盖正常路径，外加边界情况。

(चीनी निर्देश को ही रहने दें)

निर्देशों की तुलना:

❌ गलत प्रॉम्प्ट	✅ सही प्रॉम्प्ट
"इस फ़ंक्शन के लिए टेस्ट लिखें"	"stats.ts के average फ़ंक्शन के लिए टेस्ट लिखें, जिसमें सामान्य कंडीशन्स के साथ खाली लिस्ट, null, और बहुत बड़े इनपुट की एरर कंडीशन्स शामिल हों"

आप यह भी कह सकते हैं:

另外帮想想还有哪些我没列到的边界情况，一并测上。

(चीनी निर्देश का अर्थ: "यदि कोई और एरर कंडीशन छूट गई है, तो उसका भी टेस्ट जोड़ें")

यह कोडिंग को पूरी तरह सुरक्षित रखता है।

परीक्षण कार्य प्रवाह:

चरण	IDE एक्सटेंशन	CLI
1. फ़ंक्शन सिलेक्ट	कोड सिलेक्ट करें → Add to Thread	@ लगाकर फ़ाइल का पाथ दें
2. कोडिंग स्टाइल	"प्रोजेक्ट के टेस्ट स्टाइल का पालन करें"	समान निर्देश
3. एरर कंडीशन्स	"नियम: सामान्य + एरर कंडीशन्स [नाम लिखें]"	समान निर्देश
4. सजेशन	"अन्य संभावित एरर कंडीशन्स भी जोड़ें"	समान निर्देश
5. टेस्ट रन	टेस्ट फाइलें रन करवाएं	समान निर्देश

💡 संक्षेप में: टेस्ट लिखने का नियम—सामान्य कोडिंग के साथ-साथ खाली इनपुट, null जैसी एरर कंडीशन्स के टेस्ट लिखने का निर्देश स्पष्ट रूप से दें।

---

06 अभ्यास: बग फिक्स करने का संपूर्ण चक्र

अब हम एक व्यावहारिक अभ्यास करेंगे। इसके लिए हम 'बग फिक्स' कार्य प्रवाह का उपयोग करेंगे।

अभ्यास के लिए विंडोज़ में PowerShell या Mac में टर्मिनल का उपयोग करें।

पहला कदम: प्रोजेक्ट फोल्डर और फ़ाइल बनाना

mkdir bug-demo
cd bug-demo

calc.py फ़ाइल बनाएं और लिखें:

def average(numbers):
    return sum(numbers) / len(numbers)

(कमांड्स और कोड को मूल रूप में रहने दें)

एरर: यदि इनपुट में खाली लिस्ट [] दी जाए, तो len 0 होने के कारण 'डिवाइड बाय जीरो' एरर आएगी।

दूसरा कदम: Codex शुरू करना

codex

तीसरा कदम: बग फिक्स कार्य प्रवाह के अनुसार निर्देश देना

इनपुट बॉक्स में यह निर्देश टाइप करें:

Bug：调用 calc.py 里的 average([]) 会崩。

复现：
1) 给 average 函数传一个空列表 []
2) 它必现 ZeroDivisionError: division by zero

约束：
- 改动尽量小，别动函数签名。

请你：先复现这个 bug，再定位根因（先别改），然后给最小修复，
最后补一个能复现这个 bug 的回归测试并跑一遍确认通过。

(चीनी निर्देश को ही रहने दें)

अपेक्षित परिणाम: Codex पहले एरर का कारण बताएगा (खाली लिस्ट में len 0 होने के कारण एरर आना), फिर कोड सुधार का diff दिखाएगा, और फिर एक टेस्ट फ़ाइल test_calc.py बनाएगा।

चौथा चरण: बदलाव स्वीकार करना और टेस्ट देखना

diff सही होने पर Yes चुनें। Codex टेस्ट रन करेगा।

अपेक्षित परिणाम: स्क्रीन पर टेस्ट पास होने का परिणाम (PASSED) दिखाई देगा।

पांचवां चरण: बाहर आना और पुष्टि करना

सत्र से बाहर आएं (/exit टाइप करें) और फ़ाइल देखें:

cat calc.py

(विंडोज़ में type calc.py चलाएं)

अपेक्षित परिणाम: calc.py में खाली लिस्ट की एरर हैंडलिंग जुड़ चुकी होगी।

💡 संक्षेप में: इस अभ्यास से स्पष्ट होता है कि बग फिक्स की क्रेडेंशियल्स देने से कोडिंग पूरी तरह सही और टेस्टेड होती है।

---

07 सारांश

इस लेख में हमने चार मुख्य कोडिंग कार्यों को समझा:

कार्य	प्रक्रिया का आधार	ध्यान दें
1. प्रोजेक्ट विश्लेषण	"बड़ा आर्किटेक्चर → मॉड्यूल्स → कोडिंग फ्लो"	सिर्फ पढ़ने का मोड रखें, फाइलों को @ से दें
2. बग फिक्स	"एरर क्रेडेंशियल्स → कारण → न्यूनतम बदलाव → टेस्ट"	एरर छिपाने से बचें, टेस्ट अवश्य लिखें
3. रिफैक्टर	"योजना → छोटे चरण → टेस्ट क्रेडेंशियल्स → टेस्ट रन"	लॉजिक नहीं बदलना चाहिए, बिना टेस्ट के काम न करें
4. परीक्षण (tests)	"सामान्य कोडिंग + एरर कंडीशन्स"	खाली इनपुट, null जैसी एरर कवरेज महत्वपूर्ण है

कोडिंग नियमों को सुरक्षित रखने के लिए क्रेडेंशियल्स और नियमों का ध्यान रखें।

अगले लेख 15 · अनुमतियाँ, सैंडबॉक्स और अनुमोदन में हम सैंडबॉक्स सीमाओं और सुरक्षा सेटिंग्स को विस्तार से समझेंगे।

---

अनुशंसित पठन

• कोडिंग के लिए स्किल्स (Skills) सेट करना
• कार्यों का ऑटोमेशन और शेड्यूलिंग
• क्लाउड पर काम ट्रांसफर करना