TypeScript في الفريق: أسلوب الكود، الاتفاقيات ولا فوضى

لماذا "يعمل" ليس كافيًا للفريق؟

تخيل: تفتح طلب سحب (PR) لشخص آخر، وتجد any في كل خطوة، والمتغيرات مسماة a، b، c، وكل شيء منسق وكأن الكود كتبته قطة تمشي على لوحة المفاتيح. مألوف؟ بمفردك، يمكنك تحمل هذا الكود. لكن في الفريق، هذا طريق للصراعات والأخطاء والليالي الطويلة في مراجعة الكود.

اليوم سنتحدث عن كيفية جعل TypeScript في الفريق ليس مجرد أداة، بل أساسًا موثوقًا. سنناقش أسلوب الكود والاتفاقيات التي ستنقذ أعصابك وتسرع التطوير. بدون إطالة، مع أمثلة حية.

1. الكتابة الصارمة: صديقك الأول

TypeScript يتعلق بالأنواع. لكن العديد من الفرق تستخدمه كـ "TypeScript خفيف"، تاركة any في كل مكان حيث يكون التفكير كسلاً. هذا يقتل السحر كله. الاتفاقية الأولى: حظر any.

سيء:

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

جيد:

interface ApiResponse {    id: number;    name: string;    isActive: boolean;}

function fetchData(url: string): Promise<ApiResponse> {    // ...}

عندما يصف كل مطور بوضوح ما يعيده ويستقبله، يصبح الكود موثقًا ذاتيًا. لم تعد تتساءل: "هل هذه data سلسلة نصية أم كائن؟". الأنواع تتحدث عن نفسها.

2. ESLint + Prettier: إعداد غير قابل للنقاش

إذا كان فريقك لا يزال بدون مدقق (linter) ومنسق (formatter) موحد، توقف وقم بإعدادهما الآن. ESLint يكتشف الأخطاء المنطقية وانتهاكات أسلوب الكود، وPrettier يجعل الكود موحدًا.

إعداد ESLint الأساسي لـ TypeScript:

{  "parser": "@typescript-eslint/parser",  "plugins": ["@typescript-eslint"],  "extends": [    "eslint:recommended",    "plugin:@typescript-eslint/recommended",    "prettier" // يجب أن يكون في النهاية  ],  "rules": {    "@typescript-eslint/no-explicit-any": "error",    "@typescript-eslint/explicit-function-return-type": "warn",    "no-console": "warn"  }}

أضف Prettier بقواعد بسيطة: علامات تبويب بدلاً من مسافات (أو العكس، لكن بشكل موحد)، علامات اقتباس مفردة، فاصلة منقوطة في النهاية. وقم بتفعيل formatOnSave في بيئة التطوير المتكاملة (IDE). هذا سينقذك من النقاشات التي لا نهاية لها حول المسافات البادئة.

3. التسمية: تحدث بلغة واحدة

اتفاقيات التسمية هي مثل قواعد المرور. بدونها، فوضى. في TypeScript، الاتفاقيات التالية مقبولة:

• camelCase للمتغيرات والدوال والطرق: getUserData()، userName
• PascalCase للفئات والواجهات والأنواع: UserProfile، ApiResponse
• UPPER_SNAKE_CASE للثوابت المعروفة وقت الترجمة: MAX_RETRY_COUNT، DEFAULT_TIMEOUT
• البادئة I للواجهات - مثيرة للجدل، لكن العديد من الفرق تستخدمها: IUser. قرروا هذا في البداية.

مثال على تسمية سيئة:

const data = { n: 'Alex', a: 30 }; // ما هما n و a؟

جيد:

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

4. هيكل المشروع: لا تخفي كل شيء في ملف واحد

عندما يكبر المشروع، غياب الهيكل هو العدو الرئيسي. اتفق على المجلدات مسبقًا. إليك خيار شائع لمشروع TypeScript:

• src/ - الكود المصدري
• src/components/ - مكونات واجهة المستخدم (إذا كان React)
• src/utils/ - دوال مساعدة
• src/types/ - الأنواع والواجهات العامة
• src/services/ - التعامل مع API
• src/hooks/ - الخطافات المخصصة (إذا كان React)