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

يا جماعة الخير، السلام عليكم ورحمة الله.

اسمحوا لي اليوم أن أرجع بالذاكرة لسنوات قليلة مضت. كنا في منتصف مشروع كبير، فريق متحمس، والكل “شَد حاله” لنسلّم في الموعد. وصلتني مراجعة كود (Code Review) من أحد المطورين الشباب الموهوبين في الفريق. فتحت الطلب (Pull Request) وبدأت أقرأ الكود. منطقياً، الكود كان سليماً ويؤدي الغرض. لكن… آه من هذه الـ “لكن”.

الكود كان، من ناحية أسلوبية، فوضى عارمة. هنا يستخدم فواصل منقوطة (semicolons) وهناك ينساها. تارة يستخدم علامات تنصيص مفردة (”) وتارة أخرى مزدوجة (“”). الأقواس المعقوفة (curly braces) تبدأ أحياناً على نفس السطر، وأحياناً على سطر جديد. قضيت نصف ساعة كاملة أكتب تعليقات من نوع: “الرجاء إضافة فاصلة منقوطة هنا”، “الرجاء توحيد استخدام علامات التنصيص”، “حسب دليل الأسلوب المتفق عليه، القوس يجب أن يكون على سطر جديد”.

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

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

جحيم النقاشات الأسلوبية: لما تتحول مراجعة الكود إلى معركة شخصية

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

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

نصيحة أبو عمر: وقت المطور هو أثمن مورد في أي شركة تقنية. أي دقيقة تقضيها في نقاش يمكن أتمتته هي دقيقة مهدرة من عمر المشروع.

المنقذ وصل: встречайте أدوات التنسيق التلقائي (Auto-Formatters)

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

ما هي هذه الأدوات السحرية؟

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

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

Prettier: диктаторنا العادل في عالم التنسيق

بما أن معظم عملي يتركز في بيئة JavaScript/TypeScript، فإن Prettier هو صديقي الصدوق. دعونا نتعرف عليه عن قرب وكيف يمكن أن يغير حياتكم كفريق.

لماذا Prettier بالذات؟

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

يلا نشتغل: إعداد Prettier في مشروعك

الأمر أسهل مما تتخيل. لنأخذ مشروع JavaScript كمثال:

  1. التثبيت: قم بتثبيت Prettier كأداة تطوير في مشروعك.

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

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

  2. إنشاء ملف الإعدادات (اختياري لكن موصى به): أنشئ ملفاً جديداً في جذر مشروعك باسم .prettierrc.json. هذا الملف يسمح لك بتخصيص بعض القواعد القليلة التي يتيحها Prettier.

    {
      "semi": true,
      "singleQuote": true,
      "trailingComma": "all",
      "printWidth": 100,
      "tabWidth": 2
    }
    • "semi": true: أضف فواصل منقوطة في نهاية الأسطر.
    • "singleQuote": true: استخدم علامات التنصيص المفردة بدلاً من المزدوجة.
    • "trailingComma": "all": أضف فاصلة في نهاية العنصر الأخير في المصفوفات والكائنات. (هذه مفيدة جداً في مراجعات الكود!).
    • "printWidth": 100: حاول ألا يتجاوز السطر 100 حرف.

    الآن، الفريق كله يتبع نفس هذه القواعد. انتهى الجدال!

قبل وبعد: شاهد السحر بنفسك

لنفترض أنك كتبت هذا الكود الفوضوي بسرعة:

// قبل Prettier
const myObject = {prop1: 'value1', prop2: "value2",
prop3: `value3` };

function myFunction( arg1,   arg2,arg3) {
    if(arg1 === true) {
        console.log('it is true')
    }
}

بمجرد تشغيل أمر Prettier (أو الحفظ في المحرر)، سيتحول الكود فوراً إلى هذا الشكل النظيف والموحد:

// بعد Prettier
const myObject = {
  prop1: 'value1',
  prop2: 'value2',
  prop3: 'value3',
};

function myFunction(arg1, arg2, arg3) {
  if (arg1 === true) {
    console.log('it is true');
  }
}

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

التنسيق التلقائي ليس رفاهية، بل جزء من سير العمل

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

نصيحة أبو عمر: أتمتة كل شيء!

لا تعتمد على ذاكرة المطورين لتشغيل أمر التنسيق. البشر ينسون، ولكن الأدوات لا تفعل. إليك طريقتان لدمج Prettier في سير عملكم اليومي:

1. التنسيق عند الحفظ (Format on Save)

هذه هي الخطوة الأولى والأهم لكل مطور على حدة. كل محررات الأكواد الحديثة مثل VS Code تدعم إضافات لـ Prettier. قم بتثبيت الإضافة، ثم اذهب إلى إعدادات المحرر وفعّل خيار “Format on Save”.

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

