مراجعة كود TypeScript: 10 أخطاء تثير حنق الخبراء

مقدمة: لماذا تبدو مراجعة كود TypeScript الخاصة بك مثل الضوء الأحمر على لوحة التحكم؟

هل سبق لك أن أرسلت طلب سحب (pull request)، وبعد ساعة تلقيت 20 تعليقًا من مطور خبير، نصفها يبدأ بعبارة "يمكن تحسين هذا"؟ مألوف. إذا كنت تكتب بلغة TypeScript، ولكن كودك لا يزال يثير لدى زملائك الرغبة في إعادة كتابته من الصفر - فهذه المقالة لك.

نحن في PythonLib نواجه غالبًا مواقف يرتكب فيها المطورون، حتى مع معرفتهم بتركيب TypeScript، نفس الأخطاء. هذه الأخطاء لا تعطل الكود، لكنها تجعله غير قابل للقراءة، وغير آمن، ويصعب صيانته. اليوم سأعرض لكم 10 ملاحظات نموذجية يكتبها الخبراء في مراجعة كود TypeScript، وكيفية تجنبها. استعدوا لإعادة الهيكلة!

1. "Any" - عدوك وليس صديقك

أكثر انتقاد شائع في أي مراجعة كود TypeScript هو استخدام any. يبدو أن كتابة const data: any = await fetch(...) أسهل من التعامل مع الأنواع. لكن الخبراء يرون ذلك كقطعة قماش حمراء.

سيء:

function processUser(user: any) {  console.log(user.name.toUpperCase());}

جيد:

interface User {  id: number;  name: string;  email: string;}

function processUser(user: User): void {  console.log(user.name.toUpperCase());}

لماذا هذا مهم؟ يفقد TypeScript معناه بالكامل إذا استخدمت any. أنت حرفيًا تعطل نظام الأنواع. إذا كانت البيانات تأتي من API - قم بإنشاء واجهة (interface). إذا كان النوع معقدًا - استخدم unknown مع التحقق. هذه إحدى قواعد TypeScript best practices الرئيسية.

2. تجاهل الوضع الصارم (strict mode)

يقوم العديد من المشاريع بتعطيل الوضع الصارم في tsconfig.json، لأن "الأمر أسرع" أو "الأنواع مزعجة". سيلاحظ مطور TypeScript الخبير فورًا أن كودك لا يتحقق من null و undefined.

سيء (strict: false):

function getLength(str: string) {  return str.length; // قد تكون str فارغة (null) وسيؤدي ذلك إلى تعطل}

جيد (strict: true):

function getLength(str: string | null): number {  if (str === null) return 0;  return str.length;}

نصيحة: قم بتفعيل strict: true في tsconfig.json. سيجبرك ذلك على كتابة كود أكثر أمانًا. في مراجعة كود TypeScript سيكون هذا نقطة إيجابية وليست سلبية.

3. السحر بالأنواع: تعقيد مفرط

أحيانًا يحاول المطورون إظهار مدى براعتهم، ويكتبون أنواعًا تجعل حتى الخبراء يحكون رؤوسهم. على سبيل المثال، أنواع شرطية تحتوي على أدوية عامة (generics) متداخلة حيث كان يمكن الاكتفاء بواجهة بسيطة.

سيء (هندسة مفرطة):

type DeepReadonly<T> = {  readonly [P in keyof T]: T[P] extends object ? DeepReadonly<T[P]> : T[P];};

جيد (بساطة):

interface Config {  readonly apiUrl: string;  readonly timeout: number;}

يقدر الخبراء قابلية قراءة الكود. إذا كان من الممكن استبدال نوعك بواجهة تحتوي على ثلاثة حقول - فافعل ذلك. لا تعقد الأمور دون داع.

4. معالجة الأخطاء غير الصحيحة

خطأ نموذجي في مراجعة كود TypeScript هو استخدام try-catch مع any أو كتلة catch فارغة. سيشير الخبراء إلى ذلك فورًا.

سيء:

try {  const data = await fetchData();} catch (e) {  console.log('خطأ');}

جيد:

try {  const data = await fetchData();} catch (error: unknown) {  if (error instanceof Error) {    console.error(error.message);  } else {    console.error('خطأ غير معروف', error);  }}

استخدم unknown للأخطاء. هذا يج