مراجعة الكود كانت حقل ألغام: كيف حوّلنا الصراع إلى تعاون بـ “المراجعات القائمة على التعاطف”؟

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

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

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

“هذا الكود بطيء.”
“لماذا لم تستخدم X؟”
“هيكلية خاطئة، أعد كتابة كل شيء.”
“هذا الاسم للمتغير لا معنى له.”

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

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

لماذا تتحول مراجعات الكود إلى حقل ألغام؟

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

الأنا (Ego) والارتباط الشخصي بالكود

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

سوء فهم النوايا (النص لا ينقل النبرة)

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

فجوة الخبرات (صراع الأجيال التقني)

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

المنقذ: المراجعات القائمة على التعاطف (Empathy-Based Reviews)

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

كيف نطبقها عمليًا؟ دليل أبو عمر خطوة بخطوة

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

أولاً: للمُراجِع (The Reviewer) – كن مُعلّمًا لا جلادًا

1. ابدأ دائمًا بالإيجابيات: قبل ما تطلع القطط الفاطسة، دور على شغلة إيجابية واحكيها. حتى لو كانت بسيطة. هذا بيفتح نفس المؤلف وبيخليه متقبل للنقد.
   • مثال: “يعطيك العافية يا سامر، شغل مرتب! عجبتني الطريقة اللي تعاملت فيها مع حالات الحواف (edge cases) هنا.”
2. اسأل، لا تأمر: بدل ما تفرض رأيك، اطرحه كسؤال. هذا بيعطي شعور بالحوار والتعاون بدل ما يكون أمر عسكري.
   • بدلًا من: “غير هذا اللوب واستخدم map.”
   • جرّب: “فكرة حلوة استخدام اللوب هنا. شو رأيك لو فكرنا نستخدم map؟ ممكن تخلي الكود أوضح شوي في المستقبل. ايش رأيك؟”
3. اشرح “السبب” دائمًا: لا تترك تعليق غامض. “هذا خطأ” ما بتفيد حدا. اشرح ليش هو خطأ، وما هو الأثر المترتب عليه، وما هو البديل الأفضل.
   • بدلًا من: “لا تستخدم متغير عام هنا.”
   • جرّب: “انتبهت إنك استخدمت متغير عام هنا. أقترح نمرره كـ parameter للدالة، عشان نتجنب أي side effects غير متوقعة وممكن تأثر على أجزاء ثانية من التطبيق في المستقبل، وهذا بيخلي الدالة بتاعتنا (pure) أكثر.”
4. فرّق بين الأسلوب الشخصي والمعيار المتفق عليه: إذا كان الكود شغال وصحيح ويتبع معايير الفريق (Style Guide)، لكنه مكتوب بأسلوب مختلف عن أسلوبك الشخصي، فكّر مرتين قبل ما تطلب تغييره. الهدف هو كود جيد، مش كود مكتوب بطريقتك أنت بالضبط.

مثال عملي: قبل وبعد

تخيل أنك تراجع هذا الكود في Java:

// Get names of active users
List<String> names = new ArrayList<>();
for(User user : users){
  if(user.isActive()){
    names.add(user.getName());
  }
}

طريقة المراجعة القديمة (المدمرة):

“ليش بتستخدم for loop في 2024؟ هذا شغل قديم. استخدم Streams.”

طريقة المراجعة القائمة على التعاطف (البنّاءة):

“شغل نظيف واللوجيك صحيح 100% 👍. عندي اقتراح بسيط ممكن يخلي الكود مقروء أكثر في المستقبل. بما أننا بنستخدم Java 8 وفوق، ممكن نستفيد من الـ Streams. الكود ممكن يصير هيك:
List<String> names = users.stream().filter(User::isActive).map(User::getName).collect(Collectors.toList());
هذا الأسلوب (declarative) بيخلي نية الكود واضحة من أول نظرة. مجرد اقتراح لتحسين الكود، القرار عندك بالنهاية.”

شايفين الفرق؟ في الحالة الثانية، المبرمج تعلم شيئًا جديدًا، وشعر بالتقدير، والكود تحسن.

ثانياً: لمؤلف الكود (The Code Author) – كن طالب علم لا ضحية

1. لا تأخذ الأمر على محمل شخصي: تذكر دائمًا، الملاحظات هي على الكود، مش عليك. افصل بين هويتك كإنسان وبين الكود اللي كتبته اليوم. الكود يمكن تغييره وتحسينه، وهذا لا يقلل من قيمتك أبدًا.
2. افترض حسن النية: حتى لو كان التعليق جافًا، افترض أن زميلك نيته يساعد. إذا لم تفهم التعليق أو شعرت أنه هجومي، اطلب التوضيح بهدوء.
   • مثال: “شكرًا على الملاحظة أبو خليل. ممكن توضحلي أكثر قصدك بـ ‘هذا بطيء’؟ هل في سيناريو معين أثر على الأداء عشان أقدر أعمل اختبار عليه؟”
3. اشكر المُراجِع: هذا الشخص أخذ من وقته ليقرأ الكود تبعك ويساعدك. كلمة “شكرًا على وقتك” أو “ملاحظة ممتازة، شكرًا” بتعمل العجايب في بناء العلاقات.
4. كن منفتحًا للنقاش: إذا كان عندك سبب وجيه لقرارك البرمجي، اشرحه بهدوء ومنطقية. قد يكون المُراجع لا يعرف السياق الكامل. الحوار هو ما ينتج أفضل الحلول.

بناء ثقافة التعاطف في الفريق

هذه المنهجية لا تنجح بمجهود فردي، بل تحتاج إلى أن تصبح ثقافة عامة في الفريق.

• القيادة بالقدوة: كقائد تقني، كنت أول وأكثر واحد يلتزم بهذه القواعد. كنت أمدح علنًا، وأنقد بلطف، وأشجع الحوار.
• وضع قواعد أساسية مكتوبة: كتبنا وثيقة بسيطة اسمها “مبادئ مراجعة الكود في فريقنا” ووضعناها في مكان يراه الجميع. هذا جعل القواعد مرجعًا رسميًا وليس مجرد “كلام أبو عمر”.
• المراجعات المتزامنة (Sync Reviews): أحيانًا، النقاش بالكتابة بيطول وبيعمل سوء فهم. في هذه الحالات، كنت أقول: “يا شباب، الموضوع أخذ أكبر من حجمه. خلينا نفتح مكالمة 5 دقايق ونحسمه”. هذه المكالمات كانت توفر ساعات من الجدال المكتوب.

الخلاصة: من مبرمجين إلى حرفيين متعاونين 🙏

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

نصيحتي الأخيرة لكل مبرمج ومدير فريق: المرة القادمة التي تفتح فيها طلب مراجعة (Pull Request)، تذكر أن هناك إنسانًا على الطرف الآخر، بكل آماله ومخاوفه وتعبه. القليل من التعاطف والكلمة الطيبة لا يقلل من خبرتك، بل يجعلك قائدًا أفضل وزميلًا لا يُقدّر بثمن.

خلّيكوا مناح مع بعض، فالكود يُكتب ويُمسح، لكن الأثر الطيب في نفوس الناس يبقى.