2. خطافات Git (Git Hooks) لمنع الكوارث

ماذا لو نسي أحدهم تفعيل “Format on Save” وحاول رفع كود غير منسق إلى المستودع (Repository)؟ هنا يأتي دور الحماية النهائية. باستخدام أدوات مثل Husky و lint-staged، يمكننا إجبار الكود على التنسيق قبل كل عملية git commit.

الفكرة بسيطة: قبل أن يقبل Git الكود الذي تريد إضافته، سيقوم Husky بتشغيل lint-staged، والذي بدوره سيقوم بتشغيل Prettier على الملفات التي قمت بتعديلها فقط. إذا تم تعديل أي ملف، سيتم إضافته تلقائياً إلى الـ commit. النتيجة؟ يستحيل أن يصل أي كود غير منسق إلى قاعدة الكود الرئيسية.

لإعداد هذا، ستحتاج لتثبيت الأدوات:

npm install --save-dev husky lint-staged

ثم أضف الإعدادات التالية إلى ملف package.json الخاص بك:

"husky": {
  "hooks": {
    "pre-commit": "lint-staged"
  }
},
"lint-staged": {
  "*.{js,css,md,json,ts,tsx}": "prettier --write"
}

وهكذا، نكون قد بنينا حصناً منيعاً حول جودة تنسيق الكود. لقد أزلنا “الإنسان” من معادلة التنسيق، وسلمنا المهمة للآلة التي لا تخطئ.

ما وراء الفواصل والنقاط: الفوائد الحقيقية لتوحيد الأسلوب

قد يبدو الأمر بسيطاً، لكن تأثيره على الفريق والمشروع عميق جداً:

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

الخلاصة: دعوا الآلة تهتم بالتفاهات 👨‍💻

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

نصيحتي الأخيرة لكم، لكل فريق برمجي، صغيراً كان أم كبيراً: اجتمعوا، اتفقوا على أداة تنسيق (مثل Prettier)، قوموا بأتمتة العملية عبر خطافات Git، ولا تتناقشوا في أسلوب التنسيق مرة أخرى أبداً.

بلا وجعة راس، خلّوا الروبوت هو اللي يقرر ويشتغل الشغل الممل، وركزوا انتوا في الشغل الصح وفي بناء برمجيات نفتخر بها جميعاً. دمتم مبدعين.

أبو عمر

سجل دخولك لعمل نقاش تفاعلي

كافة المحادثات خاصة ولا يتم عرضها على الموقع نهائياً

آراء من النقاشات

لا توجد آراء منشورة بعد. كن أول من يشارك رأيه!

آخر المدونات

الحوسبة السحابية

كانت خوادمنا خاملة 90% من الوقت: كيف أنقذتنا ‘الحوسبة بدون خوادم’ (Serverless) من جحيم التكاليف المهدرة؟

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

14 مايو، 2026 قراءة المزيد
التوظيف وبناء الهوية التقنية

كانت إجاباتي في المقابلات عشوائية: كيف أنقذتني منهجية STAR من جحيم أسئلة “حدثنا عن موقف…”؟

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

14 مايو، 2026 قراءة المزيد
التوسع والأداء العالي والأحمال

كيف أنقذ ‘موازن الحمل’ خادمنا الوحيد من الانهيار؟ قصة من قلب المعركة

هل يواجه تطبيقك بطئًا وتوقفًا مفاجئًا مع زيادة عدد المستخدمين؟ في هذه المقالة، أشارككم قصتي مع انهيار خادمنا الوحيد وكيف كان 'موازن الحمل' (Load Balancer)...

14 مايو، 2026 قراءة المزيد
التكنلوجيا المالية Fintech

من كشط الشاشة إلى الخدمات المصرفية المفتوحة: كيف أنقذت واجهات الـ API تطبيقاتنا المالية؟

أشارككم قصة من قلب المعركة التقنية، كيف انتقلنا في عالم التكنولوجيا المالية من جحيم "كشط الشاشة" الهش والمليء بالمخاطر، إلى نعيم واجهات الخدمات المصرفية المفتوحة...

14 مايو، 2026 قراءة المزيد
البنية التحتية وإدارة السيرفرات

وداعاً لـ `kubectl apply -f`: كيف حولنا إدارة Kubernetes إلى عملية آلية وموثوقة مع GitOps؟

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

13 مايو، 2026 قراءة المزيد
ادارة الفرق والتنمية البشرية

كانت الأفكار تموت في صمت: كيف أنقذتنا ‘السلامة النفسية’ من جحيم الخوف من الفشل؟

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

13 مايو، 2026 قراءة المزيد
البودكاست