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

يا أهلاً وسهلاً فيكم! اسمي أبو عمر، مطور برمجيات قضيت سنوات طويلة في بناء الأنظمة والتطبيقات، وشفت بعيني كيف ممكن تفاصيل صغيرة تعمل مشاكل كبيرة في فرق العمل.

بتذكر مرة، كنا قاعدين في مراجعة كود (Code Review) لمشروع مهم. الكود كان شغال مية المية، والمنطق البرمجي سليم. لكن، يا ويلي شو صار! واحد من الزملاء فتح نقاش طويل عريض ليش زميلنا “أحمد” استخدم علامات تنصيص فردية (single quotes) بدل المزدوجة (double quotes). وانفتح باب ما يتسكر… واحد يقول “الأفضل للأداء”، والثاني يقول “هيك قرأتها في مقال لفلان”، والثالث يقول “بس الأجمل للعين”. نص ساعة راحت من وقتنا، والكل طلع معصّب، وأحمد المسكين حس إنه ارتكب جريمة، وكل هالحكي على شو؟ على شخطة فاصلة ولا علامة تنصيص!

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

لماذا تعتبر النقاشات الأسلوبية جحيماً؟

قبل ما ندخل في الحلول، خلونا نتفق على المشكلة. النقاشات حول تنسيق الكود (Code Formatting) هي مضيعة هائلة للموارد لعدة أسباب:

• تستهلك الوقت: كل دقيقة تقضيها في نقاش حول الفاصلة المنقوطة هي دقيقة كان من الممكن أن تقضيها في حل مشكلة حقيقية للعميل.
• تستنزف الطاقة العقلية: اتخاذ قرارات أسلوبية تافهة بشكل مستمر يسبب ما يسمى بـ “إرهاق القرار” (Decision Fatigue).
• تخلق احتكاكاً في الفريق: هذه النقاشات شخصية بطبيعتها (“أنا أحب هذا الأسلوب”) ويمكن أن تؤدي إلى توتر بين أعضاء الفريق.
• لا تضيف قيمة للمنتج: المستخدم النهائي لا يهتم إذا كنت تستخدم مسافتين أو أربع مسافات للمسافة البادئة. هو يهتم فقط بما إذا كان التطبيق يعمل ويحل مشكلته.

باختصار، هي نقاشات لا طائل من ورائها. الحل؟ أتمتة هذه القرارات بشكل كامل. وهنا يأتي دور أبطالنا: ESLint و Prettier.

التعرف على الأبطال: ESLint و Prettier

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

ESLint: شرطي جودة الكود

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

ESLint يساعدك في اكتشاف أشياء مثل:

• المتغيرات التي تم تعريفها ولم يتم استخدامها (no-unused-vars).
• استخدام console.log في الكود النهائي (no-console).
• الكود الذي لا يمكن الوصول إليه (Unreachable code).
• اتباع أفضل الممارسات في اللغة.

على سبيل المثال، لو كتبت الكود التالي:

const name = "أبو عمر";
const age = 35; // تم تعريفه ولكن لم يستخدم

function sayHello() {
    return "مرحباً يا " + name;
}

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

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

Prettier: فنان التنسيق التلقائي

أما Prettier، فهو فنان متخصص في شيء واحد فقط ويقوم به بإتقان: تنسيق الكود. Prettier هو ما نسميه “أداة تنسيق مُصمّمة برأي محدد” (Opinionated Code Formatter).

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

لنأخذ هذا الكود المكتوب بطريقة فوضوية كمثال:

// قبل Prettier
const user  = {
name:'أبو عمر', age:35,
skills: ['JavaScript', 'Python', 'AI', 'Cloud']
};

function printUser(  user) {console.log(user.name + ' لديه ' + user.skills.length + ' مهارات.');}

بمجرد تمرير هذا الكود على Prettier، سيتحول تلقائياً إلى هذا الشكل الجميل والمنظم:

// بعد Prettier
const user = {
  name: "أبو عمر",
  age: 35,
  skills: ["JavaScript", "Python", "AI", "Cloud"],
};

function printUser(user) {
  console.log(user.name + " لديه " + user.skills.length + " مهارات.");
}

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

نصيحة أبو عمر: أجمل ما في Prettier هو أنه ينهي النقاش. القاعدة في فريقنا أصبحت: “لا تجادل Prettier”. مهما كان رأيك الشخصي، اترك الأداة تقوم بعملها. الاتساق أهم من التفضيل الشخصي.

الزواج الكاثوليكي: دمج ESLint و Prettier لنتائج مذهلة

الآن، قد تسأل: “إذا كان ESLint يستطيع التنسيق، و Prettier يقوم بالتنسيق، ألا يتعارضان؟” سؤال في محله تماماً! وهذا هو سر الخلطة.

الحل هو جعل كل أداة تركز على ما تتقنه:

1. ESLint: يتولى مسؤولية جودة الكود والبحث عن الأخطاء.
2. Prettier: يتولى مسؤولية تنسيق الكود بشكل كامل.

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

خطوات الإعداد العملي

لتحقيق هذا التكامل، ستحتاج إلى تثبيت بعض الحزم وتهيئة ملفات الإعدادات. إليك دليل سريع:

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

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

• eslint: الأداة الأساسية.
• prettier: أداة التنسيق.
• eslint-config-prettier: هذه الحزمة هي الجسر السحري! تقوم بتعطيل قواعد ESLint التي تتعارض مع Prettier.
• eslint-plugin-prettier: تجعل Prettier يعمل كقاعدة من قواعد ESLint، مما يسمح بالإبلاغ عن مشاكل التنسيق كأخطاء ESLint.

2. تهيئة ملف ESLint (.eslintrc.json):

هذا هو أهم جزء. يجب أن يكون prettier هو آخر عنصر في مصفوفة extends. هذا يضمن أنه سيقوم بتجاوز أي قواعد تنسيقية من الإعدادات الأخرى (مثل airbnb أو standard).

{
  "extends": [
    "eslint:recommended",
    "plugin:react/recommended", // مثال إذا كنت تستخدم React
    "prettier" // مهم جداً: يجب أن يكون الأخير!
  ],
  "plugins": ["prettier"],
  "rules": {
    "prettier/prettier": "error",
    // هنا يمكنك إضافة قواعد ESLint التي لا تتعلق بالتنسيق
    "no-unused-vars": "warn",
    "no-console": "warn"
  }
}

3. تهيئة ملف Prettier (.prettierrc.json):

هذا الملف اختياري، لكنه مفيد لتحديد بعض التفضيلات القليلة التي يسمح بها Prettier.

{
  "semi": true,
  "singleQuote": false,
  "tabWidth": 2,
  "trailingComma": "es5"
}

بمجرد الاتفاق على هذا الملف في بداية المشروع، ينتهي الجدل إلى الأبد.

نصيحة أبو عمر الذهبية: الأتمتة الكاملة مع Git Hooks

أفضل شيء فعلناه هو أتمتة هذه العملية بالكامل. لا نعتمد على المطور ليتذكر تشغيل الأوامر. بدلاً من ذلك، نستخدم أدوات مثل Husky و lint-staged لتشغيل المدقق والمنسق تلقائياً قبل كل عملية git commit.

بهذه الطريقة، من المستحيل أن يصل أي كود غير منسق أو يحتوي على أخطاء linting إلى المستودع (Repository). كل الكود نظيف ومتسق بشكل تلقائي. هذا هو ما يسمى “راحة البال للمطورين”.

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

التحول من النقاشات اليدوية إلى التنسيق الآلي كان أحد أفضل القرارات التي اتخذناها كفريق. الفوائد كانت واضحة:

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

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