टीम में TypeScript: कोड स्टाइल, कन्वेंशन और कोई अराजकता नहीं

क्यों "काम करता है" — टीम के लिए पर्याप्त नहीं है?

कल्पना करें: आप किसी और का PR खोलते हैं, और वहाँ हर कदम पर any है, वेरिएबल्स का नाम a, b, c रखा गया है, और सब कुछ इस तरह फॉर्मेट किया गया है जैसे कोड कीबोर्ड पर चलने वाली बिल्ली ने लिखा हो। परिचित लगता है? अकेले ऐसे कोड को सहा जा सकता है। लेकिन टीम में, यह संघर्षों, बग्स और कोड-रिव्यू में नींद हराम रातों का रास्ता है।

आज हम बात करेंगे कि टीम में TypeScript को केवल एक उपकरण नहीं, बल्कि एक विश्वसनीय नींव कैसे बनाया जाए। हम कोड स्टाइल और कन्वेंशन पर चर्चा करेंगे जो आपकी नसों को बचाएंगे और डेवलपमेंट को गति देंगे। बिना उबाऊपन के, जीवंत उदाहरणों के साथ।

1. सख्त टाइपिंग: आपका पहला दोस्त

TypeScript टाइप्स के बारे में है। लेकिन कई टीमें इसे "TypeScript-lite" के रूप में उपयोग करती हैं, जहाँ भी सोचने में आलस आता है वहाँ any छोड़ देती हैं। यह सारा जादू खत्म कर देता है। पहला कन्वेंशन: any को प्रतिबंधित करें।

खराब:

function fetchData(url: string): any {\n    // ...\n}

अच्छा:

interface ApiResponse {\n    id: number;\n    name: string;\n    isActive: boolean;\n}\n\nfunction fetchData(url: string): Promise<ApiResponse> {\n    // ...\n}

जब प्रत्येक डेवलपर स्पष्ट रूप से बताता है कि वह क्या लौटा रहा है और क्या स्वीकार कर रहा है, तो कोड स्व-दस्तावेजीकरण बन जाता है। आप अब अनुमान नहीं लगाते: "यह data स्ट्रिंग है या ऑब्जेक्ट?" टाइप्स खुद बोलते हैं।

2. ESLint + Prettier: एक सेटअप जिस पर चर्चा नहीं होती

यदि आपकी टीम में अभी भी एक समान लिंटर और फॉर्मेटर नहीं है, तो रुकें और उन्हें अभी सेट करें। ESLint तार्किक त्रुटियों और कोड स्टाइल उल्लंघनों को पकड़ता है, और Prettier कोड को एकरूप बनाता है।

TypeScript के लिए बेसिक ESLint कॉन्फ़िगरेशन:

{\n  "parser": "@typescript-eslint/parser",\n  "plugins": ["@typescript-eslint"],\n  "extends": [\n    "eslint:recommended",\n    "plugin:@typescript-eslint/recommended",\n    "prettier" // अंत में अनिवार्य\n  ],\n  "rules": {\n    "@typescript-eslint/no-explicit-any": "error",\n    "@typescript-eslint/explicit-function-return-type": "warn",\n    "no-console": "warn"\n  }\n}

सरल नियमों के साथ Prettier जोड़ें: स्पेस के बजाय टैब (या इसके विपरीत, लेकिन एकरूप), सिंगल कोट्स, अंत में सेमीकोलन। और IDE में formatOnSave चालू करें। यह इंडेंटेशन पर अंतहीन बहस से बचाएगा।

3. नामकरण: एक ही भाषा में बोलें

नामकरण कन्वेंशन सड़क के नियमों की तरह हैं। इनके बिना — अराजकता। TypeScript में ये सम्मेलन स्वीकार किए जाते हैं:

\n
• camelCase वेरिएबल्स, फंक्शन्स, मेथड्स के लिए: getUserData(), userName
\n
• PascalCase क्लासेस, इंटरफेसेस, टाइप्स के लिए: UserProfile, ApiResponse
\n
• UPPER_SNAKE_CASE कंपाइल टाइम पर ज्ञात कॉन्स्टेंट के लिए: MAX_RETRY_COUNT, DEFAULT_TIMEOUT
\n
• I प्रीफिक्स इंटरफेसेस के लिए — विवादास्पद है, लेकिन कई टीमें इसका उपयोग करती हैं: IUser। शुरुआत में ही इस पर निर्णय लें।
\n

खराब नेमिंग का उदाहरण:

const data = { n: 'Alex', a: 30 }; // n और a क्या हैं?

अच्छा:

const userProfile = { name: 'Alex', age: 30 };

4. प्रोजेक्ट संरचना: सब कुछ एक फाइल में न छिपाएं

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

\n
• src/ — सोर्स कोड
\n
• src/components/ — UI कम्पोनेंट्स (यदि React)
\n
• src/utils/ — यूटिलिटी फंक्शन्स
\n
• src/types/ — ग्लोबल टाइप्स और इंटरफेसेस
\n
• src/services/ — API के साथ काम
\n
• src/hooks/ — कस्टम हुक्स (यदि React)
\