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

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

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

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

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

جحيم الجدال حول التنسيق: المشكلة أعمق مما تظن

قد يظن البعض أن الجدال حول تنسيق الكود هو مجرد “نقاشات مبرمجين” لا قيمة لها، لكن الحقيقة أن أثرها سلبي ومدمر على عدة مستويات:

• الحمل المعرفي الزائد (Cognitive Load): عندما يضطر المبرمج للتفكير في كل مرة يكتب فيها سطراً: “هل أضع فاصلة منقوطة؟ هل أستخدم علامات تنصيص مفردة أم مزدوجة؟”، فإنه يستهلك طاقة ذهنية كان من الأفضل أن يوجهها لحل المشكلة البرمجية الأساسية.
• قاعدة كود غير متسقة (Inconsistent Codebase): عندما يكتب كل مبرمج بأسلوبه الخاص، يصبح المشروع عبارة عن خليط من الأنماط المختلفة. هذا يجعل قراءة الكود وفهمه أصعب بكثير، خاصة للمنضمين الجدد للفريق.
• مضيعة للوقت والجهد: ساعات طويلة تضيع في مراجعات الكود لمناقشة التنسيق، وساعات أخرى يقضيها المبرمج في تعديل الكود يدويًا ليتوافق مع “رأي” المراجع. هذا وقت كان يمكن استثماره في بناء ميزات جديدة أو إصلاح أخطاء حقيقية.
• احتكاك وتوتر في الفريق: مع الوقت، تتحول هذه النقاشات من موضوعية إلى شخصية. يشعر المبرمج أن عمله يتعرض للنقد غير المبرر، بينما يشعر المراجع بالإحباط لعدم الالتزام بالمعايير. “صار الموضوع شخصي”، وهذا يفسد بيئة العمل.

المنقذ Prettier: أداة تفرض رأيها… ولصالح الجميع

وسط هذا الجحيم، ظهرت أداة Prettier. الفكرة وراء Prettier عبقرية في بساطتها: هي أداة تنسيق كود “صاحبة رأي” (Opinionated Code Formatter). لكن ماذا يعني هذا؟

ماذا يعني “Opinionated” (صاحب رأي)؟

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

“الهدف من Prettier هو إنهاء كل الجدالات حول التنسيق. ببساطة، لم يعد هناك مجال للنقاش. هناك فقط ‘طريقة Prettier’.”

هذا النهج يزيل كل الآراء الشخصية من المعادلة. لا رأي أبو عمر، ولا رأي خالد، ولا رأي سامي يهم. ما يهم هو رأي Prettier، والجميع يلتزم به. هذا هو سر قوته.

كيف يعمل Prettier؟ (شرح مبسط)

لفهم سبب فعالية Prettier، من المفيد أن نعرف كيف يعمل من الداخل:

1. التحليل (Parsing): يأخذ الكود الخاص بك ويحوله إلى هيكل بيانات يسمى “شجرة النحو المجردة” (Abstract Syntax Tree – AST). هذه الشجرة تمثل بنية الكود ومنطقه، وليس شكله.
2. إعادة الطباعة (Re-printing): يقوم Prettier بأخذ هذه الشجرة (AST) ويعيد بناء الكود كنص من جديد، ولكن هذه المرة، يطبق قواعد التنسيق الصارمة الخاصة به أثناء عملية البناء.

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

يلا نطبّق: إعداد Prettier في مشروعك (خطوة بخطوة)

الكلام النظري جميل، لكن خلينا نشوف كيف نطبق هذا الحل بشكل عملي. سأريكم الخطوات التي اتبعناها في فريقنا، والتي أنصح بها أي فريق.

1. التثبيت (Installation)

أول خطوة هي إضافة Prettier إلى مشروعك كـ “اعتمادية تطوير” (dev dependency).

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

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

2. ملف الإعدادات (.prettierrc)

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

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

• semi: هل تريد فواصل منقوطة في نهاية الأسطر؟
• singleQuote: هل تفضل علامات التنصيص المفردة على المزدوجة؟
• trailingComma: هل تريد فاصلة في نهاية العنصر الأخير في المصفوفات والكائنات؟ (مفيدة جدًا لـ Git).
• tabWidth: عدد المسافات التي تمثل الـ Tab.
• printWidth: أقصى عرض للسطر قبل أن يقوم Prettier بتقسيمه.

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

3. التكامل مع محرر الكود (VS Code كمثال)

هنا يحدث السحر الحقيقي! نريد أن يتم التنسيق تلقائيًا في كل مرة نحفظ فيها الملف.

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

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

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

4. الأتمتة مع Git Hooks (الحل الاحترافي)

لضمان عدم وصول أي كود غير منسق إلى قاعدة الكود الرئيسية، نستخدم ما يسمى بـ Git Hooks. سنستخدم أداتين رائعتين: husky و lint-staged.

1. التثبيت:

   npm install --save-dev husky lint-staged

2. إعداد Husky:

   npx husky-init && npm install

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

3. ربط lint-staged مع Husky:
   نقوم بتعديل ملف .husky/pre-commit ليحتوي على الأمر التالي:

   npx lint-staged

4. إعداد lint-staged:
   أخيرًا، نضيف الإعدادات التالية إلى ملف package.json الخاص بك:

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

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

ما بعد Prettier: العودة إلى الهدوء والإنتاجية

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

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

الخلاصة: استثمر في سلام فريقك النفسي 🧘‍♂️

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

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

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