يا جماعة الخير، السلام عليكم ورحمة الله.
اسمحوا لي اليوم أحكي لكم قصة صارت معي قبل كم سنة، قصة عن “مقبرة طلبات الدمج” اللي كانت عنا في الفريق. والله يا جماعة كان الوضع وصل لمرحلة صعبة. أتذكر جيداً ذلك اليوم، كان يوم ثلاثاء، وكان عندي طلب دمج (Pull Request أو PR) لميزة مهمة جداً، وكان صاحب الـ PR شب جديد معنا، شاطر ومتحمس، خلينا نسميه “سامر”.
سامر رفع الـ PR تبعه يوم الخميس اللي قبله، ومبسوط على حاله إنه خلص الشغل قبل الموعد. يوم الثلاثاء، فتحت الـ PR لألقي نظرة، وإذ بي أرى ما يشيب له الرأس: أكثر من 70 تعليقاً! والنقاش مش عن منطق البرنامج أو عن ثغرة أمنية خطيرة، لا والله. النقاش كان بين اثنين من كبار المبرمجين في الفريق، واحد بقول للثاني “ليش استخدمت for loop بدل map؟” والثاني برد عليه “الـ map هنا أبطأ من ناحية الأداء في هذه الحالة الخاصة جداً”. والنقاش امتد وتفرّع وصار عن أسماء المتغيرات، وعن المسافات (spaces vs tabs)، وعن أمور، صدقوني، كان ممكن يحلها أي مُنسّق كود (linter) تلقائياً.
المسكين سامر كان ضايع في النص، كل شوي يعدّل شغلة بناءً على طلب واحد، فيجي الثاني ويعترض. حسيت الولد رح يترك الشغل من الإحباط. والـ PR تبعه، اللي كان جاهز للدمج، صار زي قطعة أثرية في متحف، الكل بتفرج عليها وبتفلسف، بس ولا حدا عنده الجرأة ياخد قرار ويدمجها. هذا الموقف كان الشرارة، قلت لحالي: “خلص، بكفي. مش هيك القصة يا أبو عمر، لازم نلاقي حل جذري”.
لماذا كانت طلبات الدمج تتحول إلى ساحات معارك؟
قبل ما أحكيلكم عن الحل، خلينا نشخّص المشكلة صح. ليش كان يصير معنا هيك؟ بعد جلسة تفكير عميقة مع فنجان القهوة السادة، لخصت الأسباب في عدة نقاط:
1. الغموض هو سيد الموقف: لا توجد معايير واضحة
ما كان عنا أي اتفاق مكتوب أو حتى شفهي حول “ماذا تعني مراجعة الكود الجيدة؟”. كل واحد كان يراجع بناءً على خبرته، مزاجه، ومدرسته الفكرية في البرمجة. واحد بركز على الأداء، والثاني على قابلية القراءة (Readability)، والثالث على التصميم المعماري، والكل صح، بس النتيجة كانت فوضى.
2. الذوق الشخصي مقابل الحقائق الموضوعية
الكثير من التعليقات كانت من نوع “أنا أفضل أن تكتبها بهذه الطريقة” أو “هذا الأسلوب لا يعجبني”. هذه آراء شخصية، مش أخطاء برمجية حقيقية. تحولت المراجعة من عملية هندسية لعملية نقد فني، وهذا أكبر خطأ ممكن نقع فيه.
3. المراجع “الخبير” الذي يريد إثبات نفسه
في كل فريق، هناك ذلك المبرمج الخبير (وأحياناً بكون أنا للأسف!) الذي يشعر بمسؤولية تجاه كل سطر كود. من حرصه الزائد، يبدأ بالتدقيق في تفاصيل دقيقة جداً (Nitpicking)، ليس بهدف التحسين الحقيقي، بل أحياناً لإظهار خبرته وسيطرته. وهذا يقتل الإبداع ويخلق جو من الخوف.
4. انهيار التواصل: النص لا ينقل النوايا
تعليق مكتوب مثل “لماذا لم تستخدم X؟” يمكن أن يُقرأ كاستفسار بريء، ويمكن أن يُقرأ كاتّهام بالجهل. غياب لغة الجسد ونبرة الصوت في التواصل الكتابي كان سبباً رئيسياً في سوء الفهم والجدل العقيم.
نقطة التحول: تقديم “ميثاق مراجعة الكود”
هنا قررت أننا بحاجة إلى “دستور”. وثيقة نتفق عليها جميعاً، تحدد قواعد اللعبة، وتحول مراجعة الكود من “وجع راس” إلى عملية بناءة وممتعة. أطلقت عليها اسم “ميثاق مراجعة الكود” (Code Review Charter).
شو قصة هالميثاق؟
ببساطة، هو وثيقة حية (living document) يكتبها ويوافق عليها كل أعضاء الفريق الهندسي. هذه الوثيقة لا تقول لك “استخدم tabs وليس spaces”، بل تحدد كيفية إجراء المراجعة، ما هو نطاقها، وكيف نتواصل ونتعامل مع الخلافات.
كيف بنيناه خطوة بخطوة (ورشة عمل)
- اجتماع الفريق (بدون مدراء): حجزت قاعة اجتماعات، جبت قهوة و”كنافة نابلسية” عشان أروّق الجو، وجمعت كل المبرمجين. طلبت من المدراء عدم الحضور عشان الكل ياخد راحته في الكلام.
- تفريغ ما في القلوب: بدأت الجلسة بسؤال واحد: “يا جماعة، شو أكثر إشي بكرهكم في عملية مراجعة الكود حالياً؟”. أعطيت كل واحد أوراق ملاحظات (sticky notes) وطلبت منهم يكتبوا كل مشاكلهم وأوجاعهم ويلصقوها على السبورة.
- تحويل السلبيات إلى مبادئ إيجابية: بعد ما امتلأت السبورة بالمشاكل (مثل: “تأخير في المراجعة”، “تعليقات جارحة”، “جدل على تفاهات”)، بدأنا كمجموعة بتحويل كل مشكلة إلى “مبدأ” أو “قاعدة”.
- “تأخير في المراجعة” -> تحولت إلى -> “مبدأ: نلتزم بالرد على طلبات المراجعة خلال 24 ساعة عمل”.
- “جدل على تفاهات” -> تحولت إلى -> “مبدأ: ما يمكن أتمتته (مثل تنسيق الكود) لا نناقشه يدوياً. المراجعة تركز على المنطق والتصميم”.
- “تعليقات جارحة” -> تحولت إلى -> “مبدأ: نسأل ولا نأمر. نقدم اقتراحات وليس أوامر. (مثال: بدل ‘غير هذا’، نقول ‘ما رأيك لو جربنا كذا؟’)”.
- صياغة المسودة الأولى: تطوعت أنا ومبرمج آخر لجمع كل هذه المبادئ وصياغتها في وثيقة مرتبة على Google Docs أو Confluence.
- المراجعة والتصديق: أرسلنا المسودة لكل الفريق، وأخذنا أسبوعاً كاملاً لجمع الملاحظات والتعديلات النهائية، ثم عقدنا اجتماعاً قصيراً للموافقة عليه بالإجماع. أصبح الميثاق “قانون” الفريق الرسمي.
ماذا يحتوي ميثاقنا؟ (تشريح عملي)
لأعطيكم فكرة أوضح، هذا هو الهيكل العام للميثاق الذي توصلنا إليه، مع بعض الأمثلة:
المبدأ الأسمى (The Prime Directive)
الهدف الأساسي من مراجعة الكود هو تحسين جودة المنتج النهائي ككل. نحن نراجع “الكود” وليس “كاتب الكود”. كلنا في قارب واحد، وهدفنا الوصول إلى بر الأمان بأفضل كود ممكن.
نطاق المراجعة (Scope of Review)
هنا حددنا بوضوح ما يجب التركيز عليه وما يجب تجاهله.
- أمور نركز عليها:
- المنطق والأخطاء (Logic & Bugs): هل الكود يفعل ما هو مطلوب منه؟ هل هناك حالات طرفية (edge cases) لم تتم تغطيتها؟
- التصميم المعماري (Architecture): هل يتبع الكود الأنماط المعمارية المتفق عليها في الفريق؟ هل هو قابل للتوسعة والصيانة؟
- الأمان (Security): هل هناك أي ثغرات أمنية محتملة (مثل SQL Injection, XSS)؟
- الاختبارات (Tests): هل توجد اختبارات كافية تغطي الكود الجديد؟
- وضوح الكود (Clarity): هل أسماء المتغيرات والدوال واضحة؟ هل الكود معقد أكثر من اللازم؟
- أمور نتجنبها (لأنها مؤتمتة):
- تنسيق الكود (Code Style): المسافات، الفواصل، طول الأسطر… إلخ. هذه وظيفة أدوات مثل Prettier, ESLint, Black. يجب أن تكون جزءاً من عملية الـ CI/CD.
نصيحة عملية: أضفنا خطوة إلزامية في الـ CI/CD Pipeline تفحص تنسيق الكود (linting). إذا فشلت، لا يمكن دمج الـ PR. هذا يزيل 90% من الجدل غير المفيد.
# مثال بسيط على خطوة في GitHub Actions
- name: Run Linter
run: npm run lint -- --fail-on-error
مسؤوليات المراجع (Reviewer’s Responsibilities)
- كن سريع الاستجابة: اعترف باستلام طلب المراجعة خلال ساعات قليلة، وقدم مراجعتك الكاملة خلال 24 ساعة عمل. إذا كنت مشغولاً، أبلغ صاحب الكود بذلك.
- كن بنّاءً: اشرح “لماذا” تقترح تغييراً، وليس فقط “ماذا” يجب تغييره. اربط اقتراحك بأحد مبادئ الميثاق (مثل: “أقترح تغيير اسم هذا المتغير لتحسين الوضوح كما اتفقنا في الميثاق”).
- اسأل، لا تأمر:
- سيء: “استخدم `async/await` هنا.”
- جيد: “ما رأيك في استخدام `async/await` هنا لتبسيط الكود وتجنب الـ callback hell؟”
- وازن بين المثالية والواقعية: لا تطلب إعادة كتابة كل شيء من الصفر. الهدف هو تحسين تدريجي، وليس الوصول للكمال في كل PR.
- امدح أيضاً: إذا رأيت شيئاً جيداً، قل ذلك! كلمة “شغل مرتب يا خال!” أو “فكرة ممتازة” ترفع المعنويات كثيراً.
مسؤوليات صاحب الكود (Author’s Responsibilities)
- اجعل الـ PR صغيراً ومركزاً: الـ PR الذي يغير 1000 سطر في 20 ملفاً هو كابوس للمراجعة. حاول أن يكون كل PR يعالج مشكلة واحدة فقط.
- اكتب وصفاً واضحاً: اشرح “لماذا” هذا التغيير ضروري، و “كيف” قمت بحله. أضف صوراً أو فيديوهات قصيرة إذا كان التغيير في الواجهة الأمامية.
- لا تأخذ الملاحظات بشكل شخصي: تذكر المبدأ الأسمى. النقد موجه للكود. كن ممتناً لأن زميلك يقضي وقتاً لمساعدتك.
- قم بمراجعة الكود بنفسك أولاً: قبل أن تطلب مراجعة من الآخرين، راجع الكود بنفسك كما لو كنت شخصاً آخر. ستكتشف الكثير من الأخطاء.
آلية حل الخلافات (Dispute Resolution)
هذه كانت أهم نقطة. اتفقنا على ما يلي:
إذا استمر النقاش في تعليقات الـ PR لأكثر من 3 ردود ذهاباً وإياباً دون الوصول إلى اتفاق، يجب التوقف عن الكتابة فوراً. الحل هو الانتقال إلى تواصل متزامن: مكالمة سريعة (5 دقائق) أو الذهاب إلى مكتب الزميل ومناقشة الأمر وجهاً لوجه. إذا لم يتم التوصل إلى حل، يتم تصعيد الأمر إلى القائد التقني (Tech Lead) لاتخاذ القرار النهائي.
النتائج: من الفوضى إلى “شغل مرتب”
والله يا جماعة، النتائج كانت أسرع وأفضل مما توقعت. خلال شهر واحد فقط، لاحظنا تغييرات جذرية:
- انخفاض متوسط عمر الـ PR: نزل من 3-4 أيام إلى أقل من 24 ساعة في معظم الحالات.
- تقليل الجدل: اختفت النقاشات الطويلة حول التنسيق والأسلوب الشخصي تماماً.
- تحسن معنويات الفريق: شعر المبرمجون، وخصوصاً الجدد منهم، بأمان نفسي أكبر. أصبحوا لا يخافون من عرض أعمالهم.
- زيادة جودة الكود: لأننا أصبحنا نركز على الأمور المهمة (المنطق، التصميم، الأمان)، أصبحت المراجعات أكثر فعالية وقيمة.
خلاصة الكلام والنصيحة من أخوكم أبو عمر 👨💻
يا أصدقائي المبرمجين وقادة الفرق، “ميثاق مراجعة الكود” ليس مجرد قطعة ورق أو بيروقراطية زائدة. إنه استثمار في أهم أصل تملكونه: ثقافة فريقكم. إنه الأداة التي تحول عملية فوضوية ومحبطة إلى عملية هندسية منظمة وبناءة.
لا تنتظروا حتى تصلوا إلى مرحلة “مقبرة طلبات الدمج”. ابدأوا اليوم. اجمعوا فريقكم، تحدثوا بصراحة عن أوجاعكم، وضعوا دستوركم الخاص. قد تبدو خطوة صغيرة، لكن أثرها على الإنتاجية والرضا الوظيفي وجودة الكود سيكون هائلاً.
تذكروا دائماً، الكود العظيم تبنيه فرق عظيمة، والفرق العظيمة لا تتشكل بالصدفة، بل بالاتفاق والتنظيم والاحترام المتبادل. موفقين جميعاً. 🙏
