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

أذكر ذلك اليوم جيدًا، كان يوم ثلاثاء عاديًا في المكتب. كنت أراجع طلب سحب (Pull Request) لأحد المطورين الشباب في الفريق. المهمة كانت بسيطة: إضافة حقل جديد في نموذج تسجيل. الكود كان يعمل، والمنطق سليم، وكل شيء يبدو على ما يرام. لكن عندما بدأت أقرأ الكود، شعرت بوخزة في عيني. زميلي استخدم الفواصل المزدوجة (double quotes) وأنا من جماعة الفواصل المفردة (single quotes). ترك مسافة قبل القوس في تعريف الدالة، ووضع القوس المعقوف `{` في سطر جديد.

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

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

لماذا نختلف على تنسيق الكود أصلاً؟

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

• الذاتية المحضة: لا يوجد سبب موضوعي يجعل if (condition) { أفضل من if (condition)n{. كلاهما صحيح، والاختيار بينهما هو مجرد تفضيل شخصي.
• أهمية الاتساق: على الرغم من ذاتية القواعد، فإن الاتساق في الكود مهم جدًا. الكود غير المتسق صعب القراءة والصيانة، ويشبه غرفة فوضوية يصعب العثور فيها على أي شيء. هذا ما يعرف بـ “نظرية النوافذ المكسورة” في عالم البرمجيات.

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

المرحلة الأولى من الحل: ESLint لفرض القواعد

كانت خطوتنا الأولى هي تبني أداة تحليل للكود (Linter). الخيار الطبيعي في عالم JavaScript كان ESLint. الفكرة كانت بسيطة: بدلاً من أن نكون نحن “شرطة التنسيق”، سنجعل البرنامج يقوم بهذه المهمة.

ما هو ESLint؟

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

• متغيرات تم تعريفها ولم تستخدم.
• الوصول إلى متغير قبل تعريفه.
• استخدام أنماط كتابة كود قديمة أو غير آمنة.

كيف بدأنا مع ESLint؟

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

1. التثبيت: أول خطوة كانت تثبيت الحزم اللازمة.

   npm install eslint eslint-config-airbnb-base eslint-plugin-import --save-dev

2. ملف الإعدادات: ثم قمنا بإنشاء ملف .eslintrc.json في جذر المشروع. هذا الملف يخبر ESLint بالقواعد التي يجب اتباعها.

   {
     "extends": "airbnb-base",
     "rules": {
       "no-console": "warn",
       "quotes": ["error", "single"],
       "no-unused-vars": "warn"
     }
   }

   في هذا الإعداد، نحن نقول: “استخدم كل قواعد Airbnb كأساس، لكن مع بعض التعديلات: حذرنا فقط عند استخدام console.log بدلاً من إظهار خطأ، وافرض استخدام الفواصل المفردة، وحذرنا من المتغيرات غير المستخدمة”.

النتيجة الأولية: تحسن، ولكن…

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

المنقذ الحقيقي: Prettier لإنهاء الجدل تماماً

هنا دخل البطل الحقيقي إلى القصة: Prettier. على عكس ESLint الذي هو أداة تحليل قابلة للتخصيص، فإن Prettier هو ما يسمى بـ “منسق الكود العنيد” (Opinionated Code Formatter).

ما هو Prettier ولماذا هو “عنيد”؟

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

فلسفة Prettier بسيطة: دع الآلة تهتم بالتنسيق، وأنت ركز على كتابة كود عظيم.

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

التكامل السحري: Prettier + ESLint

قد تسأل: “إذا كان Prettier يقوم بالتنسيق، فهل ما زلنا بحاجة إلى ESLint؟”. الجواب هو نعم! فهما يحلان مشكلتين مختلفتين:

• ESLint: يركز على جودة الكود واكتشاف الأخطاء المنطقية المحتملة (Code Quality).
• Prettier: يركز حصريًا على تنسيق الكود (Code Formatting).

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

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

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

2. تحديث ملف الإعدادات .eslintrc.json:

   {
     "extends": [
       "airbnb-base",
       "plugin:prettier/recommended" // هذا السطر يقوم بكل السحر
     ],
     "rules": {
       // يمكننا هنا وضع أي قواعد خاصة بـ ESLint لا تتعارض مع Prettier
       "no-unused-vars": "warn"
     }
   }
   

   السطر "plugin:prettier/recommended" يقوم بأمرين: يضيف Prettier كإضافة لـ ESLint، والأهم من ذلك، أنه يعطل أي قاعدة في ESLint قد تتعارض مع طريقة Prettier في التنسيق. الآن، أصبح ESLint مسؤولاً عن الأخطاء المنطقية، و Prettier مسؤولاً عن المظهر الجمالي للكود.

التطبيق العملي: أتمتة كل شيء!

وجود الأدوات شيء، وجعلها تعمل تلقائيًا دون تفكير هو شيء آخر. الهدف هو الوصول إلى مرحلة “اكتب الكود واضغط حفظ، وكل شيء يتم وحده”.

الخطوة 1: إعداد المحرر (VS Code كمثال)

أول خطوة هي دمج هذه الأدوات في محرر الأكواد الذي يستخدمه الفريق. في VS Code، الأمر بسيط:

1. قم بتثبيت إضافة ESLint وإضافة Prettier – Code formatter.
2. افتح إعدادات VS Code (ملف settings.json) وأضف الأسطر التالية:

   {
     // تفعيل التنسيق التلقائي عند الحفظ
     "editor.formatOnSave": true,
   
     // تحديد Prettier كمنسق افتراضي للملفات المدعومة
     "editor.defaultFormatter": "esbenp.prettier-vscode",
   
     // تفعيل إصلاح أخطاء ESLint تلقائيًا عند الحفظ
     "editor.codeActionsOnSave": {
       "source.fixAll.eslint": true
     }
   }
   

   بهذه الإعدادات، في كل مرة يضغط المطور على Ctrl + S (أو Cmd + S)، سيقوم Prettier بتنسيق الملف بالكامل، ثم سيقوم ESLint بإصلاح أي مشاكل إضافية يمكنه إصلاحها تلقائيًا. سحر!

الخطوة 2: فرض القواعد على مستوى الفريق (Husky و lint-staged)

ماذا لو نسي أحدهم تفعيل “التنسيق عند الحفظ” أو لم يقم بتثبيت الإضافات؟ نحتاج إلى شبكة أمان أخيرة تضمن عدم وصول أي كود غير متسق إلى مستودع الكود (repository).

الحل هو استخدام Git Hooks، وهي سكربتات تعمل تلقائيًا عند أحداث معينة في Git (مثل git commit). الأدوات التي تسهل هذا هي Husky و lint-staged.

• Husky: أداة لتسهيل إدارة Git Hooks.
• lint-staged: أداة لتشغيل الأوامر (مثل ESLint و Prettier) فقط على الملفات التي تم تعديلها وجاهزة للـ commit (staged files)، مما يجعل العملية سريعة جدًا.

بعد تثبيتهما، نضيف الإعدادات التالية إلى ملف package.json:

"husky": {
  "hooks": {
    "pre-commit": "lint-staged"
  }
},
"lint-staged": {
  "*.{js,jsx,ts,tsx}": [
    "eslint --fix",
    "prettier --write"
  ]
}

الآن، عندما يحاول أي مطور في الفريق تنفيذ أمر git commit، سيقوم Husky بتشغيل lint-staged، الذي بدوره سيقوم بتشغيل ESLint و Prettier على الملفات المعدلة فقط. إذا كان هناك أي أخطاء لا يمكن إصلاحها تلقائيًا، سيفشل الـ commit، مما يجبر المطور على إصلاح المشكلة قبل المتابعة. هذا يضمن أن 100% من الكود في المستودع نظيف ومتسق.

نصائح من خبرة أبو عمر

• ابدأ بمشروع صغير: لا تحاول تطبيق هذا النظام على مشروع ضخم وقديم دفعة واحدة. قد ينتج عن ذلك آلاف التغييرات في طلب سحب واحد، مما يجعله كابوسًا للمراجعة. جرب على مشروع جديد، أو قم بتطبيقه تدريجيًا على أجزاء من مشروع قائم.
• الاتفاق هو المفتاح: قبل فرض الأدوات، اجلس مع الفريق. اشرح الفوائد والهدف. صوتوا على بعض الخيارات القليلة التي يوفرها Prettier (مثل عرض السطر printWidth أو استخدام الفاصلة المنقوطة semi). عندما يشعر الفريق بأنه جزء من القرار، يكون التبني أسهل.
• لا تفرط في تخصيص القواعد: قاوم الرغبة في تغيير كل قاعدة في ESLint أو Prettier لتناسب ذوقك الشخصي. جمال هذه الأدوات يكمن في تبني معايير مجتمعية جاهزة. ثق بالإعدادات الافتراضية قدر الإمكان.
• استخدم // eslint-disable-next-line بحكمة: في حالات نادرة جدًا، قد تحتاج إلى تعطيل قاعدة ESLint لسطر معين. افعل ذلك فقط عند الضرورة القصوى واترك تعليقًا واضحًا يشرح السبب.

الخلاصة: ركز على ما يهم حقًا 🚀

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

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