Prettier و ESLint: كيف أنقذنا مراجعات الكود من جحيم النقاشات الأسلوبية؟

يا جماعة الخير، خلوني أحكيلكم قصة صارت معي قبل كم سنة. كنا في عز الشغل على مشروع جديد، فريق صغير ومتحمس، والكل بيكتب كود ليل نهار. وصلتني “Pull Request” من شب جديد معنا بالفريق، خلينا نسميه سامي. شب شاطر ومجتهد، لكنه لسا جديد على أسلوبنا في الشغل.

فتحت الـ Pull Request وبديت أراجع الكود. المنطق البرمجي كان سليم، والـ feature شغالة مية بالمية. لكن… وهنا بدأت المشكلة. دخل على الخط زميلنا “أبو خليل”، وهو مبرمج قديم وخبرة، لكنه “حمش” شوي بموضوع تنسيق الكود. بدأت التعليقات تنهال على سامي: “ليش مستخدم فاصلة منقوطة هنا؟”، “لازم تستخدم single quotes مش double quotes”، “المسافة قبل القوس غلط”، “ولك عمي، السطر طويل زيادة عن اللزوم!”.

خلال ساعة، تحولت مراجعة الكود من نقاش تقني مفيد إلى ساحة معركة على الأسلوب والشكل. سامي صار محبط، وأبو خليل معصّب، وأنا بتابع المشهد وبحكي لحالي: “شو هالحكي الفاضي؟ إحنا بنضيّع وقت وطاقة على تفاهات!”. كانت هذيك اللحظة هي نقطة التحول. أدركت إنه لازم نلاقي حل جذري ينهي هذا الجدال العقيم مرة وللأبد، ويرجع تركيزنا على اللي يهم فعلًا: بناء منتج عظيم.

وهنا بدأت رحلتنا مع Prettier و ESLint.

ما هو “جحيم النقاشات الأسلوبية”؟

اللي صار معنا في قصة سامي وأبو خليل هو مثال حي على ما أسميه “جحيم النقاشات الأسلوبية”. هو الوضع اللي بتتحول فيه عملية مراجعة الكود (Code Review) من عملية هدفها تحسين جودة المنطق، وإيجاد الأخطاء الحقيقية، ومشاركة المعرفة، إلى مجرد جدال حول تفضيلات شخصية في كتابة الكود.

هذه النقاشات سامة جدًا للفريق وللمشروع للأسباب التالية:

• مضيعة للوقت والجهد: تخيل كم ساعة عمل تضيع كل أسبوع في نقاشات حول الفواصل والمسافات بدلًا من حل مشاكل حقيقية للعملاء.
• تحطيم الروح المعنوية: المبرمج الجديد (مثل سامي) يشعر بالإحباط والهجوم الشخصي، بينما المبرمج الخبير (مثل أبو خليل) يشعر أن معايير الجودة لا تُحترم. الكل خسران.
• تشتيت التركيز: عندما يركز المراجعون على الشكل، فإنهم غالبًا ما يغفلون عن الأخطاء المنطقية الحقيقية والثغرات الأمنية ومشاكل الأداء في الكود.
• عدم الاتساق في الكود: بدون وجود قواعد واضحة، يصبح الكود خليطًا من أساليب مختلفة، مما يجعله صعب القراءة والصيانة مستقبلًا.

الحل السحري: الأتمتة هي المنقذ

الحل ليس في عمل اجتماعات طويلة لوضع “دستور” لكتابة الكود، ولا في تعيين “شرطي” مسؤول عن التنسيق. الحل أبسط وأكثر فعالية: دعوا الآلات تقوم بالعمل.

هنا يأتي دور أدوات مثل Linters و Formatters. دعونا نفرق بينهما:

• الـ Linter (المدقق): مثل ESLint، هو أداة تحلل الكود البرمجي للعثور على الأخطاء المحتملة، والأنماط السيئة، والمشاكل المنطقية. يمكنه أيضًا فرض قواعد تنسيقية، لكن قوته الحقيقية تكمن في صيد الأخطاء قبل أن تحدث.
• الـ Formatter (المنسّق): مثل Prettier، هو أداة “عنيدة” لا تهتم بمنطق الكود أبدًا. كل همها هو أخذ الكود الذي كتبته وإعادة طباعته بشكل متسق وجميل بناءً على مجموعة قواعد ثابتة.

