كود نظيف في TypeScript: المبادئ والأمثلة للممارسين

كود نظيف في TypeScript: المبادئ والأمثلة التطبيقية

الكود النظيف (Clean Code) ليس مجرد مصطلح عصري، بل هو مهارة أساسية للمطور المحترف. في سياق TypeScript، الذي يضيف الكتابة النمطية الثابتة إلى عالم JavaScript الديناميكي، تصبح مبادئ الكود النظيف أكثر أهمية. يمنحنا TypeScript أدوات قوية لتوثيق الكود ذاتيًا، ولكن بدون نهج صحيح، يمكن أن تتحول إلى فوضى.

في هذه المقالة، سنستعرض المبادئ الأساسية لـ Clean Code فيما يتعلق بـ TypeScript وننظر في أمثلة عملية ستساعدك على كتابة كود أكثر قابلية للقراءة والصيانة والموثوقية.

1. التسمية: تحدث بلغة الأعمال

أول وأوضح مبدأ في Clean Code هو التسمية الصحيحة. يجب أن تعكس أسماء المتغيرات والدوال والكلاسات والواجهات جوهرها ونية المطور. TypeScript مع كتابته النمطية الصارمة يسمح بجعل الأسماء أكثر إفادة.

مثال سيء:

// ماذا تفعل هذه الدالة؟ كم من الوقت تحتاج لفهم ذلك؟function d(a: number, b: number): number {    return a * b - (a + b);}

// وما هذه الواجهة؟interface I {    n: string;    a: number;    e: string;}

مثال جيد:

// دالة حساب الخصم مع مراعاة الحد الأدنىfunction calculateDiscountedPrice(price: number, discountPercent: number): number {    const discountAmount = price * (discountPercent / 100);    return price - discountAmount;}

// واجهة المستخدم مع حقول واضحةinterface UserProfile {    name: string;    age: number;    email: string;}

قواعد لـ TypeScript:

• الواجهات — استخدم الأسماء بدون بادئة I (مثل User بدلاً من IUser). يوصي TypeScript الحديث و ESLint بهذا النهج.
• الأنواع — للاتحادات المعقدة استخدم الرمز | وأسماء ذات معنى: StatusType، ApiResponse.
• المتغيرات المنطقية — ابدأ بـ is، has، should: isActive، hasPermission.
• الدوال — استخدم الأفعال: getUserData، validateEmail، processOrder.

2. SOLID في TypeScript: التطبيق العملي

مبادئ SOLID (المسؤولية الفردية، مفتوح-مغلق، استبدال ليسكوف، فصل الواجهات، عكس التبعية) تنطبق بشكل ممتاز على TypeScript بفضل دعمه للواجهات والكلاسات المجردة والأدوية (Generics).

مبدأ المسؤولية الفردية (SRP): يجب أن يكون للكلاس سبب واحد فقط للتغيير.

// انتهاك SRP: الكلاس يفعل الكثيرclass UserService {    createUser(data: any) { /* ... */ }    sendEmail(email: string) { /* ... */ }    generateReport() { /* ... */ }}

// النهج الصحيح: فصل المسؤولياتclass UserRepository {    save(user: User): void { /* ... */ }}

class EmailService {    sendWelcomeEmail(email: string): void { /* ... */ }}

class ReportGenerator {    generateUserReport(users: User[]): Report { /* ... */ }}

مبدأ استبدال باربرا ليسكوف (LSP): يجب أن تكون الفئات الفرعية قابلة للتبادل مع الفئة الأساسية. في TypeScript، هذا مهم بشكل خاص عند التعامل مع الوراثة.

// انتهاك LSP: الفئة الفرعية تضيق العقدclass Bird {    fly(): void { console.log('Flying'); }}

class Penguin extends Bird {    fly(): void {        throw new Error('Penguins cannot fly!');    }}

// الصحيح: استخراج واجهةinterface Flyable {    fly(): void;}

class Bird implements Flyable {    fly(): void { console.log('Flying'); }}

class Penguin {    s