مراجعات الكود: كيف حولنا ساحة المعركة إلى ورشة عمل إبداعية بفضل “السلامة النفسية”؟

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

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

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

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

هنا أدركت أن المشكلة ليست في كود سعيد، ولا في خبرة أبو خليل التقنية. المشكلة كانت أعمق بكثير… كانت مشكلة “ثقافة”. كانت غياب ما يُعرف اليوم بـ “السلامة النفسية” (Psychological Safety).

ما هي السلامة النفسية في فرق البرمجة؟ وليش هي مهمة “لهالدرجة”؟

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

بدون سلامة نفسية، الفريق بصير عبارة عن مجموعة جزر منعزلة. الكل خايف يغلط، والكل خايف يظهر بمظهر الضعيف. والنتيجة؟

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

علامات الخطر: كيف تعرف أن فريقك يفتقر للسلامة النفسية؟

قبل ما نحكي عن الحلول، لازم نعرف نشخّص المشكلة. إذا شفت هاي الأعراض في فريقك، فهذا ضوء أحمر كبير:

1. اللغة الاتهامية: استخدام كلمات مثل “أنت” بدل “نحن”. (مثال: “أنت نسيت تعالج الحالة الفلانية” بدل “ما رأيك لو أضفنا معالجة للحالة الفلانية هنا؟”).
2. الدفاعية المفرطة: أي تعليق على الكود يقابَل بسلسلة من التبريرات الطويلة بدلاً من النقاش المفتوح.
3. صمت المبتدئين: المطورون الجدد لا يسألون ولا يشاركون، خوفاً من الظهور بمظهر “الجاهل”.
4. “Blame Game” أو لعبة اللوم: عند حدوث خطأ في الإنتاج، أول سؤال يكون “مين كتب هاد الكود؟” بدلاً من “كيف نصلح المشكلة ونتأكد إنها ما تتكرر؟”.
5. تأخير طلبات الدمج (PRs): المطورون يؤخرون رفع الكود للمراجعة لأطول فترة ممكنة، في محاولة لجعله “مثالياً” وتجنب أي نقد.

خارطة الطريق: خطوات عملية لبناء ثقافة السلامة النفسية في مراجعات الكود

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

1. وضع “المبدأ الأساسي” (The Prime Directive)

استعرنا هذا المبدأ من اجتماعات “الريترو” (Retrospectives) وطبقناه على مراجعات الكود. علّقناه على قناتنا في “سلاك” وصرنا نذكّر بعض فيه دايماً. المبدأ يقول:

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

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

2. تغيير لغة الحوار: من “أنت” إلى “نحن”، ومن الأمر إلى السؤال

هاي كانت أهم خطوة. اتفقنا على تجنب الصيغ الاتهامية والتركيز على الكود نفسه، وليس على كاتبه. شوفوا الفرق بين الطريقتين لمراجعة نفس الجزء من الكود:

مثال كود (JavaScript):

function getUserProfile(userId) {
  const user = database.findUser(userId);
  // This will crash if user is not found
  return user.profile; 
}

طريقة المراجعة السيئة (اتهامية وشخصية):

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

طريقة المراجعة الجيدة (تعاونية ومركزة على الكود):

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

function getUserProfile(userId) {
  const user = database.findUser(userId);
  if (!user) {
    // Maybe return null or throw a specific error?
    return null; 
  }
  return user.profile;
}

لاحظتوا الفرق؟ الطريقة الثانية تفتح باب النقاش، تقترح حلاً، وتفترض النية الحسنة. إنها تقول: “نحن في هذا معاً”.

3. أتمتة النقد التافه (Automate the Nitpicks)

من أكثر الأشياء اللي بتسبب احتكاك في مراجعات الكود هي التعليقات على التنسيق والأسلوب: المسافات الزائدة، الفاصلة المنقوطة، ترتيب الـ imports… إلخ. هاي أمور مهمة للنظافة، لكن لا تستحق وقت وجهد البشر.

نصيحتي العملية: استخدموا الأدوات! أدوات مثل Prettier لتوحيد تنسيق الكود، و ESLint (لـ JavaScript) أو Black/Flake8 (لـ Python) لفرض قواعد الأسلوب والجودة. قوموا بضبطها لتعمل تلقائياً قبل كل `commit` (باستخدام pre-commit hooks).
بهذه الطريقة، “الروبوت” هو من يقوم بالنقد التافه، والمراجعون البشر يتفرغون للأمور الأهم: منطق العمل، التصميم، المعمارية، والحالات الحرجة.

4. القدوة الحسنة: على القائد أن يبدأ بنفسه

كقائد للفريق، كان عليّ أن أكون أول من يطبق هذه المبادئ. بدأت أتعمد طلب المساعدة في القنوات العامة. كنت أرفع طلبات دمج (PRs) لكود أعرف أنه ليس مثالياً، وأكتب في الوصف: “يا جماعة، هذا هو تصوري الأولي، لكنني لست متأكداً من أفضل طريقة لمعالجة X، أرحب بآرائكم”.

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

الخلاصة: من ساحة معركة إلى ورشة عمل إبداعية 🧑‍💻

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

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

يعطيكم ألف عافية! 🙏