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

“يا زلمة، الفاصلة المنقوطة!”.. قصة كادت أن توقف مشروعاً

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

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

“لماذا تستخدم علامات اقتباس مفردة هنا؟ معيارنا هو المزدوجة.”
“يجب أن يكون القوس المعقوف `{` على سطر جديد.”
“هناك مسافة زائدة قبل القوس في هذه الدالة.”
“نسيت الفاصلة المنقوطة في نهاية هذا السطر.”
… وهكذا دواليك.

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

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

ما هي مشكلة النقاشات الشكلية في مراجعات الكود؟

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

إهدار الوقت والجهد

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

تثبيط عزيمة المطورين (خصوصاً الجدد)

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

التركيز على الشكل بدلاً من الجوهر

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

الحل السحري: أدوات التنسيق والتدقيق التلقائي (Linters & Formatters)

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

ما هو المدقق (Linter)؟

الـ Linter هو أداة تحليل استاتيكي للكود. وظيفته الأساسية هي اكتشاف الأخطاء البرمجية المحتملة، والممارسات السيئة، والمشاكل الأسلوبية في الكود البرمجي أثناء كتابته. فكر فيه كمدقق نحوي وإملائي لكودك.

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

ما هو المنسق (Formatter)؟

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

• مثال: أداة مثل Prettier هي أشهر مثال. يمكنك أن تكتب كوداً “مبعثراً” كيفما تشاء، وبمجرد حفظ الملف، يقوم Prettier بإعادة ترتيبه بالكامل ليصبح متناسقاً وجميلاً حسب القواعد المتفق عليها (طول السطر، نوع علامات الاقتباس، المسافات، إلخ).

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

تطبيق عملي: لننهِ الجدال في 3 خطوات

دعنا نأخذ مثالاً عملياً في مشروع يستخدم JavaScript (Node.js/React). كيف يمكننا إعداد هذه الأدوات؟

الخطوة 1: تثبيت الأدوات

أولاً، نقوم بتثبيت الأدوات اللازمة كـ “dev dependencies” في مشروعنا باستخدام npm أو yarn.

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

الخطوة 2: إعداد ملفات الضبط

نحتاج لإنشاء ملفي إعدادات في جذر المشروع: واحد لـ ESLint وآخر لـ Prettier.

ملف .eslintrc.json:

{
  "extends": [
    "eslint:recommended",
    "plugin:prettier/recommended"
  ],
  "parserOptions": {
    "ecmaVersion": 2020,
    "sourceType": "module"
  },
  "env": {
    "es6": true,
    "node": true,
    "browser": true
  },
  "rules": {
    "no-unused-vars": "warn",
    "no-console": "off"
  }
}

هذا الملف يخبر ESLint أن يعتمد على القواعد الموصى بها، وأن يعمل بتناغم مع Prettier.

ملف .prettierrc:

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

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

الخطوة 3: التشغيل التلقائي (وهي الأهم)

السر ليس فقط في وجود الأدوات، بل في جعلها تعمل تلقائياً قبل كل عملية commit. هذا يضمن عدم وصول أي كود غير منسق إلى مستودع الشيفرة المصدرية (Git repository). نستخدم أدوات مثل husky و lint-staged لهذا الغرض.

1. نثبتها:

npm install husky lint-staged --save-dev

2. نضيف الإعدادات إلى ملف package.json:

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

الآن، في كل مرة يحاول أي مطور (أحمد، الأستاذ ماهر، أو أبو عمر) عمل git commit، ستقوم هذه الأدوات بفحص الملفات المُعدّلة وتصليحها تلقائياً. “خلصنا من هالسيرة”، كما نقول. لا مجال للنقاش.

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

• لا تكن دكتاتوراً في القواعد: قبل فرض ملف الإعدادات، اعقد اجتماعاً قصيراً مع الفريق، واتفقوا سوياً على القواعد. اجعل القرار جماعياً حتى يلتزم به الجميع عن قناعة.
• اجعلها جزءاً من الـ CI/CD Pipeline: بالإضافة إلى التشغيل المحلي، أضف خطوة في مسار التكامل المستمر (CI) الخاص بك (مثل GitHub Actions أو Jenkins) تقوم بتشغيل المدقق. هذه هي شبكة الأمان الأخيرة التي تضمن عدم مرور أي شيء.
• ثقّف الفريق: اشرح للجميع، خصوصاً الجدد، لماذا تستخدمون هذه الأدوات. وضح لهم أنها ليست لتقييدهم، بل لتحريرهم من التفاصيل الصغيرة والتركيز على الإبداع.
• لا تجادل الآلة!: القاعدة الذهبية. بمجرد الاتفاق على القواعد، تصبح الأداة هي الحكم النهائي. إذا قامت الأداة بتغيير تنسيق كودك، فاقبل التغيير وامضِ قدماً. هذا هو الهدف الأساسي من كل هذا.

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

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

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