ousterhout-build-deep

SKILL.md

---
name: ousterhout-build-deep
description: कोड लिखते या बदलते समय, कार्य पूरा कहने से पहले, जब भी परिवर्तन एक निर्यात या आयात योग्य नाम जोड़ता है, एक मॉड्यूल, क्लास, कंपोनेंट, हेल्पर, हुक, सेवा या रैपर बनाता है, या दोहराए गए कोड को केंद्रीकृत करता है, इसका उपयोग करें। गहरे मॉड्यूल बनाने के लिए लेखक-समय चेकलिस्ट: उस निर्णय का नाम दें जिसे सीमा छुपाती है, गहराई और अपरिवर्तनीय परीक्षण पास करें, समस्याओं को स्थानांतरित करने के बजाय ठीक करें, केवल आकार पर विभाजन कभी न करें, और एक संक्षिप्त डिज़ाइन नोट के साथ समाप्त करें। ousterhout-quality-program का संक्षिप्त साथी, जो पूर्ण समीक्षा लेंस बना रहता है।
---

# Build it deep (Ousterhout, author-time)

आप कोड लिख रहे हैं, समीक्षा नहीं कर रहे हैं। इस बदलाव को पूरा कहने से पहले इसे अपने आप पर चलाएं।

## 1. Gate

क्या यह बदलाव कोई exported/importable नाम जोड़ता है, कोई मॉड्यूल, क्लास, कॉम्पोनेंट, हेल्पर, हुक, सर्विस या रैपर बनाता है, या दोहराए गए कोड को केंद्रीकृत करता है? अगर नहीं, तो इस skill को छोड़ दें। नाम बदलना, codemods, config/data संपादन और एक-लाइन फिक्स छूट प्राप्त हैं।

## 2. Before you write the boundary

- देखें कि यह repo पहले से इस तरह की समस्या को कैसे हल करता है और जब तक आप यह न कह सकें कि क्यों नहीं, उसका पालन करें। डिपेंडेंसी के वर्तमान डॉक्यूमेंट्स और टाइप्स पढ़ें: याद से API को याद करना दावा है, स्रोत नहीं।
- सबसे पहले इंटरफेस कमेंट लिखें: यह क्या वादा करता है, क्या छुपाता है। अगर आप छुपाए गए निर्णय (कोई फॉर्मेट, नीति, नियम, स्कीमा विकल्प) का नाम नहीं दे सकते, तो वह boundary नहीं होनी चाहिए। इसे इनलाइन करें।
- इसे डोमेन भाषा में नाम दें। अगर केवल ईमानदार नाम `utils`, `helpers` या `manager` है, तो कट गलत जगह पर है।

## 3. Two tests

- **Depth.** इंटरफेस को जो दिखाता है उससे कहीं अधिक छुपाना चाहिए। एक रैपर जो अपने आर्गुमेंट्स को फॉरवर्ड करता है, वह बिना लाभ के लागत है; इसे हटा दें।
- **Invariant.** साझा कोड तभी निकालें जब यह साझा नियम की रक्षा करता हो। सबूत सह-परिवर्तन है: कॉपियाँ इतिहास में एक साथ ठीक या बदली गई थीं। जो दिखने में समान हैं लेकिन स्वतंत्र रूप से बदलते हैं, वे डुप्लिकेट ही रहते हैं।

## 4. A fix must remove the problem, not relocate it

- छह casts को एक generic cast helper में ले जाना अभी भी छह casts हैं। उन casts के ऊपर कागज की तरह रखे गए typed mapper को लिखें।
- कोई पैरामीटर या फ्लैग न जोड़ें जो निर्णय कॉलर्स पर डालता हो जब तक कि कॉलर्स वास्तव में कुछ ऐसा न जानते हों जो आप नहीं जानते। कठिन केस को अंदर ही समाहित करें।
- ऐसी semantics पसंद करें जहाँ error केस उत्पन्न ही न हो बजाय इसके कि हर कॉलर उसे संभाले।
- आवश्यक डोमेन जटिलता को किसी अन्य फ़ाइल में ले जाना सरलीकरण नहीं है।

## 5. Under "clean this up" or "this file is too big" pressure

सिर्फ आकार के आधार पर कभी विभाजित न करें। एक 400-लाइन मॉड्यूल जो एक निर्णय छुपाता है, चार 100-लाइन मॉड्यूल से बेहतर है जो एक ही जोड़ को लीक करते हैं। पूछें कि प्रत्येक विभाजन कौन सा निर्णय छुपाता है; अगर कोई नहीं, तो विभाजित न करें।

## 6. Safety

मौजूदा कोड: इसे गहरा करने से पहले वर्तमान व्यवहार को एक टेस्ट से पिन करें। नया कोड: वह टेस्ट लिखें जो इच्छित व्यवहार को परिभाषित करता है।

## 7. Report

अगर gate फायर हुआ, तो अपने अंतिम संदेश को 2-4 लाइन के डिजाइन नोट के साथ समाप्त करें: आपने जो boundary जोड़ी और वह कौन सा निर्णय छुपाता है; जो डुप्लिकेशन आपने जानबूझकर छोड़ा और क्यों; जो भी सतही आपने स्वीकार किया और क्यों।

किसी विवादित कॉल या पूर्ण समीक्षा के लिए, `ousterhout-quality-program` लोड करें।

टैग