لا تضيع وقتك في مراجعة التنسيقات: كيف فوضت n8n ليكون هو الـ Reviewer الأول

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

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

مرة ينسى يضيف ملف .env.example، ومرة ثانية يكون الكود مش ماشي على معايير التنسيق (Linting) اللي متفقين عليها، ومرة ثالثة ينسى يحدث ملف التوثيق. كل مرة كنت أضطر أوقف اللي بإيدي، وأفتح الكود، وأكتبله تعليق: “يا أحمد، الله يرضى عليك، ارجع شوف ملف كذا”، “يا أحمد، شغل أمر الـ linting قبل ما تبعت”. الموضوع صار يستهلك وقت وجهد ذهني كبير، ويطلعني من تركيزي في حل المشاكل الأهم في بنية النظام.

في ليلة من الليالي، وأنا براجع PR لأحمد الساعة 2 الفجر، ولقيت نفس المشكلة للمرة العاشرة، قلت لحالي: “شو هالحكي! لازم يكون في حل”. أنا مبرمج، وظيفتي أحل المشاكل، وهذه مشكلة بتتكرر ولازم أحلها مرة وللأبد. ومن هنا بدأت رحلتي مع صديقي الجديد، n8n، اللي صار هو المراجع الأول للكود في فريقي.

“وجع الراس” اليومي: لماذا نحتاج لمراجع آلي؟

قبل ما ندخل في التفاصيل التقنية، خلينا نكون صريحين. عملية مراجعة الكود (Code Review) هي حجر أساس في أي فريق برمجي محترم. لكن جزء كبير منها، للأسف، هو عمل متكرر وممل. هذه بعض المشاكل اللي كانت تسرق وقتي الثمين:

• أخطاء التنسيق (Linting): مسافات زيادة، فواصل منقوطة ناقصة، أسماء متغيرات غير متوافقة… كلها أمور مهمة للنظافة والتوحيد، لكن لا تستدعي تدخل مهندس خبير.
• الملفات المنسية: كم مرة وصلك PR بدون تحديث لملف package.json أو composer.json؟ أو الأسوأ، بدون ملف .env.example الذي يشرح للمطور الجديد كيف يجهز بيئته.
• عدم تحديث التوثيق: إضافة ميزة جديدة بدون تحديث ملف CHANGELOG.md أو ملفات التوثيق الأخرى يعني أن الميزة “غير موجودة” بالنسبة لباقي الفريق.
• فشل الاختبارات الأساسية: أحياناً يرسل المطور الكود وهو يعمل على جهازه، لكنه يكسر اختباراً أساسياً في المشروع.

هذه الأمور لا تحتاج لذكاء معماري أو خبرة سنوات لحلها، بل تحتاج لانتباه. والمشكلة أن انتباه المطور الخبير يجب أن يركز على أمور أعمق: منطق العمل (Business Logic)، الأداء (Performance)، الأمان (Security)، والتصميم المعماري (Architecture). عندما أقضي وقتي في تصحيح الفواصل، فأنا أهدر المورد الأغلى في المشروع: وقتي وخبرتي.

تعرف على صديقي الجديد: n8n

هنا يأتي دور الأتمتة. هناك الكثير من أدوات الـ CI/CD مثل Jenkins و GitLab CI و GitHub Actions، وهي ممتازة. لكن ما يميز n8n هو أنه أداة أتمتة سير عمل (Workflow Automation) مرئية وسهلة الاستخدام بشكل لا يصدق. هو ليس مجرد أداة CI/CD، بل هو “صمغ” يربط بين كل الأدوات التي تستخدمها.

ببساطة، n8n يسمح لك ببناء عمليات تلقائية عبر واجهة رسومية، حيث تقوم بسحب وإفلات “العقد” (Nodes) التي تمثل تطبيقات (مثل GitHub, Slack, Gmail) أو وظائف (مثل IF/Else, Run Script) وتربطها ببعضها. أفضل ما فيه أنه “fair-code”، ويمكنك استضافته على خوادمك الخاصة، مما يعطيك تحكماً كاملاً في بياناتك وعملياتك.

بناء سير العمل (Workflow) خطوة بخطوة

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

الخطوة الأولى: المشغل (The Trigger) – GitHub يسمعنا!

أول شيء في أي سير عمل هو “المشغل” الذي يبدأ العملية. في حالتنا، المشغل هو حدث معين في GitHub.

1. في n8n، أضف عقدة GitHub Trigger.
2. قم بربط حسابك في GitHub.
3. في خانة “Events”، اختر pull_request.
4. هذا سيجعل سير العمل يبدأ تلقائياً عند فتح، إعادة فتح، أو تحديث أي Pull Request في المستودع (Repository) الذي تحدده.

نصيحة أبو عمر: لا تنسَ تفعيل خيار “Re-Opened” و “Synchronize” في إعدادات المشغل. هذا يضمن أن البوت سيعيد فحص الكود حتى بعد أن يقوم المطور بتعديله بناءً على ملاحظات سابقة.

الخطوة الثانية: التحليل (The Analysis) – دع السكربت يقوم بالعمل الشاق

هنا يكمن “العقل” المدبر للعملية. لدينا طريقتان، سأشرحهما معاً:

الطريقة الأفضل (الموصى بها): هي الاعتماد على CI Pipeline (مثل GitHub Actions) لإجراء الفحوصات، ثم إعلام n8n بالنتيجة. لماذا هي الأفضل؟ لأن بيئة الفحص تكون معزولة ونظيفة، والعملية كلها موثقة داخل المستودع نفسه.