عندما ندمج هاتين الأداتين معًا، نحصل على نظام شبه مثالي يضمن جودة الكود واتساقه بشكل آلي، ويحررنا كمطورين للتركيز على الإبداع وحل المشكلات.

بطلنا الأول: ESLint – شرطي الجودة

ESLint هو خط دفاعنا الأول. إنه مثل الشرطي الذكي الذي يراقب الكود الخاص بك باستمرار ويحذرك من المشاكل المحتملة.

ما هو ESLint؟

ببساطة، ESLint هي أداة مخصصة بشكل أساسي لعالم JavaScript و TypeScript. تقوم بتحليل الكود بشكل ثابت (أي بدون تشغيله) وتحديد الأنماط التي لا تتوافق مع القواعد المحددة. هذه القواعد يمكن أن تكون أي شيء من “منع استخدام المتغيرات غير المعرّفة” إلى “فرض استخدام الأقواس في جمل `if` متعددة الأسطر”.

كيف نبدأ مع ESLint؟

إعداد ESLint أصبح سهلاً جدًا. لنفترض أنك في مشروع Node.js:

1. تثبيت الحزمة:

   npm install eslint --save-dev

2. إنشاء ملف الإعدادات:

   npx eslint --init

   سيقوم هذا الأمر بطرح بعض الأسئلة عليك لمساعدتك في إنشاء ملف الإعدادات الأولي .eslintrc.json. يمكنك اختيار اتباع دليل أسلوب شائع مثل Airbnb أو Google.

نصيحة أبو عمر: أنصح بشدة بالبدء بأحد أدلة الأسلوب المشهورة مثل eslint-config-airbnb. هذه الأدلة تمثل خلاصة خبرة آلاف المطورين في أفضل الممارسات، وتوفر عليك عناء تحديد مئات القواعد بنفسك.

مثال عملي: صيد الأخطاء قبل وقوعها

تخيل أنك كتبت الكود التالي:

const name = "Abu Omar";

function getUser(id) {
    const user = db.findUser(id);
    // ... الكثير من المنطق هنا
    return { name: "Sami" };
}

بمجرد حفظ الملف، سيقوم ESLint (إذا كان مدمجًا في محرر الأكواد) بتحديد مشكلتين فورًا:

• 'name' is assigned a value but never used. (المتغير `name` تم تعريفه ولكن لم يتم استخدامه).
• 'user' is assigned a value but never used. (المتغير `user` تم تعريفه ولكن لم يتم استخدامه).

هذه التحذيرات البسيطة تمنع تراكم “الكود الميت” في مشروعك وتجعلك تفكر مرتين في المتغيرات التي تقوم بتعريفها. هذا مجرد مثال بسيط، وقدرات ESLint تتجاوز ذلك بكثير.

بطلنا الثاني: Prettier – فنان التنسيق

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

ما هو Prettier؟

Prettier هو “منسق كود عنيد” (Opinionated Code Formatter). كلمة “عنيد” هنا هي سر قوته. هذا يعني أنه لا يحتوي على الكثير من خيارات التخصيص. لماذا؟ لأن الهدف هو إنهاء النقاشات. الفريق يوافق على استخدام Prettier، و Prettier يفرض أسلوبه على الجميع.

لا يهم إذا كنت تحب الفاصلة المنقوطة أم لا، أو إذا كنت تفضل علامات الاقتباس المفردة أو المزدوجة. بمجرد تشغيل Prettier، سيتم تنسيق كل الكود بنفس الطريقة تمامًا. انتهى النقاش.

كيف ندمج Prettier مع ESLint؟

هنا تكمن الحيلة. ESLint يمكنه فرض قواعد تنسيق، و Prettier يقوم بالتنسيق. هذا قد يؤدي إلى تعارض بينهما. الحل هو جعلهما يعملان معًا كفريق واحد.

1. ثبّت الحزم اللازمة: نحتاج إلى Prettier وحزمة خاصة لإلغاء تفعيل قواعد ESLint التي تتعارض معه.

   npm install --save-dev prettier eslint-config-prettier

