مبادئ الكود النظيف لـ React و TypeScript

اتقن مبادئ الكود النظيف مع أمثلة عملية على React و TypeScript. اكتب برمجيات قابلة للتوسع وسهلة الصيانة بحيث يحبها فريقك بأكمله.

المقدمة

الكود النظيف مجموعة من العادات العملية التي تجعل البرمجيات أسهل قراءةً وفهمًا وصيانة. الفكرة بسيطة: اكتب كودًا يمكن للمطوّر التالي، بما في ذلك أنت في المستقبل، أن يستوعبه بسرعة ويغيّره بثقة. هذا المقال يشرح مبادئ عامة مع أمثلة عملية، بنية مشروع مقترحة، أدوات تدقيق، واستراتيجيات لإعادة الهيكلة بفعالية.

لماذا تهم مبادئ الكود النظيف

العمل في قاعدة شفرة فوضوية يشبه محاولة طهي وجبة معقدة في مطبخ مليء بالأواني المتناثرة. كل تغيير يصبح أبطأ وأكثر عرضة للخطأ. الكود النظيف يقلل الدين التقني ويُسرّع توظيف المطورين الجدد ويحسّن جودة الإنتاجية وثبات تسليم الميزات¹².

الفوائد العملية

• توظيف أسرع للمهندسين الجدد
• تعاون أفضل عبر الفريق
• أخطاء إنتاجية أقل وتصحيح أسرع
• تسليم ميزات مستمر ومستدام

الحجة التجارية

الكود المعقّد والفوضوي يرفع تكاليف الصيانة على المدى الطويل. الاستثمار في مبادئ الكود النظيف يقلل الاحتكاك في تسليم الميزات ويسمح للفريق بالتركيز على خلق القيمة بدلًا من إطفاء الحرائق¹².

مبادئ عملية قابلة للتطبيق

ركز على ثلاث قواعد ذات أثر كبير: مبدأ المسؤولية الواحدة (SRP)، لا تكرر نفسك (DRY)، ولن تحتاجه (YAGNI). تطبيق هذه القواعد يوميًّا يُقلل التعقيد ويُسهّل الاختبار.

مبدأ المسؤولية الواحدة (SRP)

كل وحدة، كائن أو دالة يجب أن تتغير لسبب واحد فقط. عندما يجمع مكوّن واجهات المستخدم منطق الجلب، المعالجة، والعرض، تنشأ أسباب متعددة للتغيير وتصبح الأخطاء أكثر احتمالاً. فصل الاهتمامات يجعل المكوّنات أسهل للاختبار وإعادة الاستخدام.

مثال: فصل جلب البيانات عن العرض في React.

// Messy: Component has multiple responsibilities
const UserProfile = ({ userId }) => {
  const [user, setUser] = useState(null);
  const [error, setError] = useState(null);

  useEffect(() => {
    const fetchUserData = async () => {
      try {
        const response = await fetch(`/api/users/${userId}`);
        if (!response.ok) {
          throw new Error('Failed to fetch user');
        }
        const data = await response.json();
        const formattedName = `${data.firstName} ${data.lastName}`.trim();
        setUser({ ...data, fullName: formattedName });
      } catch (err) {
        setError(err.message);
      }
    };
    fetchUserData();
  }, [userId]);

  if (error) return <p>Error: {error}</p>;
  if (!user) return <p>Loading...</p>;

  return (
    <div>
      <h1>{user.fullName}</h1>
      <p>Email: {user.email}</p>
    </div>
  );
};

أعد الهيكلة باستخراج hook مخصّص يتعامل مع الجلب والتنسيق، تاركًا المكوّن للعرض فقط.

// Clean: Custom hook handles logic
const useUserData = (userId) => {
  // fetch, format, and error logic here
  return { user, error, isLoading };
};

// Clean: Component only renders
const UserProfile = ({ userId }) => {
  const { user, error, isLoading } = useUserData(userId);

  if (isLoading) return <p>Loading...</p>;
  if (error) return <p>Error: {error}</p>;

  return (
    <div>
      <h1>{user.fullName}</h1>
      <p>Email: {user.email}</p>
    </div>
  );
};

لا تكرر نفسك (DRY)

كل قطعة معرفة يجب أن يكون لها تمثيل واحد وموثوق. انسخ/الصق المنطق يخلق عدم تناسق ويضاعف العمل عند التغيير. اجمع المنطق المشترك في أدوات مساعدة، hooks أو خدمات.

لن تحتاجه (YAGNI)

تجنّب التجريد المبكر لبناء حلول عامة لاحتياجات مستقبلية غير مؤكدة. حل مشاكل اليوم اليوم، ثم أعد الهيكلة عندما يتكرر النمط فعلاً.

الكود الذي يوثق نفسه بنفسه

عامل الكود كمحادثة. الأسماء الجيدة توضّح النية وتقلّل الحاجة إلى تعليقات. الأسماء الغامضة تجبر القارئ على تتبّع المنطق بدلًا من فهمه بسرعة.

قواعد للتسمية المقروءة

• واضح وغير غامض: استخدم fetchActiveUsersFromAPI بدلاً من handleData
• قابلة للبحث: فضّل event أو employee بدلًا من e
• قابلة للنطق: userManager بدلًا من usrMgr

