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

السلام عليكم يا جماعة الخير، معكم أخوكم أبو عمر.

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

بدأ سمير يراجع الكود، وأول تعليق كان: “يا خالد، ليش مستخدم الفاصلة المنقوطة (semicolon) في آخر كل سطر؟ احنا متفقين ما نستخدمها!”. رد خالد: “يا زلمة، هيك أنا متعود، والكود شغال! شو المشكلة؟”. ومن هون بلّشت الـ “طوشة”. انتقل النقاش من الفاصلة المنقوطة لعلامات التنصيص المزدوجة والفردية (`”` vs `’`)، وبعدين لكيفية كتابة الـ `if statement`، وهل القوس `{` لازم يكون بنفس السطر ولا بسطر جديد.

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

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

لماذا تتحول مراجعات الكود إلى حلبة مصارعة؟

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

أشهر ساحات القتال الأسلوبية تشمل:

• المسافات أم الـ Tabs (Spaces vs. Tabs): معركة أزلية لا تنتهي.
• الفاصلة المنقوطة (Semicolons): هل نضعها أم لا في لغات مثل JavaScript؟
• علامات التنصيص (Quotes): فردية (`’`) أم مزدوجة (`”`)؟
• طول السطر (Max Line Length): 80 حرف؟ 100؟ 120؟ أم “على البركة”؟
• مكان الأقواس (Brace Style): هل تبدأ في نفس السطر أم في سطر جديد؟

هذه النقاشات تستهلك وقتاً وطاقة ذهنية هائلة كان من الأفضل استثمارها في مراجعة منطق العمل (Business Logic)، أو اكتشاف الأخطاء البرمجية الحقيقية (Bugs)، أو تحسين أداء التطبيق.

الحل السحري: تعرف على “Prettier” 🦸

هنا يأتي دور البطل Prettier. باختصار، Prettier هي أداة لتنسيق الكود، ولكنها ليست كأي أداة أخرى. ما يميزها هي أنها “صاحبة رأي” (Opinionated).

ما هو Prettier بالضبط؟

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

فلسفة Prettier بسيطة: توفير أداة ذات إعدادات قليلة جداً تفرض أسلوباً واحداً متناسقاً، مما ينهي الجدال تماماً ويريح رأس المطورين.

لماذا “صاحب رأي” أفضل من “قابل للتخصيص”؟

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

Prettier يقلل خيارات التخصيص إلى الحد الأدنى عن قصد. الهدف ليس إرضاء ذوقك الشخصي، بل فرض الاتساق (Consistency) على مستوى الفريق بأكمله. عندما يبدو كل الكود في المشروع وكأنه كُتب بواسطة شخص واحد، بغض النظر عن عدد المطورين، تصبح القراءة والصيانة أسهل بأضعاف.

يلا نشتغل شغل عملي: كيف نطبق Prettier في مشاريعنا؟

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

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

أول شيء، نحتاج إلى تثبيت Prettier كـ “اعتمادية تطوير” (dev dependency) في مشروعنا.

npm install --save-dev --save-exact prettier

نصيحة من أبو عمر: استخدام --save-exact يضمن أن كل أعضاء الفريق يستخدمون نفس الإصدار بالضبط من Prettier، مما يمنع أي اختلافات طفيفة في التنسيق بين الأجهزة.

الخطوة الثانية: ملف الإعدادات (اختياري ولكن موصى به)

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

{
  "semi": true,
  "singleQuote": false,
  "tabWidth": 2,
  "trailingComma": "all",
  "arrowParens": "always"
}

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

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

الجمال الحقيقي يظهر عندما تجعل التنسيق تلقائياً. في VS Code، يمكنك تحقيق ذلك بسهولة:

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

{
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "esbenp.prettier-vscode"
}

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

الخطوة الرابعة (الأهم): الأتمتة مع Git Hooks

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

سنستخدم أداتين رائعتين: husky و lint-staged.

1. تثبيت الأدوات:

npm install --save-dev husky lint-staged

2. تفعيل Husky:

npx husky-init
npm install

هذا الأمر سيقوم بإنشاء مجلد .husky مع ملف pre-commit.

3. إعداد lint-staged:

افتح ملف package.json وأضف هذا الجزء:

"lint-staged": {
  "**/*.{js,jsx,ts,tsx,json,css,scss,md}": "prettier --write"
}

4. ربط Husky مع lint-staged:

عدّل ملف .husky/pre-commit ليصبح محتواه كالتالي:

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx lint-staged

ماذا يحدث الآن؟ قبل كل عملية git commit، سيقوم husky بتشغيل lint-staged، والذي بدوره سيقوم بتشغيل prettier --write على الملفات التي قمت بتعديلها فقط. والنتيجة؟ من المستحيل أن يتم عمل commit لكود غير منسق. لقد قضينا على المشكلة من جذورها.

النتائج على أرض الواقع: جنة المطورين

بعد تطبيق هذا النظام، تغيرت حياة فريقنا 180 درجة:

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

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

من خبرتي في تطبيق Prettier في عدة فرق ومشاريع، اسمحوا لي أن أقدم لكم بعض النصائح العملية:

• لا تحارب الأداة: تقبّل “رأي” Prettier. الهدف هو الاتساق، وليس فرض ذوقك الشخصي. كل دقيقة تقضيها في محاولة تغيير سلوك Prettier هي دقيقة ضائعة.
• طبقه على المشروع كاملاً دفعة واحدة: عند إدخال Prettier على مشروع قائم، قم بتشغيله على كل الملفات في المشروع في “commit” واحد منفصل. هذا يمنع تداخل تغييرات التنسيق مع تغييرات الميزات في تاريخ Git.
• استخدمه لكل شيء: Prettier لا يدعم JavaScript فقط، بل يدعم أيضاً HTML, CSS, JSON, Markdown, GraphQL وغيرها الكثير. استخدمه لتوحيد الأسلوب في كل ملفات مشروعك.
• أضف خطوة تحقق في الـ CI/CD: بالإضافة إلى الـ pre-commit hook، أضف خطوة في نظام التكامل المستمر (CI) الخاص بك تقوم بتشغيل npx prettier --check .. هذه الخطوة ستفشل إذا تمكن أي كود غير منسق من الوصول إلى الـ repository، مما يوفر شبكة أمان إضافية.

الخلاصة: ركز على المهم، ودع الباقي للأدوات ✅

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

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