2. حدّث ملف إعدادات ESLint: افتح ملف .eslintrc.json وأضف "prettier" إلى نهاية مصفوفة extends. يجب أن تكون آخر عنصر في المصفوفة لضمان أنها تتجاوز أي قواعد أخرى.

   {
       "extends": [
           "eslint:recommended",
           "airbnb-base",
           "prettier" 
       ]
   }

بهذه الطريقة، نحن نقول لـ ESLint: “يا صديقي، اهتم أنت بجودة الكود والأخطاء المنطقية، واترك مهمة التنسيق والشكل لـ Prettier”.

مثال قبل وبعد Prettier

تخيل هذا الكود المكتوب على عجل:

// قبل Prettier
function     sayHello( name){
console.log('Hello, ' + name + "!");}

بمجرد حفظ الملف (مع تفعيل Format on Save)، سيتحول تلقائيًا إلى:

// بعد Prettier
function sayHello(name) {
  console.log("Hello, " + name + "!");
}

لاحظ كيف تم إصلاح المسافات، وإضافة فاصلة منقوطة (إذا كانت هذه هي القاعدة)، وتوحيد علامات الاقتباس. كل هذا يحدث في أقل من ثانية وبدون أي تدخل يدوي.

الأتمتة الكاملة: إجبار الفريق على الالتزام

إعداد الأدوات على جهازك الشخصي خطوة ممتازة، ولكن القوة الحقيقية تظهر عندما تفرض هذه القواعد على مستوى الفريق بأكمله. لا مجال للتهاون أو “نسيت أن أنسق الكود”.

الخطوة الأولى: تكامل المحرر (IDE Integration)

يجب على كل عضو في الفريق تثبيت الإضافات (Extensions) الخاصة بـ ESLint و Prettier في محرر الأكواد الذي يستخدمه (مثل VS Code). والأهم من ذلك، تفعيل خيار “Format on Save”. هذا يضمن أن أي ملف يتم حفظه يتم تنسيقه تلقائيًا.

الخطوة الثانية: خطافات Git (Git Hooks)

ماذا لو نسي أحدهم تفعيل “Format on Save”؟ هنا يأتي دور خطافات Git. باستخدام أدوات مثل Husky و lint-staged، يمكننا تشغيل أوامر تلقائيًا قبل كل عملية `commit`.

الفكرة بسيطة: قبل أن يسمح Git بتنفيذ الـ commit، تقوم `lint-staged` بتشغيل Prettier و ESLint على الملفات التي تم تغييرها فقط. هذا يضمن عدم دخول أي كود غير منسق أو يحتوي على أخطاء إلى مستودع الكود (repository).

مثال للإعداد في ملف package.json:

"husky": {
  "hooks": {
    "pre-commit": "lint-staged"
  }
},
"lint-staged": {
  "*.{js,css,md,ts,tsx}": "prettier --write"
}

الخطوة الثالثة: التكامل المستمر (CI Pipeline)

هذه هي شبكة الأمان الأخيرة. في مسار التكامل المستمر (CI Pipeline) الخاص بك (مثل GitHub Actions أو GitLab CI)، يجب إضافة خطوة تقوم بتشغيل أمر للتحقق من التنسيق والجودة (مثل `npm run lint`).

إذا حاول شخص ما (بطريقة ما) تجاوز كل الدفاعات السابقة، فإن الـ CI Pipeline سيفشل، وسيتم حظر الـ Pull Request من الدمج. هذا يضمن بنسبة 100% أن الكود الموجود في الفرع الرئيسي (main branch) دائمًا نظيف ومتسق.

الخلاصة: من جدال إلى إبداع 🚀

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

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

نصيحة أبو عمر النهائية:
لا تخافوا من فرض القواعد الآلية. في البداية قد تجدون بعض المقاومة، لكن سرعان ما سيدرك الفريق أنكم تزيحون عن كاهلهم عبئًا لم يكونوا يدركون حجمه. استثمروا وقتكم في حل المشاكل الحقيقية، ودعوا الآلات تهتم بالفواصل والنقاط. وقتكم أثمن من أن يضيع في جدالات تافهة. ✌️