مثال تحويل التسمية:

// Before: Vague
const ItemList = ({ data }) => {
  const process = (item) => {
    // ...complex logic
  };

  return (
    <ul>
      {data.map(d => (
        <li onClick={() => process(d)}>{d.name}</li>
      ))}
    </ul>
  );
};

// After: Clear intent
const UserDirectory = ({ inactiveUsers }) => {
  const activateUserSubscription = (user) => {
    // ...logic to activate subscription
  };

  return (
    <ul>
      {inactiveUsers.map(user => (
        <li onClick={() => activateUserSubscription(user)}>
          {user.fullName}
        </li>
      ))}
    </ul>
  );
};

التسمية استثمار صغير بعائد كبير على مدى حياة المشروع.

بنية مشروع قابلة للتوسع (مثال لـ Next.js)

هيكل مجلد واضح يجعل من السهل العثور على الكود وفهم تدفق البيانات. تخطيط مقترح:

• /app — توجيه التطبيق والصفحات
• /components
  • /ui — عناصر واجهة عامة
  • /features — مكونات خاصة بالميزات
• /lib — أدوات مساعدة وعميلات API
• /hooks — hooks مخصصة
• /styles — أنماط وملفات الثيم
• /types — تعريفات TypeScript

هذا التخطيط يساعد الفرق على التوسع دون خلق تداخل وظيفي. للمزيد من تفاصيل البنية انظر دليلنا: دليل بنية Next.js.

كتابة دوال صغيرة ومحددة

الدوال القصيرة التي تفعل شيئًا واحدًا أسهل للاختبار وإعادة الاستخدام. إذا كانت الدالة تحتاج تعليقات لشرح سلوكها، فكّر في تقسيمها.

نصائح عملية:

• استهدف أقل من ثلاث وسائط، واجمع القيم في كائن إذا لزم الأمر
• اجعل الدوال أقل من 25 سطرًا عندما يكون ذلك ممكنًا
• قلّل عمق التعشيش إلى مستويين أو ثلاثة

interface RegistrationOptions {
  username: string;
  email: string;
  password: string;
  shouldSendWelcomeEmail: boolean;
}

function registerNewUser(options: RegistrationOptions) {
  // access options.username, etc.
}

إعادة الهيكلة بثقة وباستخدام أدوات ذكية

ابدأ بإجراء تدقيق مستهدف يحدد الدوال الطويلة، عدد الوسائط الكبير، التعشيش العميق، والأسماء الغامضة. إصلاح هذه القضايا يعطي أكبر أثر بسرعة.

قائمة تدقيق سريعة:

• طول الدالة أقل من 25 سطرًا
• عدد الوسائط أقل من 3 أو اجمعها في كائن
• تجنّب تعشيش أكثر من 2–3 مستويات
• استبدل الأسماء العامة بأسماء وصفية

الذكاء الاصطناعي كمساعد مبرمج

أدوات مثل GitHub Copilot و Cursor يمكنها تسريع استخراج الأنماط واقتراح قوالب، لكن يجب مراجعة الاقتراحات يدويًا للتأكد من أنها تتوافق مع معايير التسمية والتعامل مع الأخطاء في مشروعك³.

مثال مطالبة لإعادة الهيكلة في Copilot Chat:

“This React component violates SRP. Extract data fetching and state management into a hook named useUserData. Keep the component focused on rendering.”

استخدم مطالبات متكررة لتنقيح الكود المولَّد وضمان اتباع معايير المشروع.

بناء ثقافة فريقية للكود النظيف

المعايير المشتركة، مراجعات الكود المحترمة، والبرمجة المشتركة تنمّي الاتساق ومشاركة المعرفة. آتمتة قواعد التنسيق بواسطة ESLint وPrettier تسمح للمراجعين بالتركيز على التصميم والمنطق بدلًا من التنسيق⁴.

بناء ثقافة جودة يستغرق وقتًا، لكنه ينعكس بتوظيف أسرع، حوادث إنتاجية أقل، وفِرَق أكثر صحّة هندسيًا².

أسئلة شائعة — ملخّص سريع

س: هل سيبطئني الكود النظيف في البداية؟

ج: قد يتطلب الكود النظيف وقتًا أكثر أولياً، لكن استثمارات سريعة مثل أسماء واضحة، تحسينات بسيطة لإعادة الهيكلة، وSRP تُقلّل وقت التصحيح وتمنع إعادة العمل لاحقًا.

س: كيف أوازن بين الكود النظيف والمواعيد النهائية؟

ج: ركّز على الممارسات ذات التأثير العالي والقليل الوقت: تسمية جيدة، دوال صغيرة، وفصل الاهتمامات. تواصل مع أصحاب المصلحة لشرح القيمة طويلة الأمد.

س: متى أتعامل مع التجريد؟

ج: اتبع قاعدة الثلاثة: أنشئ تجريدًا بعد أن يتكرر النمط فعلاً ثلاث مرات.

في Clean Code Guy نساعد الفرق على تحويل الشفرة إلى أصول قابلة للصيانة عبر تدقيقات، إعادة هيكلة بمساعدة أدوات ذكية، وتدريب. احجز استشارة مجانية على https://cleancodeguy.com للبدء.