كيف تعمل؟

1. أنشئ ملف workflow في GitHub Actions (مثلاً: .github/workflows/validation.yml). هذا الـ workflow سيعمل تلقائياً مع كل PR.
2. سيقوم هذا الـ workflow بتشغيل سكربت الفحص الأولي.
3. في نهاية الـ workflow، سواء نجح أم فشل، سيقوم بإرسال طلب HTTP (باستخدام cURL) إلى عنوان Webhook خاص بسير عمل n8n، حاملاً معه النتيجة.

مثال على سكربت فحص بسيط (validation.sh):

#!/bin/bash
echo "--- Running Initial PR Checks ---"

# Check 1: Linting
npm run lint
if [ $? -ne 0 ]; then
  echo "LINTING_FAILED"
  exit 1
fi

# Check 2: Missing .env.example
if [ ! -f ".env.example" ]; then
  echo "ENV_EXAMPLE_MISSING"
  exit 1
fi

# Check 3: CHANGELOG update
# This checks if CHANGELOG.md was changed in this PR compared to the main branch
if git diff --quiet origin/main HEAD -- CHANGELOG.md; then
  echo "CHANGELOG_NOT_UPDATED"
  exit 1
fi

echo "--- All Checks Passed! ---"
exit 0

في GitHub Actions، ستقوم بتشغيل هذا السكربت، وفي حال فشله (exit code 1)، سترسل webhook إلى n8n مع رسالة الخطأ (مثلاً: “LINTING_FAILED”).

الخطوة الثالثة: القرار (The Decision) – عقدة الـ IF

بعد عقدة المشغل (GitHub Trigger)، أضف عقدة IF. هذه العقدة ستفحص البيانات القادمة من GitHub.

ستقوم العقدة بالتحقق من حالة الـ CI/CD pipeline المرتبط بالـ PR. معظم أنظمة الـ CI تضيف “check” أو “status” للـ PR. يمكن لعقدة الـ IF أن تفحص هذه الحالة.

• الشرط: تحقق مما إذا كانت نتيجة الفحص (التي أرسلها الـ CI pipeline أو التي يمكن جلبها عبر API) هي “failure”.
• المخرج: سيكون للعقدة مخرجان: true (إذا فشل الفحص) و false (إذا نجح الفحص).

الخطوة الرابعة: الإجراء (The Action) – البوت يتكلم!

هنا نربط الإجراءات المناسبة بكل مخرج من عقدة الـ IF.

في حالة الفشل (مخرج True):

1. أضف عقدة GitHub Node.
2. اختر “Pull Request” كـ “Resource” و “Create a Comment” كـ “Operation”.
3. استخدم البيانات من عقدة المشغل لتحديد المستودع ورقم الـ PR.
4. اكتب رسالة واضحة ومفيدة في التعليق. هذه أهم نقطة.

   مرحباً @{{ $json.body.pull_request.user.login }}، يعطيك العافية.
       
   يبدو أن هناك بعض المشاكل التي تحتاج إلى حل قبل أن نتمكن من مراجعة طلب الدمج هذا:
   
   **السبب:** فشل في فحص التنسيق (Linting).
   **الحل المقترح:** الرجاء تشغيل الأمر `npm run lint:fix` على جهازك ثم قم برفع التعديلات.
   
   شكراً لجهودك!
       
   -- أبو عمر (المراجع الآلي) 🤖

5. (اختياري) يمكنك إضافة عقدة GitHub أخرى بعدها مباشرة لتقوم بـ “Close Pull Request” وتضيف tag مثل “needs-changes”.

في حالة النجاح (مخرج False):

1. أضف عقدة من اختيارك للإشعارات. أنا شخصياً أستخدم Telegram.
2. أرسل رسالة لنفسك أو لقناة الفريق المخصصة للمراجعات.
3. مثال على الرسالة:

   يا أبو عمر، شد حيلك!
       
   طلب الدمج #{{ $json.body.pull_request.number }} من المطور @{{ $json.body.pull_request.user.login }} جاهز للمراجعة البشرية النهائية.
       
   ✅ كل الفحوصات الأولية نجحت.
       
   الرابط: {{ $json.body.pull_request.html_url }}

نصائح من خبرة “أبو عمر” 🧔

• ابدأ بسيطاً ثم توسع: لا تحاول أتمتة كل شيء من اليوم الأول. ابدأ بفحص واحد فقط، مثل الـ Linting. عندما يعمل بشكل جيد، أضف فحصاً آخر.
• اجعل رسائل البوت صديقة ومفيدة: لا تجعل المطور يشعر أن آلة تهاجمه. اجعل الرسالة لطيفة، والأهم، أن تخبره بالضبط ما هي المشكلة وكيف يمكنه حلها. هذا يحول التجربة من إحباط إلى تعلم.
• لا تستبدل المراجعة البشرية: هذا البوت هو “المساعد” وليس “البديل”. وظيفته هي تصفية المشاكل السطحية حتى أتمكن أنا (وأنت) من التركيز على جودة الكود الحقيقية والمنطق والتصميم.
• وثّق الأتمتة: أضف قسماً في ملف CONTRIBUTING.md في مشروعك يشرح ما هي الفحوصات الآلية التي سيتم إجراؤها. هذا يضع توقعات واضحة للمطورين الجدد.

الخلاصة: استثمر وقتك في الإبداع، لا في التصحيح 💡

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

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