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

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

ما هو نموذج Gemma؟

Gemma هو عائلة من النماذج اللغوية الخفيفة والمفتوحة المصدر، طُوِّرت بواسطة Google DeepMind، وتعتمد على نفس التقنيات البحثية التي بُنِيَت عليها نماذج Gemini. يتميز بقدرات متقدمة في معالجة اللغة الطبيعية NLP، مما يجعله خيارًا قويًا لمجموعة واسعة من المهام اللغوية. يتوفر Gemma بإصدارين رئيسيين، مما يمنح المستخدمين مرونة في توظيفه وفقًا لمتطلبات المهام المختلفة:

الإصدار المضبوط على التعليمات Instruction Tuned - IT: دُرب على تفاعلات لغوية بشرية، مما يجعله مثاليًا للمحادثات والتطبيقات التفاعلية مثل الشات بوت Chatbot والمساعدات الذكية. يتميز هذا الإصدار بقدرته على فهم الأسئلة والاستجابة لها بأسلوب طبيعي وقريب من طريقة تواصل البشر

الإصدار المسبق التدريب Pretrained - PT: لم يخصص لمهام محددة، حيث يعتمد فقط على البيانات الأساسية التي دُرب عليها. وبالتالي، فهو يحتاج إلى ضبط إضافي Fine-Tuning ليتمكن من أداء مهام متخصصة مثل توليد الشعر أو تحليل النصوص. لذا، فإن استخدامه مباشرة دون ضبط قد لا يكون فعالًا في التطبيقات التي تتطلب دقة وتخصصًا أكبر

لماذا اخترنا Gemma؟

اخترنا نموذج Gemma لعدة أسباب رئيسية:

• مفتوح المصدر وقابل للتخصيص: يتيح إمكانية تعديله وضبطه بسهولة، مما يسمح بتكييفه مع الأوزان والقوافي الشعرية في اللغة العربية
• خفيف مقارنة بالنماذج العملاقة، مما يجعله مناسبًا للتشغيل محليًا أو عبر موارد سحابية محدودة
• مرونة في التشغيل، حيث يمكن استخدامه مع Keras, PyTorch, Transformers وغيرها من الأدوات
• دعم لغوي واسع في النسخة الثالثة من النموذج Gemma 3، حيث يدعم أكثر من 140 لغة، بما في ذلك اللغة العربية

عملية الصقل Fine-Tuning

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

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

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

اقتباس

{"input": "اكتب بيتًا من الشعر العمودي في مدح العلم", "output": "العلمُ يبني بيوتًا لا عمادَ لها  والجهلُ يهدمُ بيتَ العزّ والشّرفِ"}

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

هناك نوعان رئيسيان من تقنيات الصقل Fine-Tuning:

• صقل النموذج الكامل Full Fine-Tuning: تُعدل جميع أوزان النموذج بالكامل. يتطلب هذا النوع موارد حسابية كبيرة وقد يستغرق وقتًا طويلًا
• صقل النموذج منخفض الموارد Parameter Efficient Fine-Tuning - PEFT: يُعدل عدد محدود من الأوزان فقط، مما يقلل من استهلاك الذاكرة ويحسن الكفاءة. من الأساليب المشهورة في هذا النوع هي LoRA و QLoRA

تجهيز بيانات التدريب

لتحقيق نتائج مثالية عند صقل نموذج Gemma لتوليد الشعر العربي، من الضروري إعداد مجموعة بيانات غنية ومتنوعة تُلبي الهدف المطلوب. تعتمد نجاح عملية الصقل Fine-Tuning على جودة البيانات وتنظيمها وتنوعها، لذا يجب أولًا تحديد الموضوعات الأساسية للقصائد، مثل وصف الطبيعة أو الغزل أو الفخر أوالرثاء أوالهجاء أو القضايا الاجتماعية والسياسية.

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

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

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

اقتباس

 

{ "prompt": "اكتب لي أبياتًا من الشعر العربي الفصيح عن الفخر، باستخدام مفردات جزلة وقافية منتظمة، بأسلوب الشاعر أبو فراس الحمداني.",
"poem": "سَيَذكُرُني قَومي إِذا جَدَّ جِدُّهُمُ\nوَفي اللَيلَةِ الظَلماءِ يُفتَقَدُ البَدرُ\nفَإِن عِشتُ فَالطَعنُ الَّذي يَعرِفونَهُ\nوَتِلكَ القَنا وَالبيضُ وَالضُمَّرُ الشُقرُ" }

 { "prompt": "اكتب لي أبياتًا من الشعر العربي عن القضايا السياسية والاجتماعية، بأسلوب شعر حر، مع استخدام مفردات بسيطة ومباشرة، بأسلوب يشابه أسلوب الشاعر أحمد مطر.",
 "poem": "ما تهمتي؟\nتهمتك العروبة\nقلت لكم ما تهمتي؟\nقلنا لك العروبة\nيا ناس قولوا غيرها\nأسألكم عن تهمتي ..\nليس عن العقوبة" }

تشغيل وصقل نموذج Gemma

لتنفيذ عملية الصقل Fine-Tuning لنموذج Gemma، سنطبق الخطوات التالية من خلال منصة Kaggle لتسريع عملية التدريب باستخدام GPU أو TPU. سنعمل على تشغيل النموذج باستخدام مكتبة Keras نظرًا لسهولة استخدامها.

نبدأ أولًا بتثبيت المكتبات الرئيسية اللازمة لتشغيل النموذج، مثل keras-nlp وkeras:

!pip install -q -U keras-nlp
!pip install -q -U keras

بعد ذلك، نستورد المكتبات التي سنحتاج إليها أثناء عملية التدريب:

import keras
import keras_nlp
import os

• Keras: مكتبة أساسية لبناء نماذج التعلم العميق
• keras-nlp: مكتبة توفر أدوات ونماذج جاهزة لعمليات الـ NLP
• os: تُستخدم للتعامل مع البيئة وتشغيل أوامر النظام

سوف نختار JAX كخلفية لتشغيل النموذج:

os.environ["KERAS_BACKEND"] = "jax"  # Or "torch" or "tensorflow".
os.environ["XLA_PYTHON_CLIENT_MEM_FRACTION"] = "0.9"

• KERAS_BACKEND: تحديد البيئة التي سنستخدمها لتشغيل Keras، حيث إن Keras هو واجهة برمجة تطبيقات عالية المستوى تدعم العديد من أطر العمل للتعلم العميق مثل TensorFlow وJAX وPyTorch
• XLA: يتيح تسريع الحسابات في JAX. الكود يحدد استخدام 90% من الذاكرة المتاحة لتجنب مشاكل تجزئة الذاكرة

ثم نحمل النموذج باستخدام keras_nlp:

gemma_lm = keras_nlp.models.Gemma3CausalLM.from_preset("gemma3_instruct_1b")
gemma_lm.summary()

summary: عرض ملخص للنموذج ليتمكن المستخدم من رؤية هيكل النموذج، مثل الطبقات وعدد المعلمات

الخطوة التالية هي تحميل البيانات، حيث نعمل على قراءة ملف JSON الذي يحتوي على بيانات الشعر ونحضرها للنموذج. في هذه العملية، سنستخرج الموجهات prompts والاستجابات من البيانات، ثم نحولها إلى مجموعة بيانات باستخدام مكتبة TensorFlow كالتالي:

import json
import tensorflow as tf

def prepare_training_data_poetry(json_path):
    # فتح ملف البيانات مع استخدام ترميز يدعم اللغة العربية
    with open(json_path, 'r', encoding='utf-8') as file:
        # قراءة محتوى الملف وتحويله إلى بيانات يمكن التعامل معها في بايثون
        data = json.load(file)

    # قائمة لحفظ الموجهات التي تُعطى للنموذج
    prompts = []

    # قائمة لحفظ القصائد أو الأبيات التي تمثل الإجابات المتوقعة
    responses = []

    # المرور على كل مثال تدريبي داخل ملف البيانات
    for entry in data:
        # إضافة نص الطلب أو التعليمات إلى قائمة الموجهات
        prompts.append(entry['prompt'])

        # إضافة النص الشعري المقابل إلى قائمة الإجابات
        responses.append(entry['poem'])

    # إنشاء مجموعة بيانات من الموجهات والإجابات حتى يمكن استخدامها في التدريب
    dataset = tf.data.Dataset.from_tensor_slices({
        "prompts": prompts,
        "responses": responses
    })

    # خلط البيانات، ثم تقسيمها إلى دفعات صغيرة، ثم تجهيز الدفعات التالية مسبقًا لتسريع التدريب
    dataset = dataset.shuffle(len(prompts)).batch(1).prefetch(tf.data.AUTOTUNE)

    # إرجاع البيانات بعد تجهيزها
    return dataset

# تجهيز بيانات التدريب من ملف البيانات الموجود في المسار المحدد
training_data = prepare_training_data_poetry('/kaggle/input/arabic-potry/data.json')

• json.load: قراءة وتحميل البيانات من ملف بصيغة JSON
• Dataset.from_tensor_slice: تحويل القوائم إلى مجموعة بيانات قابلة للاستخدام في التدريب
• shuffle: خلط البيانات بشكل عشوائي

بعد ذلك، نستخدم تقنية LoRA لتحسين التدريب عن طريق تقليل عدد المعاملات التي سوف تُعدل، مما يساعد في تقليل استهلاك الذاكرة مع الحفاظ على الأداء الجيد:

gemma_lm.backbone.enable_lora(rank=64)
gemma_lm.summary()

rank=64: يحدد حجم المصفوفات التي سوف تُعدل. قيمة صغيرة تعني تعديلات أبسط وأقل تكلفة، بينما قيمة كبيرة تعني تعديلات أعقد وأكثر تكلفة

ثم، نحدد المعاملات الخاصة بالتدريب مثل تحديد طول السلسلة Sequence length إلى 512 لتقليل استهلاك الذاكرة، واختيار مُحسِّن Optimizer مثل AdamW:

# تحديد الحد الأقصى لطول النص الذي سيدخله النموذج أثناء التدريب
# أي أن النموذج سيعالج تسلسلًا لا يتجاوز 512 رمزًا
gemma_lm.preprocessor.sequence_length = 512

# إنشاء المحسّن المسؤول عن تحديث أوزان النموذج أثناء التدريب
optimizer = keras.optimizers.AdamW(
    # تحديد سرعة تعلّم النموذج
    # كلما كانت القيمة صغيرة كان التحديث أبطأ وأكثر استقرارًا
    learning_rate=5e-5,

    # تقليل احتمالية حفظ النموذج للبيانات بدل تعلّم الأنماط العامة
    # وذلك عبر إضافة عقوبة بسيطة على الأوزان الكبيرة
    weight_decay=0.01,
)

# استثناء بعض المتغيرات من عقوبة تقليل الأوزان
optimizer.exclude_from_weight_decay(var_names=["bias", "scale"])

# تجهيز النموذج لمرحلة التدريب من خلال تحديد دالة الخطأ والمُحسّن ومقاييس التقييم
gemma_lm.compile(
    # دالة الخطأ المستخدمة في مهام التنبؤ بالكلمة أو الرمز التالي
    loss=keras.losses.SparseCategoricalCrossentropy(from_logits=True),

    # استخدام المحسّن الذي أنشأناه لتحديث أوزان النموذج
    optimizer=optimizer,

    # مقياس لحساب دقة النموذج في اختيار الرمز الصحيح أثناء التدريب
    weighted_metrics=[keras.metrics.SparseCategoricalAccuracy()],
)

• sequence_length: تحديد الحد الأقصى لطول التسلسل المدخل
• learning_rate=5e-5: معدل التعلم الذي يتحكم في سرعة التحديثات
• weight_decay=0.01: تقليل التأثير الزائد للوزن

وأخيرًا، نبدأ عملية صقل النموذج باستخدام البيانات التي جهزناها:

gemma_lm.fit(training_data, epochs=1)

بعد صقل النموذج، يمكننا حفظ الأوزان التي عُدلت أثناء عملية الصقل Fine-Tuning لتحميلها لاحقًا دون الحاجة لإعادة التدريب، وذلك باستخدام الأمر التالي:

gemma_lm.backbone.save_lora_weights("name.lora.h5")

تجربة أداء النموذج بعد التدريب

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

اقتباس

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

output = gemma_lm.generate(
    f"Instruction:\n{prompt}\n\nResponse:\n",
    max_length=512
)

print(output)

 

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

يمكن أيضًا تحسين جودة المخرجات عبر استخدام تقنية Few-shot Prompting، حيث يتم إرسال التعليمات إلى النموذج مرفقةً بأمثلة توضح المطلوب بدقة. هذا يساعد النموذج على التقاط النمط والأسلوب المستهدف. المثال التالي يوضح ذلك:

prompt = """

أنت نموذج ذكاء اصطناعي متخصص في كتابة الشعر العربي بأسلوب المتنبي.  
اكتب أبياتًا شعرية تعبر عن الفخر، الطموح، القوة، والحكمة بأسلوب المتنبي.  

### مثال :  
**المدخل:** "اكتب لي أبياتًا عن الطموح والسعي وراء المجد بأسلوب المتنبي."  
**المخرج:**  
"إِذا غامَرتَ في شَرَفٍ مَرومِ  
فَلا تَقنَع بِما دونَ النُجومِ  
فَطَعمُ المَوتِ في أَمرٍ صَغيرٍ  
كَطَعمِ المَوتِ في أَمرٍ عَظيمِ"  


الآن، أكمل وفقًا لنفس النمط:  

**المدخل:** "اكتب لي أبياتًا من الشعر العمودي عن الحكمة بأسلوب المتنبي."  
**المخرج:**  

"""
result = gemma_lm.generate(f"Instruction:\n {prompt} \n\nResponse:\n", max_length=512)
print(result.split("Response:")[1])

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

نصائح لتحسين الأداء

لتحقيق نتائج أفضل في توليد الشعر العربي بأساليب مختلفة، يمكننا اتباع عدة استراتيجيات:

تحسين وتنويع بيانات التدريب

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

استخدام نموذج أكبر

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

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

تحسين المعاملات الخاصة بالتدريب

• زيادة قيمة LoRA Rank: إذا كان النموذج الحالي يستخدم rank=64، يمكن زيادة هذه القيمة إلى rank=128 أو أكثر للحصول على ضبط أدق وأداء أفضل
• زيادة قيمة Rank قد تساعد في تحسين قدرة النموذج على تخصيص الأوزان بشكل أفضل أثناء عملية الصقل Fine-Tuning
• تدريب النموذج على عدد أكبر من Epochs: يمكن تجربة قيم أعلى مثل epochs=5 للمساعدة في تثبيت الأنماط الشعرية داخل النموذج بشكل أكثر فعالية

الخاتمة

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

code.rar

اقرأ أيضًا

• طريقة الصقل Fine-Tune لنموذج ذكاء اصطناعي مُدرَّب مُسبقًا
• المعالجة المُسبقة للبيانات قبل تمريرها لنماذج الذكاء الاصطناعي
• نظرة عامة على الصنف Trainer في مكتبة المحولات Transformers
• مشاركة نموذج ذكاء اصطناعي على منصة Hugging Face

المراجع

• Gemma 3 model overview
• Gemma 3
• aldiwan
• What is Supervised Fine-Tuning?

يبدو أننا نشهد عصرًا جديد من البرمجة ستمكننا جميعًا من إطلاق العنان لإبداعنا وصناعة ما يحلو لنا من مواقع وتطبيقات دون أن نحتاج لامتلاك معرفة تقنية واسعة ونضطر لكتابة الكثير من الأكواد البرمجية لنتفاهم مع الحواسيب ونطلب منها تنفيذ ما نريده. فالمعادلة بدأت تتغير بوتيرة متسارعة مع انتشار تقنيات الذكاء الاصطناعي المساعدة في البرمجة ومن أحدثها مفهوم فايب كودينغ Vibe Coding الذي أتاح لنا التعبير عن أفكارنا بلغة طبيعية وتحويلها لتطبيقات تعمل بمنتهى السهولة.

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

ما هو Vibe Coding؟

إن مصطلح فايب كودينج Vibe Coding هو اتجاه حديث في تطوير البرمجيات طرحه لأول مرة عالم الحاسوب أندريه كارباثي Andrej Karpathy، أحد المؤسسين المشاركين في شركة OpenAI والمدير السابق لفريق الذكاء الاصطناعي في تسلا يشير إلى أسلوب برمجة يعتمد على النماذج اللغوية الكبيرة LLMs، حيث يصف المطوّر التطبيق المطلوب بلغة طبيعية، ويتولى الذكاء الاصطناعي توليد الكود البرمجي لهذا التطبيق.

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

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

أهم أدوات Vibe Coding

تتوفر الكثير من الأدوات والمنصات التي تتيح لنا بناء التطبيقات باستخدام أسلوب Vibe Coding، ومن ضمنها:

Replit

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

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

Lovable

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

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

Cursor

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

توفر المنصة خطة مجانية باسم Hobby تمكننا من تنفيذ 50 طلب، كما توفر عدة خطط مدفوعة، وتتيح لنا تجربة مجانية لمدة أسبوعين للخطة الاحترافية المدفوعة Pro التي تبلغ تكلفتها 20 دولار في الشهر.

GitHub Copilot Agent Mode

يوفر GitHub Copilot يسمى وضع الوكيل Agent Mode يحوله إلى من مجرد مساعد برمجي ذكي لمنصة تطويرية ذكية حيث يصبح بإمكانه تنفيذ مهام تطويرية متعددة، كإنشاء تطبيقات متكاملة وإعادة هيكلة أكوادها، واختبارها وتصحيح أخطائها، كما يمكنه تحديث التطبيقات القديمة وترحيلها إلى أطر عمل حديثة، وهو يتكامل مع محرر الأكواد فيجوال ستوديو كود Visual Studio Code ويدعم اختيار نماذج ذكاء اصطناعي مختلفة مثل GPT-4o و Claude 3.5 وGemini 2.0 Flash، كما يتكامل بشكل كبير معGitHub، ويدعم عدة لغات برمجة، لكن ميزة Agent Mode لا تزال حديثة نسبيًا، وقد تكون بعض الاقتراحات غير دقيقة أو غير مناسبة للسياق وتحتاج لمراجعة من قبل المبرمج.

فيما يخص التسعير يتيح GitHub Copilot خطة المجانية محدودة بـ50 طلبًا شهريًا، كما يوفر خطط مدفوعة تبدأ بتكلفة 10 دولار شهريًا أو 100 دولار سنويًا، ويمكن أيضًا الاشتراك في الخطط المدفوعة مجانًا لبعض الفئات مثل الطلاب والمعلمين والمساهمين في المشاريع مفتوحة المصدر.

OpenHands

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

هناك العديد من الأدوات الأخرى التي تدعم أسلوب Vibe Coding ويعتمد اختيار الأداة المناسبة على احتياجاتكم وأهدافكم، ننصح بتجربة بعض الأدوات مع خططها المجانية أو الإصدارات التجريبية منها لمعرفة الأداة الأفضل من بينها. بعد أن تعرفنا على أبرز الأدوات التي تستخدم أسلوب Vibe Coding، دعونا الآن نجرب تطوير تطبيق متكامل باستخدامه.

تطوير تطبيق متكامل باستخدام Vibe Coding

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

الخطوة الأولى: اختيار منصة Vibe Coding

أول خطوة علينا اتباعها هو اختيار الأداة أو المنصة المناسبة للبرمجة بأسلوب Vibe Coding، سنختار في هذه المقالة منصة Replit التي توفر -كما وضحنا سابقًا- بيئة تطوير متكاملة تغنينا عن الحاجة لإعداد البيئة البرمجية يدويًا وتتيح لنا التركيز على مهام البرمجة وحل المشكلات.

يمكن بسهولة إنشاء حساب مجاني في المنصة بالضغط على زر Sign up وإدخال بيانات الدخول الخاصة بنا.

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

الخطوة الثانية: كتابة الموجهات

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

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

لننتبه هنا أنه ليس علينا أن نعطي الموجه الكامل لتفاصيل التطبيق بل يكفي أن نبدأ بموجه بسيط وستتخذ أفكارنا شكلها النهائي من خلال الحوار مع الذكاء الاصطناعي.

ملاحظة: سنكتب الموجهات prompts باللغتين العربية والإنجليزية ونعتمد على الانجليزية لأن أغلب بيانات تدريب النماذج اللغوية الضخمة LLMs باللغة الإنجليزية وخاصة تلك التي تتضمن أكواد ومصطلحات برمجية وهي تعطي نتائج أدق، ولكن لازال بالإمكان توجيه الأوامر والطلبات باللغة العربية من هذه الأدوات.

سنبدأ العمل بكتابة موجه بسيط من وكيل الذكاء الاصطناعي لإنشاء نموذج أولي على النحو التالي:

اقتباس

الموجه باللغة الإنجليزية:

Help me build an interactive Flask app for voting and ranking the most famous archaeological landmarks in the Arab world. The app should allow users to vote on landmarks head-to-head, then calculate a ranking for the landmarks based on the chess Elo system. The app should prominently display the matchup along with overall rankings and recent votes.

الموجه باللغة العربية:

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

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

اقتباس

الموجه باللغة الإنجليزية:

I want you to rely on the historical landmarks displayed on this page as a source of information. https://ar.wikipedia.org/wiki/قائمة_مواقع_التراث_العالمي_في_الدول_العربية 

الموجه باللغة العربية:

أريدك أن تعتمد على المعالم الأثرية المعروضة في هذه الصفحة كمصدر للمعلومات https://ar.wikipedia.org/wiki/قائمة_مواقع_التراث_العالمي_في_الدول_العربية

في هذه الحالة سنلاحظ ظهور خيارين للتعامل مع الرابط المرفق الأول هو التقاط لقطة شاشة Take screenshot من أجل التقاط صورة للمحتوى الموجود في الرابط وهو مفيد إذا كنا نريد حفظ شكل الصفحة أو مشاركتها كصورة. والثاني هو استخراج المحتوى النصي Get text content الذي يجلب المعلومات النصية الموجودة في الصفحة، بدون الصور أو التنسيقات المرئية وهو مفيد إذا كنا نريد تحليل النص واستخدمها في تطبيقنا.

سنكتب الآن الموجه الأول كاملًا كما في الصورة التالية ونرسله بالضغط على زر Start Building:

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

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

بداية لن تختار أيًا من المميزات الإضافية وسنبني التطبيق الأساسي فقط، ويمكننا إضافة ما نريده ميزات لاحقًا متى ما أردنا ذلك، لنضغط على زر Approve plan & start لتبدأ عملية إنشاء التطبيق.

ليس علينا الآن سوى الانتظار لدقائق معدودة، وترك المنصة تقوم بعملها وتنشئ التطبيق المطلوب باسم Arab World Heritage Sites مع توفير كافة ملفات المشروع وأكواده المطلوبة.

الخطوة الثالثة: اختبار التطبيق

الآن علينا تجربة الكود الناتج من خلال تشغيل التطبيق والتحقق من أدائه

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

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

الخطوة الرابعة: تحسين النتائج

سنكتب موجهات جديدة لتنفيذ مهام تحسينية ومميزات إضافية لتخصيص التطبيق وجعله يعمل وفق متطلباتنا.

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

لنكتب هذا الموجه لتنفيذ هذا التحسين.

اقتباس

الموجه باللغة الإنجليزية

The app is functioning properly, but it currently displays all content — except for the landmark names — in English. We need the entire application to be in Arabic, with full RTL layout support. Additionally, the current color scheme is too generic. Please update it to reflect earthy tones and shades of brown that better match the theme of historical and archaeological sites.

الموجه باللغة العربية

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

عند تطبيق الموجه السابق سنحصل على النتيجة التالية التي تعرض الصفحة الرئيسية للتطبيق:

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

لو تحقننا من ملفات الكود يمكن أن نرى أن التطبيق يخزن بيانات المعالم الأثرية في القاموس landmarks ضمن ملف models.py، ويخزن نتائج التصويت الأخيرة في قائمة بالاسم votes تحفظ آخر 50 نتيجة وتخزنها مؤقتًا في الذاكرة. ولجعل النتائج محفوظة بشكل دائم حتى بعد إعادة تشغيل التطبيق سنحتاج إلى إنشاء قاعدة بيانات مثل SQLite أو PostgreSQL ونحول landmarks و votes إلى جداول، كما سننشئ جدول للمستخدمين للسماح لهم بالتسجيل والتصويت.

بالطبع لن نقوم بهذه التعديلات على الكود بأنفسنا بل سنتبع أيضًا أسلوب Vibe Coding فكل ما نحتاجه هو كتابة موجه نصي بسيط على النحو التالي:

اقتباس

الموجه باللغة الإنجليزية:

To ensure data is persistently stored and accessible across sessions and for all users, we will store it permanently in the database. We'll implement a user authentication system with registration and login functionality, using email and securely encrypted passwords. Voting will be restricted to authenticated users only. Once a user is logged in, each vote will be linked to their account to maintain accurate user-specific data.

الموجه باللغة العربية:

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

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

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

كما سنلاحظ أن نتائج التصويت أصبحت تحفظ عند إعادة تشغيل التطبيق.

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

ننوه لأن منصة Replit توفر لنا نقاط حفظ تلقائية أثناء تنفيذ تغييرات مهمة على التطبيق،يطلق على كل نقطة اسم checkpoint وهي بمثابة لقطة لحالة التطبيق في لحظة معينة تساعدنا على تتبع سير العمل وتتيح لنا التراجع Rollback لإلغاء التعديلات التي أجريناها في حال كانت غير مناسبة وأردنا العودة لحالة التطبيق السابقة، كما تمكننا من حفظ الكود الناتج من خلال النقر على خيارات التبويب الجانبي Files واختيار الأمر Download as zip ليحفظ لنا كافة الأكواد البرمجية التي أنشأها باسم LandmarkLegends.zip.

الخطوة الخامسة: نشر التطبيق

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

نلاحظ من اللوحة السابقة توفر عدة خيارات للنشر:

• Reserved VM الذي يوفر خادم محجوز بموارد مخصصة تضمن تشغيل تطبيقنا دون انقطاع
• Autoscale يوسع الموارد تلقائيًا حسب استخدام التطبيق
• Static مناسب للمواقع الثابتة التي لا تتطلب معالجة من طرف الخادم
• Scheduled مناسب للتطبيقات التي تعمل في أوقات محددة نختارها

بعد تحديد نوع النشر وإعداداته ستتيح لنا المنصة عنوان URL فريد خاص به يمكننا مشاركته مع المستخدمين، ويجب التأكد من أن نمط الخصوصية privacy mode لتطبيقنا هو عام public كي يتمكن الجميع من رؤيته، ويمكن مطالعة توثيق Replit للحصول على معلومات إضافية حول عملية النشر.

هل سيلغي Vibe Coding دور المبرمجين

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

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

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

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

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

أهمية Vibe Coding للمبرمجين

يوفر أسلوب Vibe Coding عدة فوائد للمطورين والمبرمجين، لنستعرض أبرزها:

تغير طبيعة العمل

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

بناء نماذج أولية بسرعة

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

توفير أسلوب تعلم مبتكر

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

تحسين مهارات كتابة الموجهات

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

الخاتمة

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

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

المصادر

1. دليل البدء مع منصة Replit لإنشاء وتشغيل المشاريع البرمجية
2. فايب كودينج Vibe Coding: المفهوم والتعريف العام
3. ما هو Vibe Coding؟ شرح مبسط لكيفية بناء التطبيقات باستخدام الذكاء الاصطناعي
4. Vibe Coding: اتجاه حديث في تطوير البرمجيات باستخدام الذكاء الاصطناعي
5. Vibe Coding: عصر جديد من البرمجة بالذكاء الاصطناعي مع تحدياته
6. ما هو Vibe Coding؟ المزايا والعيوب في تطوير التطبيقات بالذكاء الاصطناعي

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

كيف تعمل فلاتر الصور؟

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

كما نعرف فإن الصورة مكوّنة من عدد من البكسلات pixels التي تحتوي على ثلاث قيم من 0 إلى 255 لكل من القنوات اللونية الثلاث وهي الأحمر والأخضر والأزرق التي يرمز لهم بالمصطلح RGB. وبالتالي، يمكننا تمثيل الصورة بمصفوفة عددية كما يوضّح الشكل التالي:

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

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

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

بعد أن تعرفنا على آلية عمل الفلاتر على الصورة دعونا نبدأ خطوات تطوير تطبيقنا بايثون يمكننا من رفع الصورة المطلوبة وتعديلها بفلاتر مختلفة.

الخطوة الأولى: تجهيز بيئة العمل

لنبدأ أولًا بتجهيز بيئة العمل عن طريق تجهيز المكتبات التي سنستخدمها، بالإضافة لهيكل المشروع من ملفات ومجلدات. سننشئ مجلدًا نسميه image-filters وهو المجلد الذي سيمثل المجلد الجذر لمشروعنا، ومن ثم ننشئ بداخله مجلدين الأول باسم images الذي سنضع فيه الصور التي نريد فلترتها والثاني باسم output وهو المجلد الذي سنخزن فيه الصور الناتجة عن تطبيق الفلتر، وأخيرًا ننشئ ملف image_filters.py الذي سيحتوي الشيفرة البرمجية لبرنامجنا، ويمكننا إنشاء ملف يدعى README.md يشرح كيفية عمل البرنامج ومزاياه.

يصبح لدينا هيكل المشروع في النهاية كما يلي:

image-filters/
├── images/               # مجلد يحتوي الصور التي تريد فلترتها
│   ├── sample.jpg
├── output/               # مجلد نخزن فيه الصور الناتجة عن تطبيق الفلتر
├── image_filters.py      # الشيفرة البرمجية
├── README.md             # للتوثيق ‪(اختياري)‪‬‬

بعدها، نذهب إلى طرفية سطر الأوامر command line وننفّذ التعليمة التالية:

pip install opencv-python numpy pillow

ستتكفل هذه التعليمة بتحميل المكتبات التي سنستعين بها لتطبيق الفلاتر على الصور، وهي مكتبة opencv ومكتبة numpy ومكتبة pillow لذا يجب التأكد من توفر اتصال الإنترنت قبل تنفيذ الأمر.

يمكننا التأكد من أن عملية التحميل قد تمت بنجاح بتنفيذ السطر التالي:

py -c "import cv2; import numpy; import PIL; print('Packages installed successfully!')"

إن تمت العملية بنجاح سنحصل على رسالة Packages installed successfully!‎ في الطرفية.

الخطوة الثالثة: كتابة الهيكل الأساسي للبرنامج

نبدأ باستيراد import المكاتب التي سنستخدمها في بداية الشيفرة البرمجية داخل ملف image_filters.py سنستخدم أيضًا مكتبة os المضمنة في بايثون التي ستساعدنا على إنشاء المجلدات/المسارات:

import cv2
import numpy as np
import os

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

import tkinter as tk
from tkinter import filedialog, Label, Button, ttk
from PIL import Image, ImageTk

نحفظ كل من مسار الصورة مع اسمها واسم الفلتر الذي نختاره وسنبني الفلاتر المتاحة في برنامجنا في الخطوات التالية، ومن ثم نخزّن الصورة في متغير بالاستعانة بمكتبة opencv:

image = cv2.imread(image_path)

ننشئ filters نضمّن فيها جميع الفلاتر التي يدعمها برنامجنا بالشكل التالي:

filters = {
    "Grayscale": apply_grayscale,
    "Blur": apply_blur,
    "Edge Detection": apply_edges,
    "Sharpen": apply_sharpen,
    "Cartoon": apply_cartoon,
    "Remove Background": remove_background
}

إن أردنا تجزئة منطق البرنامج المطلوب ليسهل علينا فهمه، يمكننا النظر إليه بكونه يقدّم ثلاث مزايا أساسية:

1. تطبيق الفلتر على صورة
2. عرض الصورة على الواجهة البرمجية
3. حفظ الصورة التي طُبّق عليها الفلتر على الحاسب

لنشرح الشيفرة البرمجية لكل ميزة على حدى بالتفصيل فيما يلي.

تطبيق الفلتر على الصورة

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

def apply_filter():
# جعل نطاق المتغيرات نطاق عام يمكن الوصول إليهما في أي مكان من البرنامج
    global img, img_display

# بحال لم يختر المستخدم الصورة بعد أو لم يستطع البرنامج قراءة الصورة
    if img is None:
        return

# تخزين الفلتر الذي اختاره المستخدم من الواجهة الرسومية
    selected_filter = filter_var.get()

# في حال لم يكن الفلتر مدعومًا من قبل البرنامج
    if selected_filter not in filters:
        return

# نسخ الصورة بعد قرائتها وتطبيق الفلتر على الصورة
    image = img.copy()
    image = filters[selected_filter](image)

# تحويل الصورة إلى صورة بألوان RGB في حال كانت صورة بتدرجات رمادية
    if len(image.shape) == 2:  # Convert grayscale to RGB for display
        image = cv2.cvtColor(image, cv2.COLOR_GRAY2RGB)

# ‫تحويل ترميز الصورة من نظام BGR إلى RGB‬
    image = cv2.cvtColor(image, cv2.COLOR_BGR2RGB)

# تحويل مصفوفة القيم إلى صورة
    image = Image.fromarray(image)

# تحويل الصورة إلى ترميز يدعمه‫ Tkinter لعرضها على الواجهة الرسومية‬
    img_display = ImageTk.PhotoImage(image)

# عرض الصورة على الواجهة الرسومية
    label_img.config(image=img_display)

ملاحظة: الخطوات الأخيرة هي بسبب اختلاف تعامل كل من مكتبة OpenCV وTkinter -وبالنتيجة مكتبة Pillow- بعرض وتمثيل الصور، إذ تستخدم كل مكتبة ترميزًا معينًا والتحويل السابق بين الترميز ضروري لعرض الصورة على الواجهة الرسومية.

عرض الصورة على الواجهة الرسومية

نريد أيضًا أن نعرض الصورة الأولية بعد أن نختارها من مستعرض الملفات، لذا ننشئ الدالة load_image لتحقيق ذلك:

def load_image():
    global img, img_display

# فتح نافذة مستعرض الملفات واختيار الصورة بالامتدادت المدعومة المضمنة
    file_path = filedialog.askopenfilename(filetypes=[("Image Files", "*.jpg;*.png;*.jpeg")])

# في حال تعذّر وجود الصورة
    if not file_path:
        return

# قراء الصورة وضبط أبعادها وتحضيرها للعرض على الواجهة الرسومية
    img = cv2.imread(file_path)
    img_resized = cv2.resize(img, (400, 300))
    img_resized = cv2.cvtColor(img_resized, cv2.COLOR_BGR2RGB)
    img_resized = Image.fromarray(img_resized)

# عرض الصورة على الواجهة
    img_display = ImageTk.PhotoImage(img_resized)
    label_img.config(image=img_display)

حفظ الصورة الناتجة على الحاسب

أخيرًا، نريد حفظ الصورة الناتجة على حاسبنا، لذا نكتب دالة نسميها save_image بالشكل التالي:

def save_image():
    global img

# في حال تعذر قراءة الصورة أو كونها فارغة
    if img is None:
        return

# الحصول على اسم الفلتر الذي اخترناه لتضمين اسمه في الصورة المحفوظة
    selected_filter = filter_var.get()
    output_dir = "output"

# ‫ننشئ مجلد الصور الناتجة output في حال عدم وجوده‬
    if not os.path.exists(output_dir):
        os.makedirs(output_dir)

    output_filename = os.path.join(output_dir, f"filtered_{selected_filter}.jpg")
    cv2.imwrite(output_filename, img)

القيم الموجودة في filters هي جميع الفلاتر التي سندعمها في برنامجنا، وسنبرمج المنطق الخاص بكل واحد منها ولكن دعونا أولًا نبرمج الواجهة الرسومية!

الخطوة الخامسة: برمجة الواجهة الرسومية

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

نكتب الشيفرة البرمجية التالية لتحقيق الشكل السابق:

# إنشاء عقدة جذر البرنامج
root = tk.Tk()

# ضبط عنوان نافذة البرنامج وأبعادها
root.title("Image Filter App")
root.geometry("500x550")

# ‫إنشاء متغير img وإسناد قيمة أولية له‬
img = None

# إنشاء زر إضافة الصورة ونص العنوان
Label(root, text="Image Filter Application", font=("Arial", 16)).pack(pady=10)

Button(root, text="Load Image", command=load_image).pack(pady=5)

label_img = Label(root)
label_img.pack(pady=5)

# القائمة المنسدلة التي تحتوي على الفلاتر
filter_var = tk.StringVar()
filter_var.set("Grayscale") # نضبط فلتر التدرج الرمادي كقيمة افتراضية
filter_menu = ttk.Combobox(root, textvariable=filter_var, values=list(filters.keys()), state="readonly")
filter_menu.pack(pady=5)

# إضافة الأزرار
Button(root, text="Apply Filter", command=apply_filter).pack(pady=5)
Button(root, text="Save Image", command=save_image).pack(pady=5)

root.mainloop()

الخطوة الرابعة: كتابة الفلاتر المتاحة

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

فلتر التدرج الرمادي Grayscale

نبدأ بأبسط الفلاتر عملًا وهو فلتر تغيير ألوان الصورة إلى تدرجات اللون الرمادي:

def apply_grayscale(image):
    return cv2.cvtColor(image, cv2.COLOR_BGR2GRAY)

تعمل الدالة cvtColor على تغيير قيم البكسلات الموجودة في الصورة التي تحتوي على القيم الثلاث الأحمر والأخضر والأزرق حتى تحتوي على قيمة واحدة تدلّ على شدة اللون مما يمنحنا اللون الرمادي بتدرجاته.

فلتر التغبيش Blur

ننتقل فيما بعد إلى فلتر التغبيش blur ولدى مكتبة opencv دالة جاهزة يمكننا استخدامها ألا وهي GaussianBlur ونمرر لها ثلاث قيم، الصورة ومقدار التشويش والانحراف المعياري للمرشح:

def apply_blur(image, ksize = (15,15)):
    return cv2.GaussianBlur(image, ksize, 0)

يمكننا زيادة مقدار التغبيش بزيادة قيمة المعامل الثاني ksize.

فلتر الكشف عن الحواف Edge detection

الفلتر الثالث هو فلتر الكشف عن الحواف edge detection وهو فلتر يستخدم بكثرة في تطبيقات الرؤية الحاسوبية للكشف عن الأجسام والتعرف عليها، إذ يعتمد على التغيرات الكبيرة بين بكسل وبكسل آخر يجاوره. لدينا أيضًا تابع جاهز تقدمة مكتبة opencv وهو Canny نمرر له ثلاث قيم وهي الصورة والعتبة الدنيا والعتبة العليا، وهي قيمتين تتحكمان بمقدار الحساسية للكشف عن حافة ما.

def apply_edges(image, low_threshold=100, high_threshold=200):
    return cv2.Canny(image, low_threshold, high_threshold)

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

فلتر الشحذ Sharpen

ننتقل إلى فلتر الشحذ Sharpen الذي يبرز حواف الصورة بشكل أكبر ويزيد من التباين في الصورة، نستخدم في هذا الفلتر مصفوفة معرّفة وهو أحد المرشحات Kernel التي ذكرناها في بداية المقال بالشكل التالي:

def apply_sharpen(image):
    kernel = np.array([[0, -1, 0],
                       [-1, 5, -1],
                       [0, -1, 0]])
    return cv2.filter2D(image, -1, kernel)

نستطيع الاستفادة من هذا الفلتر عن طريق توضيح الصور المغبّشة غير الواضحة.

فلتر الرسم الكرتوني Cartoon

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

def apply_cartoon(image):
    # تحويل الصورة إلى صورة ذات تدرج رمادي ‪(بشكل مشابه للفلتر الأول)‎‬
    gray = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY)

    # تطبيق تغبيش على الصورة
    blurred = cv2.medianBlur(gray, 5)

    # التعرف على الحواف وتنعيمها للحصول على نتيجة تشبه صورة مرسومة
    edges = cv2.adaptiveThreshold(blurred, 255, cv2.ADAPTIVE_THRESH_MEAN_C,
                                  cv2.THRESH_BINARY, 9, 10)

    # تغبيش الصورة مع المحافظة على الحواف مشحوذة
    color = cv2.bilateralFilter(image, 9, 250, 250)

    # دمج صورة الحواف مع صورة الألوان
    cartoon = cv2.bitwise_and(color, color, mask=edges)

    return cartoon

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

فلتر إزالة الخلفية Remove Background

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

def remove_background(image):
    # ننشئ نسخة بذات أبعاد الصورة لكن نملؤها بالأصفار
    mask = np.zeros(image.shape[:2], np.uint8)

    # نستخدم خوارزمية‫ GrabCut الموجودة في opencv لإنشاء نموذج للكائن في الصورة‬
    bgd_model = np.zeros((1, 65), np.float64)
    fgd_model = np.zeros((1, 65), np.float64)

    # نعرف مستطيلًا حول النموذج الذي أنشأناه
    rect = (50, 50, image.shape[1] - 50, image.shape[0] - 50)

    # ‫ننفذ خوارزمية GrabCut ‬
    cv2.grabCut(image, mask, rect, bgd_model, fgd_model, 5, cv2.GC_INIT_WITH_RECT)
    mask = np.where((mask == 2) | (mask == 0), 0, 1).astype("uint8")

    # نطبق الصورة ذات القيم الصفرية على صورتنا لإزالة الخلفية
    result = image * mask[:, :, np.newaxis]

    return result

نحصل على النتيجة التالية:

سنكتفي بهذه الفلاتر في تطبيقنا، ونترك لكم حرية التجربة وإضافة المزيد من الفلاتر على البرنامج، كل ما عليكم هو كتابة دالة جديدة تحتوي على المنطق البرمجي الذي يستخدمه هذا الفلتر وإضافتها إلى filters واستدعاؤها. ندعوكم لتجربة فلتر آخر وليكن عكس الألوان Invert colors وتجربة تضمينه في البرنامج لتحسينه.

الشيفرة البرمجية الكاملة للتطبيق

إليكم كامل الشيفرة الخاصة بالتطبيق لاختبارها وتجربتها لديكم:

import cv2
import numpy as np
import os
import tkinter as tk
from tkinter import filedialog, Label, Button, ttk
from PIL import Image, ImageTk

# دالة فلتر التدرج الرمادي
def apply_grayscale(image):
    return cv2.cvtColor(image, cv2.COLOR_BGR2GRAY)

# دالة فلتر التغبيش
def apply_blur(image, ksize=(25, 25)):
    return cv2.GaussianBlur(image, ksize, 0)

# دالة الكشف عن الحواف
def apply_edges(image, low_threshold=100, high_threshold=200):
    return cv2.Canny(image, low_threshold, high_threshold)

# دالة فلتر الشحذ
def apply_sharpen(image):
    kernel = np.array([[0, -1, 0],
                       [-1, 5, -1],
                       [0, -1, 0]])
    return cv2.filter2D(image, -1, kernel)

# دالة فلتر الرسوم الكرتونية
def apply_cartoon(image):
    gray = cv2.cvtColor(image, cv2.COLOR_BGR2GRAY)
    blurred = cv2.medianBlur(gray, 5)
    edges = cv2.adaptiveThreshold(blurred, 255, cv2.ADAPTIVE_THRESH_MEAN_C,
                                  cv2.THRESH_BINARY, 9, 10)
    color = cv2.bilateralFilter(image, 9, 250, 250)
    cartoon = cv2.bitwise_and(color, color, mask=edges)
    return cartoon

# ‫دالة فلتر إزالة الخلفية باستخدام خوارزمية Grab cut‬
def remove_background(image):
    mask = np.zeros(image.shape[:2], np.uint8)
    bgd_model = np.zeros((1, 65), np.float64)
    fgd_model = np.zeros((1, 65), np.float64)

    rect = (50, 50, image.shape[1] - 50, image.shape[0] - 50)
    cv2.grabCut(image, mask, rect, bgd_model, fgd_model, 5, cv2.GC_INIT_WITH_RECT)
    mask2 = np.where((mask == 2) | (mask == 0), 0, 1).astype("uint8")
    return image * mask2[:, :, np.newaxis]

# الفلاتر التي يدعمها البرنامج
filters = {
    "grayscale": apply_grayscale,
    "blur": apply_blur,
    "edges": apply_edges,
    "sharpen": apply_sharpen,
    "cartoon": apply_cartoon,
    "remove_bg": remove_background
}

def apply_filter():
# جعل نطاق المتغيرات نطاق عام يمكن الوصول إليهما في أي مكان من البرنامج
    global img, img_display

# بحال لم يختر المستخدم الصورة بعد أو لم يستطع البرنامج قراءة الصورة
    if img is None:
        return

# تخزين الفلتر الذي اختاره المستخدم من الواجهة الرسومية
    selected_filter = filter_var.get()

# في حال لم يكن الفلتر مدعومًا من قبل البرنامج
    if selected_filter not in filters:
        return

# نسخ الصورة بعد قرائتها وتطبيق الفلتر على الصورة
    image = img.copy()
    image = filters[selected_filter](image)

# تحويل الصورة إلى صورة بألوان RGB في حال كانت صورة بتدرجات رمادية
    if len(image.shape) == 2:  # Convert grayscale to RGB for display
        image = cv2.cvtColor(image, cv2.COLOR_GRAY2RGB)

# ‫تحويل ترميز الصورة من نظام BGR إلى RGB‬
    image = cv2.cvtColor(image, cv2.COLOR_BGR2RGB)

# تحويل مصفوفة القيم إلى صورة
    image = Image.fromarray(image)

# تحويل الصورة إلى ترميز يدعمه‫ Tkinter لعرضها على الواجهة الرسومية‬
    img_display = ImageTk.PhotoImage(image)

# عرض الصورة على الواجهة الرسومية
    label_img.config(image=img_display)

def load_image():
    global img, img_display

# فتح نافذة مستعرض الملفات واختيار الصورة بالامتدادت المدعومة المضمنة
    file_path = filedialog.askopenfilename(filetypes=[("Image Files", "*.jpg;*.png;*.jpeg")])

# في حال تعذّر وجود الصورة
    if not file_path:
        return

# قراء الصورة وضبط أبعادها وتحضيرها للعرض على الواجهة الرسومية
    img = cv2.imread(file_path)
    img_resized = cv2.resize(img, (400, 300))
    img_resized = cv2.cvtColor(img_resized, cv2.COLOR_BGR2RGB)
    img_resized = Image.fromarray(img_resized)

# عرض الصورة على الواجهة
    img_display = ImageTk.PhotoImage(img_resized)
    label_img.config(image=img_display)

def save_image():
    global img

# في حال تعذر قراءة الصورة أو كونها فارغة
    if img is None:
        return

# الحصول على اسم الفلتر الذي اخترناه لتضمين اسمه في الصورة المحفوظة
    selected_filter = filter_var.get()
    output_dir = "output"

# ‫ننشئ مجلد الصور الناتجة output في حال عدم وجوده‬
    if not os.path.exists(output_dir):
        os.makedirs(output_dir)

    output_filename = os.path.join(output_dir, f"filtered_{selected_filter}.jpg")
    cv2.imwrite(output_filename, img)

# إنشاء عقدة جذر البرنامج
root = tk.Tk()

# ضبط عنوان نافذة البرنامج وأبعادها
root.title("Image Filter App")
root.geometry("500x550")

# ‫إنشاء متغير img وإسناد قيمة أولية له‬
img = None

# إنشاء زر إضافة الصورة ونص العنوان
Label(root, text="Image Filter Application", font=("Arial", 16)).pack(pady=10)

Button(root, text="Load Image", command=load_image).pack(pady=5)

label_img = Label(root)
label_img.pack(pady=5)

# القائمة المنسدلة التي تحتوي على الفلاتر
filter_var = tk.StringVar()
filter_var.set("Grayscale") # نضبط فلتر التدرج الرمادي كقيمة افتراضية
filter_menu = ttk.Combobox(root, textvariable=filter_var, values=list(filters.keys()), state="readonly")
filter_menu.pack(pady=5)

# إضافة الأزرار
Button(root, text="Apply Filter", command=apply_filter).pack(pady=5)
Button(root, text="Save Image", command=save_image).pack(pady=5)

root.mainloop()

الخاتمة

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

سنستعرض في هذا المقال أساسيات منصة GitHub، التي تُعد واجهة ويب لنظام التحكم في الإصدارات Git والمملوكة لشركة Microsoft. سنركّز في هذا المقال على المفاهيم الأساسية للمنصة وآلية العمل عليها، بدءًا من إنشاء حساب جديد، ووصولًا إلى إعداد المصادقة Authentication لتأمين الوصول إلى الحساب واستخدامه بكفاءة.

اقتباس

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

إنشاء حساب GitHub

اذهب إلى موقع GitHub واضغط على زر إنشاء حساب جديد Sign up واتبع الإرشادات التي تظهر على الشاشة لإنشاء الحساب حتى تصل إلى لوحة التحكم في حسابك بعد إتمام تسجيل الدخول بنجاح.

إنشاء مستودع جديد في GitHub

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

• يوجد زر New أخضر على يسار اللوحة في الغالب، كما توجد قائمة منسدلة عليها علامة + أعلى جهة اليمين تحتوي خيار New Repository، هاتان طريقتان لإنشاء مستودع جديد تستطيع استخدام أيهما.

• أدخل اسم المستودع في الصفحة التي تلي ذلك، اختر أي اسم تريد بشرط ألا يكون لديك مستودع سابق بنفس الاسم، لنكتب test-repo لغرض مثالنا هنا.

• فعِّل خيار Add a README file لإضافة ملف Readme. لاحظ أن عليك تجنب هذا الخيار في المستقبل إذا كان لديك مستودع محلي وتريد دفعه push إلى هذه المستودع الجديد، لأن هذا سيمنع عملية الدفع.

• انقر على زر Create repository في أسفل الصفحة.

وهكذا صار لدينا أول مستودع خاص بنا.

مصادقة الحسابات

ينبغي أن نشرح عملية المصادقة authentication أولًا قبل الانتقال إلى شرح الاستنساخ cloning، ذلك أنك إذا جربت مزامنة مستودع محلي على حاسوبك مع مستودع بعيد على GitHub فلن تنجح لأن دعم المصادقة بكلمة المرور قد ألغي في 2021، فأمامنا الآن عدة خيارات:

• استخدام أداة GitHub CLI.
• استخدام مفاتيح SSH.
• استخدام مفاتيح المصادقة الشخصية Personal Authentication Tokens.

يُعد الخيار الأول هو الأسهل، أما مفاتيح SSH فهي خيار متقدم بالنسبة للمبتدئين.

واجهة سطر أوامر GitHub

تمثل أداة GitHub CLI واجهة نصية لموقع GitHub وتؤدي عدة وظائف أهمها تسهيل عملية المصادقة لحسابك فيه لتتمكن من تنفيذ مهامك مع Git كدفع ملفاتك إلى مستودع بعيد مثلًا.

لتثبيت هذه الأداة، زر صفحتها واتبع تعليمات التثبيت الخاصة بنظام تشغيلك، ثم جرب تشغيل الأمر gh --version بعد التثبيت لتتأكد من نجاح تثبيتها من خلال عرض معلومات إصدارها:

$ gh --version
  gh version 2.42.1 (2024-01-15)
  https://github.com/cli/cli/releases/tag/v2.42.1

ثم نفذ الأمرين التاليين:

$ gh auth login
$ gh auth setup-git

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

أما الأمر الثاني gh auth setup-git فننفذه مرة واحدة فقط حيث يضيف بعض العناصر المساعدة في عملية المصادقة إلى الإعدادات العامة.

مفاتيح SSH

لدينا خيار آخر للمصادقة هو مفتاح SSH، وذلك إن لم ترغب في استخدام أداة GitHub CLI السابقة، سنبدأ بتوليد مفتاح أولًا ثم استخدامه، تجاوز هذه الخطوة إذا كان لديك زوج من مفاتيح SSH بالفعل -ستعرف أنها لديك إذا نفذت الأمر:

ls ~/.ssh

ورأيت ملفًا مثل id_rsa.pub أو id_ed25519.pub. نفذ الأمر التالي لإنشاء زوج جديد من المفاتيح:

$ ssh-keygen -t ed25519 -C عنوان بريد الإلكتروني هنا

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

نصيحة أمنية

يفضل استخدام كلمة مرور للوصول إلى هذا المفتاح، ذلك أن وصول شخص غيرك إليه يمكّنه من انتحال شخصيتك والوصول إلى حسابك في GitHub، ويلجأ المطورون إلى استخدام Key Agent يتذكر كلمة المرور لفترة زمنية محددة.

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

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

استمر بالنقر على مفتاح الإدخال إذا ظهرت أي أسئلة على الشاشة حتى تصل إلى شيء شبيه بما يلي:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/user/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_ed25519
Your public key has been saved in id_ed25519.pub
The key fingerprint is:
SHA256:/lrT43BQBRPJpUXxpTBFInhdtZSQjQwxU4USwt5c0Lw user@locahost
The key's randomart image is:
+--[ED25519 256]--+
|        .o.X^%^=+|
|        ..oo*^.=o|
|        ..o = o..|
|         . + E   |
|        S .      |
|       .   o     |
|        . + +    |
|         o = .   |
|        ... .    |
+----[SHA256]-----+

سنحتاج إلى إجراء بعض الإعدادات الإضافية على المفتاح إذا اخترنا اسم ملف غير الاسم الافتراضي لكي نتمكن من تشغيله مع GitHub بشكل صحيح.

لاحظ هذا الرسم العشوائي الغريب في المثال أعلاه، وهو مجرد تمثيل بصري للمفتاح، وتوجد طرق لإعداد SSH بحيث تُعرض لك هذه اللوحة في كل مرة تسجل فيها الدخول، وفكرتها أنك إذا رأيت اختلافًا في اللوحة في مرة ما فهذا يعني أن شيئًا ما قد تغير في إعدادات الأمان. اكتب الآن ls ~/.ssh، يجب أن تظهر نتيجة كهذه:

id_ed25519    id_ed25519.pub

لا تشارك الملف الأول مع أحد أبدًا لأنه مفتاحك الخاص private key، بل لا يوجد سبب يدعوك حتى لنسخه، أما الملف الثاني هو المفتاح العام public key، وهو ما تستطيع مشاركته بأمان، وسنشاركه مع GitHub بعد قليل لكي تسجل الدخول باستخدامه.

اقتباس

جرب تنفيذ الأمرين أدناه إذا واجهت مشكلة بسبب تدقيق SSH الأمني:

 chmod 700 ~/.ssh $
*/chmod 600 ~/.ssh $

هذه عملية ستتم مرة واحدة فقط، إن لم تكن أذونات الملفات مقيدة.

نعطي المفتاح العام الآن إلى GitHub عبر نسخه.

لنحصل أولًا على نسخة منه ننفذ الأمر التالي -غير اسم الملف لاسم الملف الخاص بك-:

$ cat ~/.ssh/id_ed25519.pub

ينبغي أن تظهر لديك نتيجة كالتالي:

ssh-ed25519 AAAC3N[بعض المحارف هنا]V+znpoO عنوان بريدك

انسخ السطر كاملًا إلى الحافظة لتستطيع لصقه لاحقًا.

ربط المفتاح بـ GitHub

اذهب الآن إلى GitHub وانقر على صورتك الشخصية في أعلى اليمين ثم اتبع ما يلي:

1. اختر الإعدادات Settings.
2. اختر SSH and GPG keys.
3. اختر New SSH key
   • أدخل عنوانًا مناسبًا مثل "my laptop key" في حقل Title.
   • تأكد من اختيار Authentication key في حقل Key type.
   • الصق المفتاح الذي نسخناه قبل قليل في حقل key.
   • انقر على Add SSH key.

اقتباس

تذكر أننا استخدمنا بروتوكول SSH لاستنساخ روابط المستودعات لاحقًا.

استخدام مفاتيح الوصول الشخصي

حان الوقت لننشئ كلمات مرور جديدة نستخدمها مع GitHub، وستكون هذه المرة من نوع المفتاح الشخصي personal token، يوفر GitHub توثيقًا مفصلًا حول الموضوع لكن ملخصه أننا سننشئ مفتاح token يمثل بعض الصلاحيات، مثل القراءة والكتابة في مستودعاتي، وسنستخدمه بدلًا من كلمة المرور العادية في سطر الأوامر كما يلي:

Username for 'https://github.com': [اسم المستخدم]
Password for 'https://beejjorgensen@github.com': [مفتاح Token]

قد يحفظ حاسوبك هذا المفتاح لئلا تضطر إلى إدخاله في كل مرة، المهم أن إحدى أفضل مزاياه هي التحكم الدقيق في الصلاحيات حيث تستطيع تقييد الوصول ليكون للقراءة فقط أو اقتصار الصلاحيات على مستودعات معينة، وكذلك نستطيع استخدام مصادقة أداة GitHub CLI مع هذا المفتاح من خلال إعطاء المفتاح للأداة عبر الإدخال القياسي standard input.

لنفرض أنك حفظت المفتاح في ملف باسم mytoken.txt، نستطيع حينها إثبات هويتنا عبر واجهة أوامر GitHub كما يلي:

$ gh auth login --with-token < mytoken.txt

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

إنشاء نسخة محلية من المستودع

نحتاج الآن إلى معرفة رابط المستودع كي نستنسخه:

1. انقر على أيقونة صورتك الشخصية في الزاوية العلوية اليمنى ثم اختر Your repositories، ستظهر لك صفحة تضم جميع مستودعاتك، قد لا تجد هنا سوى المستودع test-repo الذي أنشأناه، فانقر على اسمه.
2. تنتقل الآن إلى صفحة المستودع حيث تتصف الملفات الخاصة به، لكن هدفنا الأساسي هو الحصول على رابط الاستنتساخ، فانقر على زر Code الأزرق الكبير.

لننسخه الآن من GitHub إلى الحاسوب المحلي، سيختلف هذا إذا كنت تستخدم GitHub CLI أو مفاتيح SSH، لكن سنشرح الطريقتين.

الاستنتساخ من GitHub باستخدام CLI

لدينا خياران هنا:

الخيار الأول: أشرنا سابقًا إلى تذكر أننا سنستخدم بروتوكول SSH عندما أثبتنا هويتنا باستخدام gh auth login، وعليه سنختار التبويب الموافق لذلك في هذه النافذة، لكن إذا اخترت HTTPS فستختار تبويبها. انسخ الرابط واذهب إلى سطر الأوامر ونفذ الأمر:

 git clone [url]

حيث تضع الرابط الذي نسخته بدلًا من الأقواس، فمثلًا سيكون هكذا في حالة HTTPS:

$ git clone https://github.com/user/test-repo.git

وهذه في حالة SSH:

$ git clone git@github.com:user/test-repo.git

الخيار الثاني: اختر تبويب GitHub CLI من القائمة المنسدلة ثم نفذ الأمر كما هو مكتوب هناك تمامًا، سيكون شبيها بالسطر التالي:

$ gh repo clone user/test-repo

الاستنساخ من GitHub باستخدام مفاتيح SSH

نستخدم هذه الطريقة إذا كنا أعددنا مفتاح SSH من قبل:

1. تأكد من اختيار تبويب SSH بعد النقر على زر Code الأخضر.
2. انسخ هذا الرابط.
3. انتقل إلى سطر الأوامر ونفذ الأمر git clone [URL] حيث تضع الرابط الذي نسخته بدلًا من الأقواس بحيث يكون كالتالي:

$ git clone git@github.com:user/test-repo.git

إجراء التعديلات ودفع الملفات إلى المستودع البعيد

ننتقل الآن إلى مجلد المستودع بعد استنساخه باستخدام الأمر git clone، ثم ندخل إليه باستخدام الأمر

cd اسم المجلد

ونعدّل أحد الملفات، وبعد ذلك نضيفه إلى منطقة التحضير stage باستخدام:

git add اسم الملف

ثم ننفذ عملية إيداع باستخدام:

git commit -m "message"

وأخيرًا لدفعه إلى النسخة البعيدة على GitHub مرة أخرى:

git push

يجب أن نرى هذه التغييرات الآن إذا عدنا إلى صفحة المستودع على GitHub وأعدنا تحميل الصفحة.

هذا يعيدنا إلى مسار العمل الشائع على نظام Git:

1. استنساخ مستودع بعيد
2. إجراء بعض التعديلات على النسخة المحلية.
3. إضافة التغييرات إلى منطقة التحضير.
4. تسجيل هذه التغييرات وإيداعها من خلال عملية commit.
5. دفع هذه التغييرات إلى المستودع البعيد.
6. العودة مرة أخرى إلى الخطوة رقم 2.

التعاون في GitHub

توجد طريقتان أساسيتان للتعاون في موقع GitHub هما:

1. الاشتقاق وطلب السحب Fork/Pull Request.
2. إضافة مساهم collaborator.

الطريقة الأسهل منهما هي إضافة المساهمين مباشرة إلى مستودعك، اتبع الخطوات التالية:

1. اختر الإعدادات Settings.
2. اختر collaborators من القائمة الجانبية اليسرى.
3. أكد هويتك ثم انقر على زر Add people.
4. أدخل اسم المستخدم للشخص الذي تريد التعاون معه.

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

خاتمة

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

اقرأ أيضًا

• إنشاء طلب سحب على GitHub
• أساسيات نظام Git للتحكم في الإصدارات البرمجية

ترجمة -بتصرف- للفصل الثاني من دليل Beej إلى Git لصاحبه Brian “Beej Jorgensen” Hall

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

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

الفئة المستهدفة

يستهدف برايان "بيج جورجينسن" هول Brian “Beej Jorgensen” Hall -مؤلف الدليل- طلاب الجامعة بشكل رئيسي لكن أسلوب الشرح مصمم بحيث يستطيع غيرهم من المبتدئين في البرمجة أن يستفيدوا منه أيضًا، وإن كنا نفترض معرفتك بكيفية التعامل مع سطر الأوامر في طرفيات POSIX مثل Bash أو Zsh وغيرهما، أي تعرف الأوامر الأساسية مثل cd, ls, mkdir, cp وغيرها، وكذلك تثبيت البرامج التي نتعرض لها أثناء الشرح.

ننصح باستخدام أحد أنظمة لينكس في تعلمك لنظام Git ورحلتك البرمجية عمومًا لأنها تُعد أنظمة شبيهة بيونكس UNIX LIKE من حيث موافقتها لمعايير POSIX لنظم التشغيل من ناحية، وجاهزيتها للأدوات والمكتبات البرمجية من ناحية أخرى، أو استخدام أنظمة أخرى شبيهة بيونكس مثل FreeBSD أو ماك، لكن إن كنت تستخدم ويندوز فإن نظام Git يأتي مع طرفية تسمى Git Bash، كما تستطيع تثبيت WSL.

ما هو نظام Git

يوصف Git بأنه نظام للتحكم في الشيفرات المصدرية Source code أو الإصدارات البرمجية حيث يحتفظ بسجل من اللقطات snapshots لملفات المشروع بحيث تمثل كل لقطة منها حالة جميع الملفات التي يتتبعها النظام في لحظة زمنية ما، فتستطيع بهذا أن تعود إلى نقطة زمنية معينة أثناء العمل على المشروع لتعاينها.

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

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

اصطلاحات

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

المستودع Repo/Repository: هو المكان الذي يُحفظ فيه مشروع برمجي ما داخل Git، ويكون لكل مشروع في العادة مستودع خاص، فقد تنشئ مستودعًا من أجل مشروع جديد تعمل عليه، ويكون إما موجودًا على حاسوبك الشخصي أو على حواسيب بعيدة.

المستودع البعيد Remote Repo: هو نسخة من مستودع في مكان غير حاسوبك المحلي.

الاستنساخ Clone: أن تنشئ نسخة محلية على حاسوبك من مستودع بعيد remote repo، وتسمى هذه النسخة نفسها clone أيضًا.

شجرة العمل Working Tree: الدليل أو المجلد الذي تعدل فيه ملفات المشروع، تُنشأ هذه الشجرة عند إنشاء نسخة clone من المستودع.

منطقة التحضير Stage: هي المكان الذي تضيف فيه الملفات التي تريد تحضيرها لعملية الإيداع commit، فإذا عدلت بعض الملفات لكن لم تضفها هنا أولًا فلن تشملها عملية الإيداع.

الفهرس Index: اسم آخر أقل شيوعًا لمنطقة التحضير.

الإيداع Commit: هو لقطة لحالة المشروع في لحظة معينة، تتضمن التعديلات التي أُضيفت إلى منطقة التحضير، ويُستخدم لتوثيق التغييرات وتتبعها عبر الزمن.

أمثلة على رسائل الإيداع:

• إضافة الميزة س إلى القاعدة البرمجية
• إصلاح خطأ ص
• دمج تغييرات مساهمين آخرين في الشيفرة

ما هو GitHub

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

اقتباس

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

سيكون لديك أيضًا نسخ من المستودعات المخزنة محليًا على حاسوبك لتعمل عليها تعرف باسم Clones، مستقلة عن المستودعات الموجودة على GitHub، ثم تزامن أنت هذه النسخ من حاسوبك مع GitHub دوريًا أثناء مسار عملك المعتاد.

مسار عمل بسيط في Git

يوجد عدة مسارات عمل قد تتبعها أثناء عملك مع Git، منها ما يكثر استخدامه ومنها الذي قد لا تستخدمه إلا نادرًا، فيما يلي أحد المسارات الشائعة:

1. الاستنساخ clone: في البداية تنسخ مستودعًا بعيدًا، أي ليس محفوظًا على حاسوبك المحلي، يكون في العادة على GitHub.
2. مرحلة التعديل: تنفذ بعض التغييرات في شجرة العمل working tree، وهي المكان الذي توجد فيه ملفات المشروع على جهازك.
3. الإضافة إلى الفهرس: تضيف بعدها تلك التغييرات إلى منطقة التحضير stage، والتي تعرف أيضًا بالفهرس Index.
4. الإيداع Commit: تودع هذه التغييرات لتسجيلها كلقطة snapshot.
5. مرحلة الدفع Push: ادفع اللقطة التي سجلتها لنقلها إلى المستودع البعيد.
6. عد إلى الخطوة رقم 2 وكرر المسار.

ما هو الاستنساخ

اقتباس

نظام التحكم الموزَّع في الإصدارات Distributed version control system

هو نظام تتواجد فيه نسخ متعددة clones من المستودعات ولا توجد فيه سلطة مركزية للبيانات، فحين تنسخ مستودعًا يكون لديك نسختين منه، واحدة بعيدة remote، وأخرى على حاسوبك المحلي، وهي نسخ مستقلة بذاتها بمعنى أن التعديلات التي تجريها في نسختك المحلية لا تؤثر في النسخة البعيدة إلا إذا رغبت أن تتفاعل النسختين مع بعضهما البعض وربطتهما بنفسك.

يُعد Git في ضوء هذا التعريف نظام تحكم موزع في الإصدارات، هذا يعني أنه لا توجد سلطة واحدة مركزية للبيانات على عكس الأنظمة الأخرى للتحكم في الإصدارات، مع أن مستخدمي Git يعاملون GitHub على أنه نظام موزع كذلك.

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

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

كيف تتفاعل النسخ مع بعضها

هناك عمليتان رئيسيتان نستخدمهما بعد إنشاء نسخة ما:

• الدفع Push: تأخذ عملية الدفع اللقطات التي أودعتها على حاسوبك المحلي وترفعها إلى المستودع البعيد.
• السحب Pull: بالعكس، تأخذ عملية السحب اللقطات الموجودة في المستودع البعيد وتنزلها إلى حاسوبك المحلي.

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

الاستخدام الفعلي لنظام Git

يفترض هذا القسم أن أدوات سطر أوامر Git مثبتة لديك وأنك ستستخدم إحدى طرفيات يونكس مثل Bash أو Zsh.

اقتباس

من أين تحصل على هذه الطرفيات؟

إذا كنت تستخدم أحد الأنظمة الشبيهة بنظام يونكس، مثل لينكس أو BSD أو يونكس أو ماك فهي تأتي مع النظام، أما في حالة ويندوز فننصح بتثبيت نظام ويندوز الفرعي للينكس، أو استخدام طرفية Git Bash التي تأتي مع نظام Git.

سنفترض في حالتنا هنا أن لدينا مستودعًا في GitHub ونريد نسخه، وعليه سنمر بالخطوات التي ذكرناها قبل قليل، لكن سنضيف إليها خطوة جديدة تسبقها:

الخطوة 0: إعداد بياناتك لأول مرة

يجب أن تخبر النظام باسمك وبريدك الإلكتروني في أول مرة تستخدمه لأنها ستُضاف إلى كل اللقطات التي تودعها في المستودع، ويمكن تغيير هذه البيانات في أي وقت لاحقًا أو تخصيص تلك البيانات لتكون مختلفة لكل مستودع، أما لغرض هذا المثال فسنختار اسمك وعنوان البريد كبيانات عامة لنظام Git، أدخل كليهما في سطر الأوامر لضبط اسمك وبريدك الإلكتروني.

$ git config set --global user.name "اسمك"
$ git config set --global user.email "بريدك الإلكتروني"

اقتباس

إذا أردت تغيير الاسم أو عنوان البريد لاحقًا فكرر الأمرين في المثال السابق.

لا تنسخ المحث $ في المثال أعلاه فهو يتغير وفقًا للطرفية التي تستخدمها، فقد يكون $ أو # أو %، ونحن نضيفه في هذه الأمثلة ليدل على أن السطر الذي بعده يُكتب في الطرفية أو سطر الأوامر.

أخيرًا، نحدد اسم الفرع الافتراضي default branch ليكون main من خلال الأمر التالي:

$ git config set --global init.defaultBranch main

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

لكن اسم main ليس إجباريًا بل تستطيع اختيار ما شئت، حيث تسمى بعض المستودعات master مثلًا للفرع الرئيسي أو main و trunk و development، وكلها من الأسماء الشائعة للفروع الرئيسية للمستودعات.

الخطوة 1: استنساخ مستودع

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

$ git clone https://github.com/beejjorgensen/git-example-repo.git

ستلاحظ ظهور مخرجات مثل هذه:

Cloning into 'git-example-repo'...
remote: Enumerating objects: 10, done.
remote: Counting objects: 100% (10/10), done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 10 (delta 2), reused 9 (delta 1), pack-reused 0
remote: (from 0)
Receiving objects: 100% (10/10), done.
Resolving deltas: 100% (2/2), done.

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

$ cd git-example-repo
$ ls -la

ستظهر الملفات التي يحتوي عليها المستودع كما يلي:

os@machine:~$ cd git-example-repo
os@machine:~/git-example-repo$ ls -la
total 20
drwxr-xr-x  3 os os 4096 فبر 23 17:29 .
drwxr-xr-x 22 os os 4096 فبر 24 00:09 ..
drwxr-xr-x  8 os os 4096 فبر 24 00:01 .git
-rwxr-xr-x  1 os os  175 فبر 24 00:09 hello.py
-rw-r--r--  1 os os  162 فبر 23 17:29 README.md

نلاحظ في خرج الأمر أعلاه أن المستودع يحتوي على الملفين hello.py و README.md إضافة إلى المجلد ‎.git الذي يخزن فيه نظام Git جميع البيانات الوصفية meta data والإيداعات commits الخاصة بالمشروع، وينبغي تجنب العبث بملفات هذا المجلد أو تعديلها لأن وجوده هو ما يمنح المجلد الرئيسي صفة "مستودع Git". نستخدم الأمر status لمعرفة حالة المستودع المحلي كما يلي:

$ git status

فتظهر لنا النتيجة التالية:

On branch main
Your branch is up to date with 'origin/main'.
nothing to commit, working tree clean

تخبرنا هذه النتيجة معلومات كثيرة عن حالة المستودع الراهنة، حيث نعرف منها ما يلي:

• يخبرنا السطر الأول أننا الآن في الفرع الرئيسي main.
• في السطر الثاني نعرف أن الفرع المحلي main متطابق ومحدّث مع النسخة البعيدة منه origin/main، أي لا يوجد أي اختلاف بينهما. لاحظ أن الفرع في نظام Git يمثل مرجعًا يشير إلى إيداع محدد، تمامًا كورقة ملاحظات توضع على هذه اللقطة من الشيفرة، وتمثل هذه اللقطة بدورها صورة لحالة الشيفرة في وقت معين.

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

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

الخطوة الثانية: إجراء تعديلات على المستودع المحلي

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

$ code .

لنعدّل الآن في ملف hello.py الذي كانت بياناته الأصلية كما يلي:

#!/usr/bin/env python

print("Hello World!")
print("This is my program!")

أضف الآن سطرًا يمثل تعديلًا جديدًا:

#!/usr/bin/env python

print("Hello World!")
print("This is my program!")
print("And this is my modification!")

احفظ الآن هذا الملف، ولنسأل Git عن الحالة الجديدة للمستودع عن طريق الأمر status:

$ git status

في النتيجة هذه المرة سنحصل على:
  

On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working
  directory)
  modified:   hello.py

 no changes added to commit (use "git add" and/or "git commit -a")

نرى من هذه الحالة الجديدة الآن ما يلي:

اكتشف Git أننا عدلنا على ملف hello.py تحديدًا لكنه يقول أيضًا no changes added to commit ، وهذا يعني أننا لم نضف الملف المعدل إلى منطقة التحضير stage التي نضع فيها العناصر التي نريد إرسالها في عملية الإيداع، لكن نريد مراجعة التغييرات أولًا قبل إرسالها، وهو ما سنفعله الآن باستخدام أداة git diff.

ترينا هذه الأداة -التي هي اختصار لكلمة difference- التفاصيل التي تغيرت في الملفات لكن مخرجاتها قد تكون غامضة بعض الشيء، انظر المثال التالي:

$ git diff

 diff --git a/hello.py b/hello.py
  index 9db78d2..1187d32 100755
  --- a/hello.py
  +++ b/hello.py
  @@ -2,3 +2,4 @@

   print("Hello, world!")
   print("This is my program!")
  +print("And this is my modification!")

ملخص ما تريد الاطلاع عليه هو ما يلي:

1. اسم الملف: حيث نرى أن التعديل جرى على الملف hello.py.
2. السطر الذي يبدأ بعلامة + وهو الذي أضفناه.

أما علامة - إذا جاءت في بداية السطر فهي تشير أن السطر قد حُذف، ورغم أننا لم نحذف السطر كله بل عدلناه فقط إلا أن نظام Git يظهر الأسطر المعدلة كأنها محذوفة ثم أضيفت كأسطر جديدة. 

الخطوة 3: إضافة التعديلات إلى منطقة التحضير

no changes added to commit (use "git add" and/or "git commit -a")

في هذه المرحلة لم نقم بعد بإضافة التعديلات إلى منطقة التحضير، لذلك يخبرنا Git بعدم وجود تغييرات جاهزة للإيداع، ونحن نعلم أننا عدلنا الملف hello.py ونريد أن ننفذ عملية إيداع تجسد تلك التعديلات الجديدة لذا سنضيف الملف أولًا إلى منطقة التحضير باستخدام git add:

os@machine:~/git-example-repo$ git add hello.py
os@machine:~/git-example-repo$ git status
On branch main
Your branch is up to date with 'origin/main'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   hello.py

لقد تغيرت الرسالة الآن من Changes not staged for commit إلى Changes to be committed، وهذا يعني أننا نجحنا في نسخ الملف hello.py إلى منطقة التحضير.

نرى رسالة أخرى في السطر قبل الأخير حول كيفية إلغاء تحضير الملف، فإذا فرضنا أننا أضفناه دون قصد ونريد حذفه منها وعدم تضمينه في الإيداع الذي سنرسله، فما علينا إلا تنفيذ الأمر التالي:

$ git restore --staged hello.py

وسيعود الملف إلى مرحلة Changes not staged for commit.

الخطوة 4: إيداع التعديلات

نستطيع الآن تنفيذ عملية إيداع commit بما أننا نسخنا الملف إلى منطقة التحضير، ونعيد التذكير هنا أن هذا الإيداع يمثل لقطة snapshot لحالة المستودع بناء على الملفات المعدلة الموجودة في منطقة التحضير فقط -إضافةً إلى الملفات التي لم نعدلها-، أما الملفات التي عدلناها ثم لم نضفها إلى منطقة التحضير فلا تدخل في عملية الإيداع. هذا يعني أن عملية الإيداع تمثل حالة كاملة للمشروع، حيث تتضمن التعديلات التي أُضيفت إلى منطقة التحضير، بينما تبقى الملفات غير المعدلة كما هي من الإيداع السابق دون تغيير.

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

$ git commit -m "Add another print line"
[main a3c7285] Add another print line
   1 file changed, 1 insertion(+)

يسمح الخيار ‎-m بتحديد رسالة الإيداع مباشرة -التي بين علامات التنصيص- أما إذا لم نضفها فسيفتح Git محرر نصي لتعديل رسالة الإيداع، وإذا فتحت هذا المحرر فاعلم أن كل رسالة إيداع تبدأ بعلامة # هي تعليق يتجاهله Git عند تسجيل اللقطة، لنتحقق مرة أخرى من حالة المستودع:

$ git status
On branch main
Your branch is ahead of 'origin/main' by 1 commit.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

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

فمثلًا، نستطيع إيداع ملف وليكن foo.txt دون إضافته إلى منطقة التحضير عن طريق ما يلي:

$ git commit -m "jerbify the flurblux" foo.txt

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

إذا عدنا إلى مخرجات status مرة أخرى سنرى أننا متقدمون على origin/main بعملية إيداع واحدة أو لقطة واحدة، وهذا يعني أن سجل الإيداع المحلي على فرع main يحتوي على لقطة ليست في سجل main الخاص بالمستودع البعيد، وهذا منطقي نظرًا لأن المستودع البعيد يمثل نسخة مستقلة تمامًا عن النسخة المحلية التي على حاسوبنا، ولا تتأثر به إلا إذا حاولنا عمدًا أن نزامن النسختين، أما عدا هذا فلن يعرف المستودع البعيد أننا أجرينا تعديلات محلية.

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

الخطوة 5: رفع التعديلات إلى المستودع البعيد

ننفذ الأمر git push لنرفع تعديلاتنا المحلية إلى المستودع البعيد:

$ git push

تظهر لنا النتيجة التالية:

Username for 'https://github.com':

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

Username for 'https://github.com': my_username
Password for 'https://beejjorgensen@github.com': [my_password]
remote: Support for password authentication was removed on August
        13, 2021.
remote: Please see https://docs.github.com/en/get-started/getting-
        started-with-git/about-remote-repositories#cloning-with-
        https-urls for information on currently recommended modes
        of authentication.
fatal: Authentication failed for 'https://github.com/beejjorgensen/
       git-example-repo.git/'

تظهر رسالة الفشل fatal: Authentication failed لعدة أسباب:

• أولًا: لا تملك تصريحًا بالكتابة أو التعديل في هذا المستودع لأنك لست صاحبه.
• ثانيًا: توقف دعم المصادقة بكلمات المرور التقليدية منذ 2021.

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

خاتمة

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

اقرأ أيضًا

• الدليل المرجعي للعمل على نظام غيت Git
• ما هو Git؟
• كيفية استعادة إصدارات الملفات القديمة في جيت Git

ترجمة -بتصرف- للفصل الثاني من دليل استخدام Git لصاحبه Brian “Beej Jorgensen” Hall

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

تعريف اختبار البرامج

اختبار البرامج Software testing هو تقييم التطبيقات البرمجية التي نطورها من حيث الأداء والوظائف التي تؤديها لنتأكد من استيفاء هذه البرامج للمتطلبات المستهدفة منها وأنها تخلو من الأخطاء والعيوب، وتُختبر البرامج إما آليًا أو يدويًا.

ويقسَّم اختبار البرامج من منظور آخر إلى اختبار وظيفي Functional testing واختبار غير وظيفي Non-Functional testing، حيث تقيس الاختبارات الوظيفية أداء الوظائف الأساسية المطلوبة من النظام مثل التحقق من معالجة البيانات المدخلة بشكل صحيح بينما يقيس الاختبار غير الوظيفي مزايا وصفية وليست وظيفية للنظام، مثل اختبار الأداء Performance testing أو اختبار قابلية الاستخدام Usability أو اختبار سهولة الوصول Accessibility.

متطلبات العمل

• تنزيل محرر أكواد مناسب مثل VS Code

• تثبيت إضافة BLACKBOXAI في VSCode

• تثبيت مكتبات بايثون التالية fastapi و uvicorn و locust باستخدام الطرفية:

pip install fastapi uvicorn locust

مستويات اختبار البرامج Software testing levels

ذكرنا أول المقال أننا نختبر البرامج لنضمن عملها وأداءها لوظائفها، وأدنى هذه المستويات هو اختبار الوحدة unit test، ثم اختبار التكامل Integration test الذي يقيس توافقية الوحدات البرمجية المختلفة مع بعضها البعض عند دمجها، يلي هذا اختبار النظام بشكل شامل System testing، ثم اختبارات القبول في المستوى النهائي التي ينفذها المستخدم حيث يختبر الوظائف المطلوبة بشكل كامل ليقيس جاهزيتها للتسليم.

اختبار الوحدات البرمجية unit test

يمثل اختبار الوحدات البرمجية أدنى مستوى من اختبار البرامج حيث يفحص أصغر الأجزاء القابلة للتنفيذ في الشيفرة مثل الدوال البرمجية Functions أو الأصناف classes أو التوابع methods، ويتم هذا الاختبار في بيئة معزولة عن باقي مكونات النظام أو أي أنظمة خارجية مثل قواعد البيانات أو واجهات التطبيقات البرمجية APIs لأن المشكلات التي قد تحدث في هذا المستوى ستؤثر على غيره، فإذا كنا نصمم برنامج آلة حاسبة سنحتاج للتأكد من عمل كل وظيفة بشكل مستقل، فنختبر دالتي الجمع والطرح وغيرها من الدوال الوظيفية اختبارات مستقلة لنضمن سلاسة وسلامة الانتقال للمستوي التالي الذي يدمج عدة عمليات رياضية معًا.

اختبار تحويل الأموال في نظام بنكي

لنفرض أن لدينا نظام بنكي فيه صنف class اسمه BankAccount مسؤول عن إنشاء كائنات حسابات بنكية، ويحتوي تابع method باسم transfer مسؤول عن تحويل الأموال من حساب لآخر.

class BankAccount:
    def __init__(self, balance: float):
        self.balance = balance

    # دالة لإيداع الأموال
    def transfer(self, target_account, amount: float):
        # التحقق من أن الحساب ليس مديونًا أو مفلسًا
        if amount <= 0:
            raise ValueError("ينبغي أن يكون المبلغ أكبر من الصفر.")
        # التحقق من أن الرصيد كافي
        if self.balance < amount:
            raise ValueError("الرصيد غير كافي")

        # خصم المبلغ من الحساب المرسل
        self.balance -= amount
        # إيداع المبلغ في الحساب المستهدف
        target_account.balance += amount

نختبر الآن دالة تحويل الأموال في معزل عن باقي النظام باستخدام أداة BlackBox AI، من خلال توليد حالات اختبار مناسبة باستخدام مكتبة pytest لأنها من أبسط المكتبات المتاحة في لغة بايثون لتنفيذ اختبار على مستوى الوحدة، وبما أننا ثبتنا إضافة BlackBox AI في محرر Vscode فستكون موجودة في القائمة الجانبية في يسار المحرر، ونخبرها أن تنشئ ملف اختبار لوظيفة تحويل الأموال بين الحسابات البنكية كما يلي:

> create a test file in python using pytest library to test the method of transfer in BankAccount class @/BankAccount.py

نلاحظ أن BlackBoxAI وضعت خطة لتنفيذ الطلب ثم أنشأت ملف test_BanckAccount.py وتطلب مصادقتنا على التغييرات المقترحة والتي يمكن تصفحها قبل الموافقة عليها أو رفضها.

بالنظر في ملف test_BanckAccount.py سنجد أن الأداة قد ولدت الشيفرة التالية:

import pytest
from BankAccount import BankAccount

def test_transfer_successful_transfer():
    account1 = BankAccount(100)
    account2 = BankAccount(50)
    account1.transfer(account2, 50)
    assert account1.balance == 50
    assert account2.balance == 100

def test_transfer_with_zero_amount():
    account1 = BankAccount(100)
    account2 = BankAccount(50)
    with pytest.raises(ValueError, match="ينبغي أن يكون المبلغ أكبر من الصفر."):
        account1.transfer(account2, 0)

def test_transfer_with_negative_amount():
    account1 = BankAccount(100)
    account2 = BankAccount(50)
    with pytest.raises(ValueError, match="ينبغي أن يكون المبلغ أكبر من الصفر."):
        account1.transfer(account2, -10)

def test_transfer_with_insufficient_balance():
    account1 = BankAccount(50)
    account2 = BankAccount(100)
    with pytest.raises(ValueError, match="الرصيد غير كافي"):
        account1.transfer(account2, 100)

نشغل هذا الملف الاختباري بالأمر التالي في سطر الأوامر Terminal

pytest test_BankAccount.py

ونحصل على الخرج التالي:

===========================
platform win32 -- Python 3.9.12, pytest-7.1.1, pluggy-1.0.0
rootdir: F:\AI_tools\Article_4
plugins: anyio-3.5.0
collected 4 items

test_BankAccount.py ....
============================= 4 passed in 0.21s =====================[100%]

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

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

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

> I want to test edge cases to ensure all transactions are atomic, especially when a transaction fails. Specifically, I need to verify that the balance remains unchanged if the sending or receiving process fails, using pytest.

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

import pytest
from BankAccount import BankAccount

def test_transfer_successful_transfer():
    account1 = BankAccount(100)
    account2 = BankAccount(50)
    account1.transfer(account2, 50)
    assert account1.balance == 50
    assert account2.balance == 100

def test_transfer_with_zero_amount():
    account1 = BankAccount(100)
    account2 = BankAccount(50)
    with pytest.raises(ValueError, match="ينبغي أن يكون المبلغ أكبر من الصفر"):
        account1.transfer(account2, 0)

def test_transfer_with_negative_amount():
    account1 = BankAccount(100)
    account2 = BankAccount(50)
    with pytest.raises(ValueError, match="ينبغي أن يكون المبلغ أكبر من الصفر"):
        account1.transfer(account2, -10)

def test_transfer_with_insufficient_balance():
    account1 = BankAccount(50)
    account2 = BankAccount(100)
    with pytest.raises(ValueError, match="الرصيد غير كافي"):
        account1.transfer(account2, 100)

def test_transfer_mid_transaction_failure():
    """
    محاكاة فشل العملية بعد خصم المبلغ وقبل إيداعه.
    السلوك المتوقع: يجب ألا يفقد المرسل المال إذا فشلت العملية.
    """
    account1 = BankAccount(100)
    account2 = BankAccount(50)

    # إنشاء حساب يحتوي على خطأ محتمل عند محاولة إعادة تعيين الرصيد
    class ProblematicAccount:
        def __init__(self, balance):
            self.balance = balance

        # الحصول على الرصيد بشكل آمن
        # getter
        @property
        def balance(self):
            return self._balance

        # تعيين الرصيد بشكل آمن
        # setter
        @balance.setter
        def balance(self, value):
            if hasattr(self, '_balance'):  # إن كانت القيمة معرفة مسبقًا
                raise RuntimeError("Unexpected failure before deposit!")
            self._balance = value

    problem_account = ProblematicAccount(50)

    # اختبار نقل الأموال
    with pytest.raises(RuntimeError, match="Unexpected failure before deposit!"):
        account1.transfer(problem_account, 30)

    # التحقق من عدم فقدان المرسل للمال بشكل غير متوقع
    assert account1.balance == 100, "Sender lost money unexpectedly!"
    assert problem_account.balance == 50, "Receiver should not gain money!"

ينبغي أن نحصل على الخرج التالي بتشغيل تلك الشيفرة:

=========================== short test summary info ========================
FAILED test_BankAccount.py::test_transfer_mid_transaction_failure - AssertionError: Sender lost money unexpectedly!
================ 1 failed, 4 passed in 0.14s =================================

ندرك بهذا أن الدالة transfer تحتاج للتعديل لتتمكن من التعامل مع حالات الفشل غير المتوقعة، خاصة تحقيق مبدأ الذرية Atomic الذي ينص على أن العملية ينبغي أن تنجح بالكامل أو تفشل بالكامل، ونحقق ذلك بتطبيق آلية للتراجع في حالة حدوث خطأ غير متوقع، انظر الموجه التالي.

> Given that failure on the atomicity test case (test_transfer_mid_transaction_failure) ,fix the  BankAccount.py transfer method.

ينبغي أن نحصل على الشيفرة المعدلة لملف BankAccount.py

class BankAccount:
    def __init__(self, balance: float):
        self.balance = balance

    def transfer(self, target_account, amount: float):
        # التحقق من أن الحساب ليس مديونًا أو مفلسًا
        if amount <= 0:
            raise ValueError("ينبغي أن يكون المبلغ أكبر من الصفر.")
        # التحقق من أن الرصيد كافي
        if self.balance < amount:
            raise ValueError("الرصيد غير كافي")

        # حفظ الرصيد الحالي في حالة حدوث خطأ
        original_balance = self.balance

        try:
            # خصم المبلغ من الحساب المرسل
            self.balance -= amount
            # إيداع المبلغ في الحساب المستهدف
            target_account.balance += amount
        except Exception as e:
            # استعادة الرصيد الأصلي في حالة حدوث خطأ
            self.balance = original_balance
            # إعادة رفع الاستثناء
            raise e

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

================================ test session starts ==============
platform win32 -- Python 3.9.12, pytest-7.1.1, pluggy-1.0.0
rootdir: F:\Article_4
plugins: anyio-3.5.0
collected 5 items

test_BankAccount.py .....                                                                                                 [100%]
====================== 5 passed in 0.03s=========================

اختبار الانحدار

اختبار الانحدار Regression test هو نوع من اختبارات البرامج Software testing يستخدم لضمان أن تحديث الشيفرة لا يضر بأي وظيفة كانت تعمل سابقًا، وينفذ عادة بعد تطوير وظائف جديدة أو إصلاح أحد الأخطاء البرمجية، فإذا أردنا إضافة ميزة جديدة للنظام البنكي مثل فرض رسوم على التحويلات، سنطور هذه الميزة ونختبرها لنتأكد من أنها لم تُحدث انحدارًا في التطبيق الموجود، أي ينبغي أن تظل كل المزايا الأخرى وحالات الاختبار تعمل بكفاءة.

class BankAccount:
    def __init__(self, balance: float, fee_percentage: float = 0):
        self.balance = balance
        self.fee_percentage = fee_percentage

    def transfer(self, target_account, amount: float):
        # التحقق من أن الحساب ليس مديونًا أو مفلسًا
        if amount <= 0:
            raise ValueError("ينبغي أن يكون المبلغ أكبر من الصفر.")
        # حساب الرسوم المفروضة
        fee = self.get_fee_amount(amount)
        total_amount = amount + fee

        # التحقق من أن الرصيد كافي
        # مضيفين الرسوم إلى تكلفة التحويل
        if self.balance < total_amount:
            raise ValueError("الرصيد غير كافي")

        # حفظ الرصيد الحالي في حالة حدوث خطأ
        original_balance = self.balance

        try:
            # خصم المبلغ من الحساب المرسل
            self.balance -= total_amount
            # إيداع المبلغ في الحساب المستهدف
            # لا نودع إلا المبلغ المرسل فقد بدون الرسوم
            target_account.balance += amount
        except Exception as e:
            # استعادة الرصيد الأصلي في حالة حدوث خطأ
            self.balance = original_balance
            # إعادة رفع الاستثناء
            raise e
    def get_fee_amount(self, transfer_amount: float):
        """حساب مبلغ الرسوم لتحويل معين"""
        return transfer_amount * self.fee_percentage / 100

نحتاج لاختبار الميزة الجديدة لنتأكد من عمل الوظائف السابقة أولًا، حيث نختبر الحالة التي تكون الرسوم فيها 0% ثم اختبار التحويل حين تكون الرسوم أكبر من الصفر -2% مثلًا-، ونوجه BlackBoxAI حينئذ لتوليد ملف يختبر عمل الوظائف السابقة بالإضافة لاختبار الحالات الجديدة. لنستخدم الموجه التالي:

> Create a regression test for the newly implemented fee feature on money transfers. Ensure the test verifies that the new functionality works as expected, while also confirming that existing features remain unaffected.

ينبغي أن نحصل على ملف اختبار يكون كما يلي:

import pytest
from BankAccount import BankAccount

# ---------- اختبارات الانحدار (Regression Tests) ----------
# هذه هي الاختبارات الموجودة مسبقًا للتأكد من أن الوظائف الأساسية ما زالت تعمل

def test_transfer_successful_transfer():
    account1 = BankAccount(100)
    account2 = BankAccount(50)
    account1.transfer(account2, 50)
    assert account1.balance == 50
    assert account2.balance == 100

def test_transfer_with_zero_amount():
    account1 = BankAccount(100)
    account2 = BankAccount(50)
    with pytest.raises(ValueError, match="ينبغي أن يكون المبلغ أكبر من الصفر."):
        account1.transfer(account2, 0)

def test_transfer_with_negative_amount():
    account1 = BankAccount(100)
    account2 = BankAccount(50)
    with pytest.raises(ValueError, match="ينبغي أن يكون المبلغ أكبر من الصفر"):
        account1.transfer(account2, -10)

def test_transfer_with_insufficient_balance():
    account1 = BankAccount(50)
    account2 = BankAccount(100)
    with pytest.raises(ValueError, match="الرصيد غير كافي"):
        account1.transfer(account2, 100)

def test_transfer_mid_transaction_failure():
    """
    محاكاة فشل العملية بعد خصم المبلغ وقبل إيداعه.
    السلوك المتوقع: يجب ألا يفقد المرسل المال إذا فشلت العملية.
    """
    account1 = BankAccount(100)

    # إنشاء حساب يحتوي على خطأ محتمل عند محاولة إعادة تعيين الرصيد
    class ProblematicAccount:
        def __init__(self, balance):
            self.balance = balance

        # الحصول على الرصيد بشكل آمن
        @property
        def balance(self):
            return self._balance

        # تعيين الرصيد بشكل آمن
        @balance.setter
        def balance(self, value):
            if hasattr(self, '_balance'):  # إن كانت القيمة معرفة مسبقًا
                raise RuntimeError("Unexpected failure before deposit!")
            self._balance = value

    problem_account = ProblematicAccount(50)

    # اختبار نقل الأموال
    with pytest.raises(RuntimeError, match="Unexpected failure before deposit!"):
        account1.transfer(problem_account, 30)

    # التحقق من عدم فقدان المرسل للمال بشكل غير متوقع
    assert account1.balance == 100, "Sender lost money unexpectedly!"
    assert problem_account.balance == 50, "Receiver should not gain money!"

# ---------- اختبارات الميزة الجديدة (New Feature Tests) ----------
# اختبارات للتحقق من ميزة رسوم التحويل الجديدة

def test_transfer_with_fee():
    """اختبار التحويل مع وجود رسوم"""
    # %إنشاء حساب مع رسوم 2
    account1 = BankAccount(100, fee_percentage=2)
    account2 = BankAccount(50)

    # تحويل 50 وحدة مع رسوم 1
    account1.transfer(account2, 50)

    # التحقق من الأرصدة
    assert account1.balance == 49, "Should be 100 - 50 - 1(fee) = 49"
    assert account2.balance == 100, "Should be 50 + 50 = 100"

def test_transfer_with_fee_insufficient_balance():
    """اختبار فشل التحويل عند عدم كفاية الرصيد لتغطية المبلغ والرسوم"""
    # إنشاء حساب مع رسوم %10
    account1 = BankAccount(100, fee_percentage=10)
    account2 = BankAccount(50)

    # محاولة تحويل مبلغ 95 يتطلب مبلغ 9.5 إضافي للرسوم
    with pytest.raises(ValueError, match="الرصيد غير كافي"):
        account1.transfer(account2, 95)

    # التحقق من عدم تغيير الأرصدة
    assert account1.balance == 100
    assert account2.balance == 50

def test_get_fee_amount():
    """اختبار حساب مبلغ الرسوم"""
    account = BankAccount(1000, fee_percentage=2.5)

    fee = account.get_fee_amount(200)
    assert fee == 5, "2.5% of 200 should be 5"

def test_zero_fee_percentage():
    """اختبار أن الحساب يعمل بشكل طبيعي عندما تكون الرسوم صفرًا"""
    account1 = BankAccount(100, fee_percentage=0)
    account2 = BankAccount(50)

    account1.transfer(account2, 50)

    assert account1.balance == 50
    assert account2.balance == 100

بتشغيل ملف الاختبار نجد أنه تجاوز جميع الاختبارات، مما يعني أن الميزة المضافة لم تتسبب في إفساد الميزات الموجودة مسبقًا بالنظام.

اختبارات الأداء

تعد اختبارات الأداء Performance tests أحد الطرق الكمية لقياس المتطلبات غير الوظيفية non-functional requirements مثل قدرة تحمل التطبيق وسرعته في التحميل أو عدد المستخدمين الذين يستطيع التعامل معهم وغيرها من المعايير التي تساعدنا في تحديد حدود الاستخدام المناسبة للتطبيق وتحديد حاجتنا للموارد الحاسوبية من ذاكرة وصول عشوائي RAM أو CPU أو مساحة تخزين.

أنواع اختبارات الأداء Performance test

• اختبار الحمل Load test : يقيس أداء النظام تحت الظروف المتوقعة أو الطبيعية وسرعة الرد واستخدام الموارد

• اختبار الضغط Stress test : يختبر حدود النظام بتعريضه لحمل أكبر من المتوقع أو الطبيعي، لمعرفة مدى استقرار النظام ونقاط الفشل وقدرة النظام على التعافي

• اختبار الحمل المفاجئ Spike test : يختبر أداء النظام تحت حمل عالي ومفاجئ، ويختبر قدرته على التوسع السريع scale up والتعامل مع الضغط المفاجئ

اختبار الحمل في نظام إدارة مخزون

نفترض أن لدينا نظام إدارة مخزون Inventory بسيط يعمل من خلال واجهة تطبيق برمجية API مبنية بمكتبة FastAPI ويرتبط بقاعدة بيانات بسيطة من نوع Sqlite تحفظ العناصر وكميتها في جدول.

import sqlite3
from fastapi import FastAPI

app = FastAPI()

# تهيئة قاعدة البيانات
def init_db():
    conn = sqlite3.connect("inventory.db")
    cursor = conn.cursor()

    # إنشاء جدول البيانات إذا لم يكن موجودًا
    cursor.execute("CREATE TABLE IF NOT EXISTS inventory (id INTEGER PRIMARY KEY, name TEXT, quantity INTEGER)")

    # إضافة بيانات افتراضية إذا كانت الجدول فارغة
    cursor.execute("SELECT COUNT(*) FROM inventory")
    if cursor.fetchone()[0] == 0:
        sample_data = [
            ("Laptop", 10),
            ("Keyboard", 25),
            ("Mouse", 30),
            ("Monitor", 15)
        ]
        cursor.executemany("INSERT INTO inventory (name, quantity) VALUES (?, ?)", sample_data)
        conn.commit()

    conn.close()

init_db()  # تهيئة كائن قاعدة البيانات

# دالة لجلب العناصر الموجودة بالمخزون
@app.get("/inventory")
def get_inventory():
    conn = sqlite3.connect("inventory.db")
    cursor = conn.cursor()
    cursor.execute("SELECT * FROM inventory")
    items = cursor.fetchall()
    conn.close()
    return {"inventory": items}

لتشغيل هذا التطبيق نكتب في الطرفية الأمر التالي :

uvicorn inventory_api:app --reload

بهذا تصبح واجهة التطبيق البرمجية API تعمل وجاهزة للاستخدام من خلال الرابط المحلي http://127.0.0.1:8000/inventory، أو الرابط http://127.0.0.1:8000/docs#/default/get_inventory_inventory_get الذي يسمح لنا بتجربة نقاط النهاية End-points للواجهة البرمجية API باستخدام واجهة صفحة ويب.

نوجه BlackBoxAI بعدها لتوليد ملف اختبار أداء باستخدام مكتبة Locust والتي ستسمح لنا باختبار واجهة التطبيق البرمجية API بمحاكاة استخدام عدد كبيرة من المستخدمين النظام في نفس الوقت وتساعد في تحليل أداء النظام بعرض رسومات بيانية توضح سرعة الرد وعدد مرات الفشل مقارنة بعدد الطلبات التي نفذها النظام بنجاح وغيرها من المزايا الأخرى.

from locust import HttpUser, task, between

class InventoryUser(HttpUser):
    wait_time = between(1, 2)  # كل مستخدم ينتظر بين 1-2 ثانية بين الطلبات

    """ inventory محاكاة أكثر من مستخدم يتصل بنقطة النهاية """

    @task
    def load_test_inventory(self):
        ‫"""مستخدم افتراضي يقوم بطلب رابط inventory بشكل متكرر"""
        response = self.client.get("/inventory")
        if response.status_code != 200:
            response.failure("Failed to fetch inventory")

نشغل الأمر التالي من خلال الطرفية، حيث نمرر اسم الملف والرابط المحلي المؤدي للموقع.

locust -f load_test.py --host=http://127.0.0.1:8000

سنحصل على الرابط التالي http://localhost:8089 لتجربة أداة الاختبار، حيث نجد عند فتح الصفحة بعض المدخلات التي نستطيع التحكم فيها، مثل عدد المستخدمين، وتزايد ذلك العدد في كل ثانية Ramp up حيث أن أداة الاختبار تضيف هذا العدد من المستخدمين كل ثانية حتى تصل لعدد المستخدمين الأقصى بشكل تدريجي، سنضبط عدد المستخدمين ليكون 1000 مستخدم، ومعدل تزايد المستخدمين ليكون 10 في الثانية.

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

يمكننا تعريض النظام لمستوى أعلى من الضغط لنرى نسبة الفشل في إجابة الطلبات، بأن نجعل عدد المستخدمين 100 ألف مثلًا، يزيدون بمعدل 1000 في كل مرة، سيزيد احتمال حدوث الفشل لعجز نظامنا على التعامل مع هذا الكم من الضغط.

وصلت نسبة الفشل إلى 88% حيث فشل 332008 طلب من أصل 377561، وكان متوسط سرعة الإجابة 174 ثانية، وهذا وقت طويل يدل أن النظام لم يستطع تحمل الزيادة في الحمل، كما نرى من الرسومات البيانية الموضحة بالأعلى أن النظام بدأ في التدهور عندما تجاوز عدد المستخدمين 50 ألف تقريبًا، هذه المعلومات تمكننا من تحسين كفاءة النظام تحت الضغط بإجراءات مثل تحجيم عدد الطلبات المسموح للمستخدم إرسالها في فترة زمنية محددة، واستخدام رتل Queue لتخزين الطلبات الفائضة عن سعة النظام لتعالج عندما يستطيع النظام استيعاب المزيد من الطلبات، فبدلًا من محاولة معالجة 100 ألف طلب نستطيع تخزين الطلبات في رتل Queue وندفع الطلبات للنظام على هيئة دفعات كل دفعة تتكون من 10000 طلب فقط.

خاتمة

تعرفنا في هذا المقال على كيفية استغلال قدرات أداة الذكاء الاصطناعي BlackBoxAI لتطبيق مبادئ اختبار البرامج Software testing بأنواعها المختلفة، مثل الاختبارات الوظيفية Functional testing كاختبار الوحدة Unit test واختبار الانحدار Regression test بالإضافة للاختبارات غير الوظيفية Non-functional testing التي تركز على اختبار أداء النظام وسرعة استجابته ونقاط الفشل المحتملة للنظام عن طريق محاكاة ظروف استخدام مختلفة، حيث استطعنا توليد الشيفرة المناسبة من خلال استخدام الموجهات Prompts المناسبة في BlackBoxAI وتحسينه حسب حاجتنا لذلك.

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

اقرأ أيضًا

• أفضل ممارسات هندسة المُوجِّهات Prompt Engineering: نصائح وحيل وأدوات

• اكتشف بدائل ChatGPT مفتوحة المصدر

• كيف ومتى نستخدم SQLite

• مدخل إلى الواجهات البرمجية API

• دمج مساعد الذكاء الاصطناعي GitHub Copilot مع محرر الأكواد VS Code

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

يمكن تقدير مدى بطء هذه العملية بحساب بسيط حيث يمكن ترتيب عدد n من العناصر في أزواج بعدد من الطرق يساوي n(n-1)، وإذا حذفنا الأزواج المكررة -إذا اعتبرنا أن الزوج A-B هو نفسه B-A يكون لدينا عدد من الأزواج الفريدة يساوي n(n-1)/2 أو (n²-n)/2 للتبسيط، وكلما زادت قيمة n تناسبت تقريبيًا مع n2، وهنا قد يقال أن تعقيد الوقت Time complexity لخوارزميتنا هو O(n²). بعبارة أبسط، حين يتضاعف عدد الملفات يزيد زمن التشغيل أربع مرات تقريبًا، أي أن الوقت المستغرق لكل ملف يزيد مع زيادة العدد الإجمالي للملفات.

لا يمكن تجنب هذا النوع من التباطؤ في الغالب، لكن لدينا حل أفضل في مثالنا هنا، حيث سنتمكن تجميع الملفات التي لديها نفس المعرف ثم نقارن بين الملفات داخل كل مجموعة، إذا ولّدنا معرفًا identifier قصيرًا لكل ملف يعتمد على البايتات التي يحتويها، ويُعد هذا الأسلوب أسرع لأننا ننفذ عملية المقارنة المكلفة -مقارنة كل بايت مقابل بايت على حدة- على الملفات التي يُحتمل تطابقها فقط، بل قد نتجنب عملية المقارنة بالكلية إذا أتقنا توليد هذه المعرفات.

الأسلوب التقليدي

سنبدأ بتنفيذ الأسلوب غير الفعال الذي يعتمد على تعقيد الوقت O(N²) لكي نقارنه بالتصميمات المتطورة التي سنكتبها لاحقًا.

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

import sys


# [bytes]
def same_bytes(left_name, right_name):
 left_bytes = open(left_name, "rb").read()
 right_bytes = open(right_name, "rb").read()
 return left_bytes == right_bytes
# [/bytes]


# [main]
def find_duplicates(filenames):
 matches = []
 for left in filenames:
 for right in filenames:
 if same_bytes(left, right):
 matches.append((left, right))
 return matches


if __name__ == "__main__":
 duplicates = find_duplicates(sys.argv[1:])
 for (left, right) in duplicates:
        print(left, right)
# [/main]

يستخدم هذا البرنامج دالة same_bytes تقرأ ملفين وتقارن بينهما "بايت مقابل بايت":

def same_bytes(left_name, right_name):
    left_bytes = open(left_name, "rb").read()
    right_bytes = open(right_name, "rb").read()
    return left_bytes == right_bytes

لاحظ في المثال أعلاه أننا نفتح الملفات في الوضع الثنائي binary mode باستخدام الوسم rb بدلًا من r المعتاد، وهذا يخبر لغة بايثون أن تقرأ البايتات تمامًا كما هي بدلًا من محاولة تحويلها إلى محارف نصية.

ننشئ مجلدًا باسم tests من أجل اختبار هذا البرنامج والبرامج الأخرى، ويحتوي على ستة ملفات:

نتوقع أن يتم الإبلاغ عن ملفات a الثلاثية وملفات b الثنائية كملفات مكررة:

python brute_force_1.py tests/*.txt

ينبغي أن نحصل على الخرج التالي:

tests/a1.txt tests/a1.txt
tests/a1.txt tests/a2.txt
tests/a1.txt tests/a3.txt
tests/a2.txt tests/a1.txt
tests/a2.txt tests/a2.txt
tests/a2.txt tests/a3.txt
tests/a3.txt tests/a1.txt
tests/a3.txt tests/a2.txt
tests/a3.txt tests/a3.txt
tests/b1.txt tests/b1.txt
tests/b1.txt tests/b2.txt
tests/b2.txt tests/b1.txt
tests/b2.txt tests/b2.txt
tests/c1.txt tests/c1.txt

هذا الخرج غير مفيد وإن كان صحيحًا، إذ يبلغ عن كل ملف على أنه مطابق لنفسه، كما يُكرر الإبلاغ مرتين عن كل تطابق بين ملفين مختلفين، لنصلح هذه الحلقة المتداخلة nested loop في دالة find_duplicates كي نتأكد أننا نفحص أزواج الملفات التي يحتمل اختلافها مرة واحدة فقط:

import sys


def same_bytes(left_name, right_name):
    left_bytes = open(left_name, "rb").read()
    right_bytes = open(right_name, "rb").read()
    return left_bytes == right_bytes


# [dup]
def find_duplicates(filenames):
    matches = []
    for i_left in range(len(filenames)):
        left = filenames[i_left]
        for i_right in range(i_left):
            right = filenames[i_right]
            if same_bytes(left, right):
                matches.append((left, right))
    return matches
# [/dup]


if __name__ == "__main__":
    duplicates = find_duplicates(sys.argv[1:])
    for (left, right) in duplicates:
        print(left, right)

تحديد نطاق الحلقة الداخلية لإنتاج تركبيات فريدة.

تجزئة الملفات

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

إذا قُسمت الملفات إلى عدد g من المجموعات فستحتوي كل مجموعة على عدد N/g من الملفات، ويصبح إجمالي العمل المطلوب O(g(N / g²)) - على سبيل المثال: عدد g مجموعة * عدد مقارنات يساوي (N/g²) داخل كل مجموعة-، أي أننا نحصل على (N²/g) مما يعني أن زمن التشغيل الكلي ينخفض بزيادة عدد المجموعات.

تجميع الملفات عبر شيفرة التجزئة يقلص عدد المقارنات من 15 إلى 4 فقط.

نستطيع إنشاء معرفات للملفات باستخدام دالة تجزئة hash function لإنتاج شيفرة تجزئة hash code، وبما أن البايتات في الأصل عبارة عن أرقام فنستطيع إنشاء دالة تجزئة بسيطة عبر جمع قيم البايتات الموجودة في الملف ثم أخذ باقي القسم على رقم معين:

# [hash]
def naive_hash(data):
    return sum(data) % 13
# [/hash]

if __name__ == "__main__":
    # [example]
    example = bytes("hashing", "utf-8")
    for i in range(1, len(example) + 1):
        substring = example[:i]
        hash = naive_hash(substring)
        print(f"{hash:2} {substring}")
    # [/example]

إليك اختبارًا سريعًا يحسب شيفرة التجزئة لأجزاء من كلمة hashing يتزايد طولها:

example = bytes("hashing", "utf-8")
for i in range(1, len(example) + 1):
    substring = example[:i]
    hash = naive_hash(substring)
    print(f"{hash:2} {substring}")

يكون الخرج ما يلي:

0 b'h'
 6 b'ha'
 4 b'has'
 4 b'hash'
 5 b'hashi'
11 b'hashin'
10 b'hashing'

يبدو الخرج عشوائيًا، نريد إجراء اختبار أكثر صرامة عبر تجربة تجزئة كل سطر نصي في رواية دراكولا -نسخة مشروع جوتنبرج-، ثم نرسم مخططًا بيانيًا للتوزيع:

توزيع شيفرات التجزئة لكل سطر في رواية دراكولا.

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

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

توزيع شيفرات التجزئة للأسطر الفريدة في رواية دراكولا.

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

import sys
from naive_hash import naive_hash


def same_bytes(left_name, right_name):
    left_bytes = open(left_name, "rb").read()
    right_bytes = open(right_name, "rb").read()
    return left_bytes == right_bytes


def find_duplicates(filenames):
    matches = []
    for i_left in range(len(filenames)):
        left = filenames[i_left]
        for i_right in range(i_left):
            right = filenames[i_right]
            if same_bytes(left, right):
                matches.append((left, right))
    return matches


# [group]
def find_groups(filenames):
    groups = {}
    for fn in filenames:
        data = open(fn, "rb").read()
        hash_code = naive_hash(data)
        if hash_code not in groups:
            groups[hash_code] = set()
        groups[hash_code].add(fn)
    return groups
# [/group]


if __name__ == "__main__":
    # [main]
    groups = find_groups(sys.argv[1:])
    for filenames in groups.values():
        duplicates = find_duplicates(list(filenames))
        for (left, right) in duplicates:
            print(left, right)
    # [/main]

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

def find_groups(filenames):
    groups = {}
    for fn in filenames:
        data = open(fn, "rb").read()
        hash_code = naive_hash(data)
        if hash_code not in groups:
            groups[hash_code] = set()
        groups[hash_code].add(fn)
    return groups

نستطيع الآن إعادة استخدام معظم الشيفرة التي كتبناها سابقًا للبحث عن التكرارات داخل كل مجموعة على حدة:

groups = find_groups(sys.argv[1:])
for filenames in groups.values():
    duplicates = find_duplicates(list(filenames))
    for (left, right) in duplicates:
        print(left, right)

فيكون الخرج كما يلي:

tests/a2.txt tests/a1.txt
tests/a3.txt tests/a1.txt
tests/a3.txt tests/a2.txt
tests/b1.txt tests/b2.txt

تجزئة أفضل

بالعودة إلى صيغة O(n²/g) التي تخبرنا بمقدار الجهد المطلوب إذا قسمنا n من الملفات على g من المجموعات، فإذا كان لدينا عدد مجموعات يساوي عدد الملفات تمامًا -أي حين تكون n مساوية لـ g- فإن الجهد المطلوب لمعالجة n ملف سيكون O(n²/n) أو O(N) للتبسيط، وهذا يعني أن الجهد المطلوب سيتناسب طرديًا مع عدد الملفات، وبما أننا نحتاج إلى قراءة كل ملف مرة واحدة على الأقل على أي حال فلن نتمكن من تحقيق نتيجة أفضل من هذه، لكن كيف نضمن أن كل ملف فريد سيكون في مجموعته التي ينتمي لها؟

يكمن الحل في استخدام دالة تجزئة تشفيرية Cryptographic hash function تتميز مخرجاتها أنها حتمية، فإذا أعطيتها نفس البايتات بنفس الترتيب ستنتج نفس الخرج في كل مرة، ومع هذا فإن الخرج يتوزع مثل متغير عشوائي منتظم بحيث يتساوى احتمال كل خرج منها مما يضمن توزيع الملفات بالعدل بين المجموعات.

تصعب كتابة دوال التجزئة بالتشفير كما يصعب كذلك إثبات أن خوارزمية ما لديها الخصائص التي نريدها، لذا سنستخدم دالة من مكتبة التجزئة hashlib في لغة بايثون التي تنفذ خوارزمية التجزئة SHA-256.

تنتج هذه الدالة تجزئة بحجم 256 بت عند إعطائها بعض البايتات كمدخلات، وتُكتب عادة كسلسلة نصية من 64 محرف بالنظام الست عشري حيث يستخدم هذا النظام الأحرف A حتى F لتمثيل الأرقام من 10 إلى 15، فتحسب القيمة 3D5 مثلًا كالتالي:

3 × 16² + 13 × 16¹ + 5 × 16⁰ = 981 بالنظام العشري.

from hashlib import sha256

if __name__ == "__main__":
    # [example]
    example = bytes("hash", "utf-8")
    for i in range(1, len(example) + 1):
        substring = example[:i]
        hash = sha256(substring).hexdigest()
        print(f"{substring}\n{hash}")
    # [/example]

ويكون خرجها كما يلي:

b'h'
aaa9402664f1a41f40ebbc52c9993eb66aeb366602958fdfaa283b71e64db123
b'ha'
8693873cd8f8a2d9c7c596477180f851e525f4eaf55a4f637b445cb442a5e340
b'has'
9150c74c5f92d51a92857f4b9678105ba5a676d308339a353b20bd38cd669ce7
b'hash'
d04b98f48e8f8bcc15c6ae5ac050801cd6dcfd428fb5f9e65c4e16e7807340fa

مسألة عيد الميلاد

يمثل احتمال تشارك شخصين في نفس عيد الميلاد 1/365 مع تجاهل يوم 29 فبراير، ومن ثم تكون احتمالية ألا يتشاركاه هو 364/365، وإذا أضفنا شخصًا ثالثًا يكون احتمال ألا يتشارك عيد الميلاد مع الشخصين السابقين هي 363/365، وهكذا يكون الاحتمال الإجمالي لعدم تشارك هؤلاء الأشخاص في نفس عيد الميلاد هي (364/365)*(363/365)، وإذا استمر الحال على هذا النمط سنجد أن هناك احتمالًا بنسبة 50% لوجود شخصين يتشاركان يوم الميلاد نفسه في مجموعة مكونة من 23 شخصًا فقط، تزيد هذه النسبة إلى 99.9% مع وجود 70 شخصًا.

تطبيق المنطق على الملفات

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

$4 \times 10^{38}$

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

import sys
from hashlib import sha256

def find_groups(filenames):
    groups = {}
    for fn in filenames:
        data = open(fn, "rb").read()
        hash_code = sha256(data).hexdigest()
        if hash_code not in groups:
            groups[hash_code] = set()
        groups[hash_code].add(fn)
    return groups


if __name__ == "__main__":
    groups = find_groups(sys.argv[1:])
    for filenames in groups.values():
        print(", ".join(sorted(filenames)))

وعند تشغيل البرنامج:

python dup.py tests/*.txt

نحصل على النتائج التالية:

tests/a1.txt, tests/a2.txt, tests/a3.txt
tests/b1.txt, tests/b2.txt
tests/c1.txt

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

خاتمة

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

خريطة تصور اكتشاف الملفات المكررة باستخدام التجزئة.

• توضح هذه الخريطة كيف ننتقل من المقارنة الثنائية البطيئة O(n²) إلى التوزيع الذكي باستخدام التجزئة.
• تحول دالة التجزئة محتوى الملف إلى بصمة رقمية فريدة.
• يؤدي استخدام خوارزميات مثل SHA-256 إلى تقليل احتمالية التصادمات إلى أدنى مستوياتها.
• يتحسن أداء البرنامج ليصبح زمن التشغيل خطيًا O(n) مما يسمح لنا بمعالجة كميات هائلة من البيانات في وقت قياسي.

اقرأ أيضًا

• تطوير مفسر بايثون Python Interpreter
• بناء لعبة رسومية باستخدام بايثون ووحدة الألعاب Pygame
• أهم الأسئلة النظرية التي قد تطرح في المقابلات لتوظيف مطور بايثون

ترجمة -بتصرف- للفصل Chapter 3: Finding Duplicate Files من كتاب Software Design by Example.

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

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

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

تمر معظم مشاريع تصميم المستويات ثلاثية الأبعاد في ألعاب الفيديو بعدة مراحل:

1. ما قبل الإنتاج Pre-production. هي مرحلة وضع الخطوط العريضة وتصميم تجربة الاستخدام العامة.
2. المعارك Combat. هذه مرحلة اختيارية خاصة بالألعاب القتالية، وفيها تُحدد طبيعة التفاعل بين اللاعبين وأنواع الأعداء التي ستكون في اللعبة.
3. المخطط Layout. مرحلة رسم مخطط مرئي ثنائي الأبعاد من منظور علوي top view.
4. النماذج الهيكلية Blockout. مرحلة بناء مسودة أولية ثلاثية الأبعاد للنماذج الهيكلية (الأجسام والمباني وغيرها) لاختبار قابليتها للعب.
5. البرمجة النصية أو كتابة السكربتات Scripting. مرحلة ربط الأحداث بالسلوكيات الخاصة بها، وتشمل المهمات والأبواب -أسلوب فتحها مثلًا-، الأزرار ووظائفها، الذكاء الاصطناعي، إلخ، وقد كان هناك فرق كبير في الأجيال السابقة من محركات الألعاب بين شيفرة محرك اللعبة ومنطق السكربت أو البرمجة النصية في مستوى معين داخل اللعبة.
6. الإضاءة. مرحلة توزيع مصادر الإضاءة للعناصر داخل اللعبة لوضوح رؤيتها ولإضفاء عمق واقعي عليها.
7. فن البيئة Environment Art. هي مرحلة وضع اللمسة الفنية النهائية من خلال إضافة الأجسام والهياكل والأثاث وغيرها.
8. الإطلاق Release. مرحلة توثيق المشروع والتسويق له ونشره.

تخصيص المراحل

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

المشاريع الجماعية

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

ألعاب القتال أو خرائط الألعاب الجماعية

تحتاج ألعاب القتال combat games أو خرائط الألعاب الجماعية multiplayer maps إلى التركيز على إنشاء النماذج الهيكلية Blockouts من أجل إخراج متقن للمواجهات encounters التي يواجهها اللاعب، خاصة مع الشخصيات غير القابلة للعب Non playable characters (NPC)، وكذلك التركيز على موازنة الخرائط map balancing للتحكم في الخيارات المتاحة للاعب داخل المستوى، واختبارات مكثفة لتجربة اللعب نفسها playtests لمعرفة إن كان المستوى شيقًا أم مملًا، واضحًا أم محيرًا للاعب، وهكذا.

الألعاب الفردية القصصية

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

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

مرحلة ما قبل الإنتاج

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

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

مرحلة المعارك (مرحلة اختيارية)

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

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

اقتباس

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

صورة نشرها المصمم جيسون دي هيراس Jason de Hera على تويتر توضح مصفوفة الحركات لشخصيات فالكيري في لعبة God Of War.

مرحلة المخططات Layouts

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

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

صورة توضح رسمًا لخريطة Warpath متعددة اللاعبين في لعبة Team Fortress Classic، من رسم المصمم روبن ووكر Robin Walker.

مرحلة النماذج الهيكلية

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

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

هذا يعني أن ملفات النماذج الهيكلية هي مستويات كاملة أو ملفات مشاهد من اللعبة scene files يمكن لعبها وتجربتها وتحميلها داخل محرك اللعبة.

صورة لنموذج هيكلي لمستوى في لعبة Uncharted 4.

مرحلة البرمجة النصية

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

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

اقتباس

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

صورة لنسخة أولية من لعبة Gone Home، لم تعمل الأبواب بالطريقة الصحيحة، من مقالة Code Judo.

مرحلة الإضاءة

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

تتعامل صناعة الألعاب عادة مع الإضاءة كعنصر تجميلي يتبع فن البيئة، لكن الحقيقة أن لها وظائف محورية في أسلوب اللعب نفسه، لذا يجب أن تُصمَّم بعد تنسيق دقيق مع مصمم المستوى لفهم كيف ستؤدي دورها في خدمة الهدف من المستوى واللعبة ككل.

صورة لإضاءة غرفة من العصور الوسطى نفذها هارلي ويلسون Harley Wilson توضح توزيع الإضاءة في المشهد.

مرحلة فن البيئة

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

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

صورة متحركة تظهر تطور قاعدة عسكرية بحرية في لعبة Sniper Elite.

مرحلة الإطلاق

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

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

خاتمة

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

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

اقرأ أيضًا

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

ترجمة -بتصرف- للفصل How to make a level من كتاب The Level Design Book.

صورة لملعب كرة سلة متراكب فوق مخطط عام لخريطة من لعبة Halo 1 بواسطة @neilsonks

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

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

تعريف

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

صورة للقطة شاشة لمرحلة الوصول إلى الجزيرة أثناء عملية التطوير بنظام blockout بواسطة إم شاتز للعبة Uncharted 4

التصميم الوظيفي للمستويات وفن البيئة

يركز مصمم المراحل level designer على صياغة سلوك اللاعب، فيكون مسؤولًا في استديوهات التصميم الكبيرة عن كتابة الوثائق التقنية ورسم المخططات الأولية وبناء النماذج الهيكلية Blockouts ومراقبة اختبارات اللعب وكذلك موازنة خيارات اللعب المتاحة في المستوى الواحد فيما يعرف بموازنة الخريطة Map balance، والمواجهات encounters التي يتعرض لها في ساحة مفتوحة مع شخصيات اللعبة الأخرى، خاصة غير القابلة للعب منها Non Playable Characters (NPC).

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

وبناء على ما سبق نستطيع فهم تصميم المستويات من منظورين:

• المنظور الرسمي للمجال، وهو تصميم المستويات بمعناه التخصصي المهني.
• المنظور العام لتصميم المستويات بمعناه الشامل الذي يضم المنظور الرسمي إضافة إلى فن البيئة وكل ما يمكن أن يشمله المستوى.

سنركز في شرحنا على المنظور الرسمي لغرض التعليم، لكن اعلم أن اللاعب يتفاعل مع المنظور العام أكثر.

صورة توضح مخطط يقارن المنظور الوظيفي لتصميم المستوى مع المنظور العام باستخدام صور عمليات من مراحل بناء منشأة أبحاث جالينت من لعبة Dust 514

الفرق بين تصميم غرفة وتصميم عالم افتراضي

يستغرق مصمم المستوى أيامًا أو أسابيع في تصميم غرفة واحدة، لكن هذا التدقيق غير عملي في حالة الألعاب الضخمة مثل العوالم المفتوحة أو الألعاب الجماعية كثيرة اللاعبين Massively Multiplayer Online (MMO) التي تضم مئات أو آلاف الغرف.

وهنا يبرز دور مصمم العالم الافتراضي حيث يهتم بتصميم الحركة العام في المستوى وإرشاد اللاعب wayfinding عبر أحياء كاملة بدلًا من منازل فردية، ومناطق حيوية Bioms بدلًا من أماكن صغيرة، والفئات العامة categories بدلًا من الحالات الخاصة instances، ويتيح هذا المنظور الشمولي مساحة كافية لتفاعل اللاعبين والأنظمة بحرية والتي سيكون العالم الافتراضي فارغًا أو باهتًا بدونها.

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

صورة في مستوى pleasant park في لعبة فورتنايت حيث لا تهم تفاصيل كل غرفة في المنازل الموجودة بقدر الشكل العام للحي كله

النظرية مقابل البناء الفعلي

بما أن هذا المقال مقروء فمن البديهي أننا نؤمن بأهمية القراءة للتعلم، لكن المادة النصية تضعك على أعتاب المجال المهني فقط إذ يتحتم عليك أن تترك المقال أو المادة النصية في مرحلة ما لتبدأ التنفيذ فعليًا.

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

اقتباس

نستخدم أحيانًا مصطلح خريطة map بدلًا من مستوى level، إذ توحي الخريطة بوجود مساحة حرة تدعم أنماطًا مختلفة من اللعب، في حين يشير المستوى إلى مسار أكثر خضوعًا للسيناريوهات البرمجية scripts، لكن لا حرج في استخدام المصطلحين بالتبادل.

صورة للقطة شاشة لمنطقة "مركز البداية" في تعديل Arcane Dimensions للعبة Quake 1، من تصميم سايمون "sock" أوكالاهان Simon "sock" O'Callaghan وآخرين

نقاء نظرية التصميم

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

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

 صورة توضح الاستراتيجيات المتنوعة للإضاءة النهارية المستخدمة في الهندسة المعمارية، فرانسيس تشينج من كتاب "Form, Space, and Order"

النظرة الشمولية

رغم أنه من الضروري أن يركز مصمم المستوى على سلوك اللاعب إلا أننا نحتاج أحيانًا إلى توسيع المنظور ليشمل الصورة الكاملة، فالمستوى أكبر من مجرد بناء تقني، بل هو مزيج معقد يجمع بين التصميم المكاني spatial design والفن وعلم النفس والبرمجة والثقافة، ولا يوجد فاصل حقيقي من منظور اللاعب بين تصميم المستوى وفن البيئة إذ يشمل تصميم المستوى كل ما يؤثر في عالم اللعبة.

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

خاتمة

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

ترجمة بتصرف للفصل What is level design من كتاب The Level Design Book.

يهدف هذا المقال إلى مساعدة المبرمج في توسيع معرفته البرمجية من خلال الاطلاع على شيفرة برمجية مفتوحة المصدر توضح له آلية العمل وتزيد من خبرته البرمجية، لذا سنوضح الشيفرة البرمجية لمفسر بايثون بسيط هو المفسر Byterun المكتوب بلغة بايثون نفسها والمحدود بحوالي 500 سطر، مما يبسط كيفية عمل المفسر ودراسة شيفرته البرمجية مفتوحة المصدر، وبالتالي سيساعد في تحسين المهارات البرمجية وفهم عمل المفسر ويعلمنا كيفية بناء مفسر لغة برمجية خاص بنا.

كتب Ned Batchelder و Allison Kaptur مفسر بايثون Byterun بناءً على عمل Paul Swartz، وبنيته مماثلة لمفسر بايثون الأساسي CPython، لذا سيساعدنا فهم مفسر Byterun على فهم المفسرات وخاصةً مفسر CPython شائع الاستخدام. يستطيع مفسر Byterun تشغيل معظم برامج بايثون البسيطة بالرغم من عدد سطور شيفرته القصير.

مفسر بايثون

لنحدد أولًا ما يعنيه مفسر بايثون، إذ يمكن استخدام مصطلح مفسر Interpreter بطرق مختلفة في سياق الحديث عن بايثون، حيث يشير أحيانًا المفسر إلى Python REPL، وهو الموجِّه التفاعلي الذي نحصل عليه من خلال كتابة python في سطر الأوامر، وقد يُستخدَم مفسر بايثون للدلالة على التنفيذ الكامل لشيفرة بايثون البرمجية، ولكن سيدل مصطلح المفسر في هذا المقال على مجال أضيق، وهو الخطوة الأخيرة من عملية تنفيذ برنامج بايثون.

يسبق تشغيل المفسر ثلاث خطوات في بايثون وهي: تحليل المفردات Lexing والتحليل Parsing والتصريف Compiling، حيث تعمل هذه الخطوات مع بعضها البعض لتحويل شيفرة المبرمج المصدرية من أسطر نصية إلى كائنات شيفرة Code Objects منظمة تحتوي على تعليمات Instructions يمكن للمفسر فهمها، وتتمثل مهمة المفسر في أخذ هذه الكائنات واتباع التعليمات.

يُعَد التصريف خطوة من خطوات تنفيذ شيفرة بايثون بالرغم من اعتبارها لغة مُفسَّرة مثل لغتي Ruby أو Perl، بينما تُعَد C أو Rust لغات مُصرَّفة. تتضمن معظم اللغات المفسَّرة بما في ذلك لغة بايثون خطوة تصريف، وسبب وصف بايثون بأنها لغة مفسَّرة هو أن خطوة التصريف تنجر عملًا أقل نسبيًا من العمل الذي تنجزه في لغة مُصرَّفة. ينجز المفسر في لغة بايثون العمل الأكبر نسبيًا، إذ يحتوي مُصرِّف بايثون على معلومات أقل بكثير حول سلوك البرنامج مقارنةً بمصرِّف لغة سي C.

تطوير مفسر بايثون باستخدام بايثون

Byterun هو مفسر بايثون مكتوب بلغة بايثون نفسها كما هو الحال مع مصرِّف C المستخدَم على نطاق واسع gcc المكتوب بلغة C، ولكن يمكننا كتابة مفسر بايثون بأي لغة تقريبًا.

توجد مزايا وعيوب لكتابة مفسر بايثون باستخدام بايثون، فالعيب الأكبر هو السرعة، إذ يُعَد تنفيذ الشيفرة البرمجية في Byterun أبطأ بكثير من تنفيذها في مفسر CPython المكتوب بلغة C، ولكن صُمِّم مفسر Byterun في الأصل كتطبيق تعليمي، لذا لم تكن السرعة ذات أهمية كبيرة.

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

بناء مفسر

لنتعرف أولًا على كيفية عمل مفسر بايثون قبل البدء بشيفرة Byterun البرمجية، حيث يُعَد مفسر بايثون آلة افتراضية Virtual Machine، أي أنه برنامج يحاكي حاسوبًا حقيقيًا، وتكون هذه الآلة الافتراضية عبارة عن آلة مكدس Stack Machine، أي أنها تعالج عدة مكدسات لأداء عملياتها على عكس آلة التسجيل Register Machine التي تكتب وتقرأ من مواقع ذاكرة معينة.

مفسّر بايثون هو مفسر بايت كود Bytecode، فمدخلاته هي مجموعات من التعليمات تسمى بايت كود، حيث يولّد محلل المفردات والمحلل والمصرِّف كائنات شيفرة ليعمل عليها المفسّر عندما نكتب شيفرة بايثون الخاصة بنا، ويحتوي كل كائن من هذه الكائنات على مجموعة من التعليمات التي يجب تنفيذها والتي هي البايت كود بالإضافة إلى معلومات أخرى سيحتاجها المفسر. يُعَد البايت كود تمثيلًا وسيطًا لشيفرة بايثون البرمجية، لأنها تعبّر عن الشيفرة المصدرية المكتوبة بطريقة يمكن للمفسّر فهمها، وهي تشبه الطريقة التي تعمل بها لغة التجميع Assembly كتمثيل وسيط بين شيفرة C والعتاد.

بناء مفسر بسيط

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

• LOAD_VALUE
• ADD_TWO_VALUES
• PRINT_ANSWER

لن نهتم في هذا المقال بمحلل المفردات والمحلل والمصرِّف، وبالتالي لن نهتم بكيفية توليد مجموعات التعليمات. لنفترض كتابة العملية ‎7 + 5‎ التالية، حيث يصدر المصرِّف مجموعة من التعليمات الثلاث السابقة، أو إذا كان لدينا المصرِّف الصحيح، فيمكننا الكتابة بصيغة لغة Lisp المُحوَّلة إلى مجموعة التعليمات نفسها. لا يهتم المفسر بذلك، فما يهمه هو أن يحصل على تنسيق مناسب من هذه التعليمات.

7 + 5

وستنتج العملية السابقة مجموعة التعليمات التالية:

what_to_execute = {
    "instructions": [("LOAD_VALUE", 0),  # العدد الأول
                     ("LOAD_VALUE", 1),  # العدد الثاني
                     ("ADD_TWO_VALUES", None),
                     ("PRINT_ANSWER", None)],
    "numbers": [7, 5] }

مُفسِّر بايثون هو آلة مكدس، لذا يجب أن يعالج المكدسات لجمع عددين كما هو موضح في الشكل الآتي، حيث سيبدأ المفسر بتنفيذ التعليمة الأولى LOAD_VALUE ودفع العدد الأول إلى المكدس، ثم يدفع العدد الثاني إلى المكدس، ثم تستخرج التعليمة الثالثة ADD_TWO_VALUES العددين وتجمعهما وتدفع النتيجة إلى المكدس، وأخيرًا يستخرج المفسر الإجابة مرة أخرى من المكدس ويطبعها.

تخبر التعليمة LOAD_VALUE المفسر بدفع عدد إلى المكدس، ولكن لا تحدد التعليمات وحدها هذا العدد، إذ تحتاج التعليمة إلى معلومات إضافية تخبر المفسر بمكان العثور على العدد الذي يجب تحميله، لذا تحتوي مجموعة التعليمات في مثالنا على معلومتين هما: التعليمات نفسها وقائمة الثوابت التي ستحتاجها التعليمات. التعليمات هي البايت كود في بايثون، والكائن الذي يجب تنفيذه what_to_execute هو كائن الشيفرة.

ولكن لماذا لا نضع الأعداد في التعليمات مباشرةً؟ حسنًا، لنفترض أننا نريد جمع سلاسل نصية بدلًا من جمع أعداد، إذ لن نرغب في جعل التعليمات كبيرة الحجم عندما نضع هذه السلاسل النصية مع التعليمات، وتسمح هذه الطريقة بالحصول على نسخة واحدة فقط من كل كائن نحتاجه، وبالتالي يمكن أن تكون الأعداد "numbers" هي [7] فقط لإجراء العملية 7 + 7 مثلًا.

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

لنبدأ الآن في كتابة المفسر، حيث يحتوي كائن المفسر على مكدس نمثله بقائمة، ويحتوي على تابع يحدد كيفية تنفيذ التعليمات، إذ سيدفع المفسر القيمة إلى المكدس مثلًا بالنسبة للتعليمة LOAD_VALUE.

class Interpreter:
    def __init__(self):
        # مكدّس لتخزين القيم أثناء التنفيذ
        self.stack = []

    def LOAD_VALUE(self, number):
        # تحميل/إدخال قيمة إلى المكدّس
        self.stack.append(number)

    def PRINT_ANSWER(self):
        # إخراج آخر قيمة من المكدّس وطباعتها
        answer = self.stack.pop()
        print(answer)

    def ADD_TWO_VALUES(self):
        # سحب آخر قيمتين من المكدّس ثم جمعهما وإرجاع الناتج إلى المكدّس
        first_num = self.stack.pop()
        second_num = self.stack.pop()
        total = first_num + second_num
        self.stack.append(total)

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

def run_code(self, what_to_execute):
    # استخراج قائمة التعليمات وقائمة القيم العددية من المدخل
    instructions = what_to_execute["instructions"]
    numbers = what_to_execute["numbers"]

    # تنفيذ التعليمات بالترتيب (كمفسّر بسيط)
    for each_step in instructions:
        # كل خطوة تحتوي اسم التعليمة ووسيطها إن وجد
        instruction, argument = each_step

        if instruction == "LOAD_VALUE":
            # جلب قيمة عددية حسب الفهرس ثم وضعها في المكدّس
            number = numbers[argument]
            self.LOAD_VALUE(number)

        elif instruction == "ADD_TWO_VALUES":
            # جمع آخر قيمتين في المكدّس ثم وضع الناتج في المكدّس
            self.ADD_TWO_VALUES()

        elif instruction == "PRINT_ANSWER":
            # طباعة آخر قيمة في المكدّس (غالبًا النتيجة)
            self.PRINT_ANSWER()

يمكننا اختبار ذلك من خلال إنشاء نسخة من الكائن ثم استدعاء التابع run_code مع مجموعة التعليمات الخاصة بجمع العددين ‎7 + 5‎، وستظهر الإجابة 12 بالتأكيد.

  interpreter = Interpreter()
    interpreter.run_code(what_to_execute)

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

يمكننا جمع أكثر من عددين في وقت واحد باستخدام مجموعات تعليمات صالحة دون أي تعديلات على المفسر الخاص بنا، إذًا ليكن لدينا مجموعة التعليمات التالية، ولنحاول توقع ما يحدث وما هي الشيفرة البرمجية المناسبة لتوليد هذه المجموعة من التعليمات عند وجود مصرِّف مناسب:

 what_to_execute = {
        "instructions": [("LOAD_VALUE", 0),
                         ("LOAD_VALUE", 1),
                         ("ADD_TWO_VALUES", None),
                         ("LOAD_VALUE", 2),
                         ("ADD_TWO_VALUES", None),
                         ("PRINT_ANSWER", None)],
        "numbers": [7, 5, 8] }

يمكننا تصور كيفية توسيع هذه البنية من خلال إضافة توابع إلى كائن المفسر لإجراء العديد من العمليات الأخرى مع وجود مصرِّف يزودنا بمجموعات تعليمات ذات تنسيق مناسب.

المتغيرات

نحتاج الآن إلى إضافة متغيرات إلى المفسر، حيث تتطلب المتغيرات تعليمات لتخزين قيمة متغير STORE_NAME وتعليمات لاسترجاعها LOAD_NAME مع ربط أسماء المتغيرات بقيمها. سنتجاهل حاليًا مساحات الأسماء والمجالات لنتمكن من تخزين ربط المتغيرات مع كائن المفسر. يجب التأكد من أن المتغير what_to_execute لديه قائمة بأسماء المتغيرات بالإضافة إلى قائمة الثوابت الخاصة به.

>>> def s():
...     a = 1
...     b = 2
...     print(a + b)

# هذا قاموس يصف بايت كود مبسّط للدالة s: ماذا ننفّذ وبأي ترتيب

what_to_execute = {
    # قائمة التعليمات بالترتيب
    # كل عنصر عبارة عن: (اسم التعليمة، وسيطها) والوسيط قد يكون فهرسًا أو لا يوجد
    "instructions": [
        ("LOAD_VALUE", 0),         # وضع القيمة الأولى في المكدّس
        ("STORE_NAME", 0),         # تخزين أعلى قيمة في المكدّس داخل المتغير الأول
        ("LOAD_VALUE", 1),         # وضع القيمة الثانية في المكدّس
        ("STORE_NAME", 1),         # تخزين أعلى قيمة في المكدّس داخل المتغير الثاني
        ("LOAD_NAME", 0),          # تحميل قيمة المتغير الأول إلى المكدّس
        ("LOAD_NAME", 1),          # تحميل قيمة المتغير الثاني إلى المكدّس
        ("ADD_TWO_VALUES", None),  # جمع آخر قيمتين في المكدّس ووضع الناتج في المكدّس
        ("PRINT_ANSWER", None)     # طباعة آخر قيمة في المكدّس
    ],

    # قائمة القيم العددية التي تشير إليها التعليمات عبر فهارس
    "numbers": [1, 2],

    # قائمة أسماء المتغيرات التي تشير إليها التعليمات عبر فهارس
    "names": ["a", "b"]
}

يمكننا تتبع الأسماء المرتبطة بالقيم من خلال إضافة القاموس environment إلى التابع ‎__init__‎ مع إضافة STORE_NAME و LOAD_NAME، حيث تبحث هذه التوابع أولًا عن اسم المتغير ثم تستخدم القاموس لتخزين قيمة المتغير أو استرجاعها.

يمكن أن تكون الوسطاء الخاصة بالتعليمة إما فهرسًا في قائمة الأعداد "numbers"، أو يمكن أن تكون فهرسًا في قائمة الأسماء "names"، إذ يعرف المفسر ما يجب أن تكون عليه من خلال التحقق من التعليمة التي ينفذها. لنضع هذه الشيفرة البرمجية مع ربط التعليمات مع ما تمثله وسطاؤها في تابع منفصل كما يلي:

class Interpreter:
    def __init__(self):
        # مكدّس لتخزين القيم مؤقتًا أثناء التنفيذ
        self.stack = []
        # بيئة لحفظ قيم المتغيرات (اسم المتغير ← قيمته)
        self.environment = {}

    def STORE_NAME(self, name):
        # أخذ آخر قيمة من المكدّس وتخزينها باسم متغير
        val = self.stack.pop()
        self.environment[name] = val

    def LOAD_NAME(self, name):
        # جلب قيمة متغير ووضعها في المكدّس
        val = self.environment[name]
        self.stack.append(val)

    def parse_argument(self, instruction, argument, what_to_execute):
        """تفسير معنى الوسيط لكل تعليمة"""
        # تعليمات تستخدم قائمة الأرقام
        numbers = ["LOAD_VALUE"]
        # تعليمات تستخدم قائمة أسماء المتغيرات
        names = ["LOAD_NAME", "STORE_NAME"]

        if instruction in numbers:
            # تحويل الفهرس إلى رقم فعلي
            argument = what_to_execute["numbers"][argument]
        elif instruction in names:
            # تحويل الفهرس إلى اسم متغير فعلي
            argument = what_to_execute["names"][argument]

        return argument

    def run_code(self, what_to_execute):
        # أخذ التعليمات وتنفيذها بالترتيب
        instructions = what_to_execute["instructions"]
        for each_step in instructions:
            # كل خطوة: (اسم التعليمة، وسيطها)
            instruction, argument = each_step
            # تحويل الوسيط من فهرس إلى قيمة مفهومة
            argument = self.parse_argument(instruction, argument, what_to_execute)

            if instruction == "LOAD_VALUE":
                # إدخال رقم إلى المكدّس
                self.LOAD_VALUE(argument)
            elif instruction == "ADD_TWO_VALUES":
                # جمع آخر قيمتين في المكدّس
                self.ADD_TWO_VALUES()
            elif instruction == "PRINT_ANSWER":
                # طباعة آخر قيمة في المكدّس
                self.PRINT_ANSWER()
            elif instruction == "STORE_NAME":
                # تخزين قيمة في متغير
                self.STORE_NAME(argument)
            elif instruction == "LOAD_NAME":
                # تحميل قيمة متغير إلى المكدّس
                self.LOAD_NAME(argument)

قد تصبح بنية التابع run_code معقدة بعض الشيء بالرغم من وجود خمس تعليمات فقط، إذ نحتاج فرعًا واحدًا من تعليمة if لكل تعليمة، لذا يمكن الاستفادة من البحث الديناميكي عن تابع في بايثون بحيث نعرّف تابعًا اسمه FOO ينفّذ التعليمة التي اسمها FOO، وبالتالي نستخدم الدالة getattr في بايثون للبحث عن التابع بسرعة بدلًا من استخدام تعليمة if السابقة المعقدة. سيبدو الآن التابع run_code على النحو التالي

def execute(self, what_to_execute):
    # جلب قائمة التعليمات
    instructions = what_to_execute["instructions"]

    # تنفيذ التعليمات خطوة بخطوة
    for each_step in instructions:
        # استخراج اسم التعليمة ووسيطها
        instruction, argument = each_step

        # تحويل الوسيط من فهرس إلى قيمة فعلية (رقم أو اسم متغير)
        argument = self.parse_argument(instruction, argument, what_to_execute)

        # الحصول على الدالة المطابقة لاسم التعليمة داخل هذا الصنف
        bytecode_method = getattr(self, instruction)

        # تنفيذ التعليمة: إن لم يكن لها وسيط ننفذها مباشرة، وإلا نمرر الوسيط
        if argument is None:
            bytecode_method()
        else:
            bytecode_method(argument)

بناء بايت كود حقيقي في بايثون

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

>>> def cond():
...     x = 3                 
...     if x < 5:             
...         return 'yes'      
...     else:                 
...         return 'no'       

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

>>> cond.__code__.co_code  # الوصول إلى البايت كود الخام للدالة على شكل بايتات
b'd\x01\x00}\x00\x00|\x00\x00d\x02\x00k\x00\x00r\x16\x00d\x03\x00Sd\x04\x00Sd\x00
   \x00S'                  # هذه هي البايتات نفسها التي ينفّذها مفسّر بايثون

>>> list(cond.__code__.co_code)  # تحويل نفس البايتات إلى قائمة أعداد لقراءتها بسهولة
[100, 1, 0, 125, 0, 0, 124, 0, 0, 100, 2, 0, 107, 0, 0, 114, 22, 0, 100, 3, 0, 83, 
 100, 4, 0, 83, 100, 0, 0, 83]  # كل رقم يمثّل جزءًا من تعليمة أو وسيطها داخل البايت كود

يُعَد البايت كود غير مفهوم، إذ لا يمكننا تمييز إلّا سلسلة من البايتات، ولكن توجد أداة يمكننا استخدامها لفهمها، والتي هي وحدة dis في مكتبة بايثون المعيارية، حيث تمثل هذه الوحدة مفككًا للبايت كود الذي يأخذ شيفرة منخفضة المستوى ومكتوبة للأجهزة مثل شيفرة التجميع أو البايت كود، ويطبعها بطريقة يمكن أن يقرأها الإنسان، فمثلًا يؤدي تشغيل dis.dis إلى عرض شرحٍ للبايت كود الممرَّر إليه.

>>> dis.dis(cond)  # عرض البايت كود بصيغة مقروءة (تعليمات + عناوين)

  2           0 LOAD_CONST               1 (3)      # تحميل الثابت رقم 1 (القيمة 3)
              3 STORE_FAST               0 (x)      # تخزين القيمة في المتغير المحلي رقم 0 (x)

  3           6 LOAD_FAST                0 (x)      # x تحميل قيمة المتغير المحلي 
              9 LOAD_CONST               2 (5)      # تحميل الثابت رقم 2 (القيمة 5)
             12 COMPARE_OP               0 (<)      # (<) مقارنة القيمتين باستخدام العامل
             15 POP_JUMP_IF_FALSE       22          # إذا كانت نتيجة الشرط غير صحيحة اقفز إلى العنوان 22

  4          18 LOAD_CONST               3 ('yes')  # 'yes' تحميل الثابت 
             21 RETURN_VALUE                        # إرجاع القيمة

  6     >>   22 LOAD_CONST               4 ('no')   # 'no' تحميل الثابت
             25 RETURN_VALUE                        # إرجاع القيمة
             26 LOAD_CONST               0 (None)   # قيمة افتراضية عند عدم الإرجاع صراحة
             29 RETURN_VALUE                        

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

تمثل البايتات الستة الأولى من البايت كود‎ [100, 1, 0, 125, 0, 0] تعليمتين مع وسطائهما، ويمكننا استخدام dis.opname التي تربط البايتات مع سلاسل نصية مفهومة لمعرفة ما تعنيه التعليمتان 100 و 125 كما يلي:

>>> dis.opname[100]        # إرجاع اسم التعليمة المقابل لرقم العملية 100
'LOAD_CONST'               # الرقم 100 يعني: تحميل ثابت

>>> dis.opname[125]        # إرجاع اسم التعليمة المقابل لرقم العملية 125
'STORE_FAST'               # الرقم 125 يعني: تخزين قيمة في متغير محلي

يمثل البايتان الثاني والثالث ‎1 و 0‎ وسطاء التعليمة LOAD_CONST، ويمثل البايتان الخامس والسادس ‎0 و 0‎ وسطاء التعليمة STORE_FAST، إذ تحتاج التعليمة LOAD_CONST إلى معرفة مكان العثور على الثابت لتحميله، وتحتاج التعليمة STORE_FAST إلى العثور على الاسم لتخزينه. تمثل هذه البايتات الستة السطر الأول من الشيفرة البرمجية x = 3، حيث تقابل التعليمة LOAD_CONST في بايثون التعليمة LOAD_VALUE في المفسر السابق، وتقابل التعليمة LOAD_FAST التعليمة LOAD_NAME.

يُستخدَم بايتان لكل وسيط، لأنه إذا استخدم بايثون بايتًا واحدًا فقط لتحديد مكان الثوابت والأسماء بدلًا من استخدام بايتين، فلن نتمكن إلا من الحصول على 256 اسمٍ أو ثابت مرتبط بكائن شيفرة واحد، بينما يمكن الحصول على ما يصل إلى مربع العدد 256 أو 65536 عند استخدام بايتين.

التعليمات الشرطية والحلقات

نفّذَ المفسر حتى الآن الشيفرة البرمجية ببساطة من خلال تنفيذ التعليمات واحدة تلو الأخرى، ولكن قد يشكّل ذلك مشكلة، لأننا في أغلب الاحيان نريد تكرار تنفيذ تعليمات معينة، أو قد نرغب في تخطي بعض التعليمات في شروط محددة، لذا يجب أن يكون المفسر قادرًا على التنقل عبر مجموعة التعليمات للسماح بكتابة الحلقات والتعليمات الشرطية if في الشيفرة البرمجية، حيث يتعامل بايثون مع الحلقات والتعليمات الشرطية باستخدام تعليمات GOTO في البايت كود. لنطلع الآن على تفكيك الدالة cond مرة أخرى:

>>> dis.dis(cond)  # عرض تعليمات الدالة بصيغة مقروءة (العنوان + اسم التعليمة + الوسيط)

  2           0 LOAD_CONST               1 (3)      # تحميل الثابت 3 إلى المكدّس
              3 STORE_FAST               0 (x)      # x تخزين القيمة في المتغير المحلي 

  3           6 LOAD_FAST                0 (x)      # تحميل قيمة x إلى المكدّس
              9 LOAD_CONST               2 (5)      # تحميل الثابت 5 إلى المكدّس
             12 COMPARE_OP               0 (<)      # مقارنة: هل x أصغر من 5؟
             15 POP_JUMP_IF_FALSE       22          # إذا كانت المقارنة خطأ انتقل إلى العنوان 22

  4          18 LOAD_CONST               3 ('yes')  # تحميل 'yes' (فرع if)
             21 RETURN_VALUE                        # إرجاع القيمة وإنهاء الدالة

  6     >>   22 LOAD_CONST               4 ('no')   # تحميل 'no' (فرع else)
             25 RETURN_VALUE                        # إرجاع القيمة وإنهاء الدالة
             26 LOAD_CONST               0 (None)   # تحميل None كقيمة افتراضية
             29 RETURN_VALUE                        # إرجاع None (مسار افتراضي/احتياطي)

تُصرَّف التعليمة الشرطية ‎if x < 5‎ في السطر 3 من الشيفرة البرمجية إلى أربع تعليمات هي: LOAD_FAST و LOAD_CONST و COMPARE_OP و POP_JUMP_IF_FALSE، حيث يولد الشرط ‎x < 5‎ الشيفرة البرمجية لتحميل x وتحميل القيمة 5 ومقارنة القيمتين. تكون التعليمة POP_JUMP_IF_FALSE مسؤولة عن تنفيذ تعليمة if، إذ تؤدي هذه التعليمة إلى سحب القيمة العليا من مكدس المفسر، حيث إذا كانت القيمة صحيحة، فلن يحدث شيء، ويمكن أن تكون القيمة صحيحة دون أن تكون كائن True حرفيًا، بينما إذا كانت القيمة خاطئة، فسينتقل المفسر إلى تعليمة أخرى.

تسمى التعليمة التي يجب الوصول إليها بهدف عملية القفز Jump Target، وتكون وسيطًا للتعليمة POP_JUMP، فهدف القفز هو 22 في مثالنا، والتعليمة ذات الفهرس 22 هي LOAD_CONST عند السطر 6، حيث تضع وحدة dis الرمز << على أهداف القفز. إذا كانت نتيجة الشرط ‎x < 5‎ خاطئة، فسيقفز المفسر إلى السطر 6 مباشرةً return "no"‎‎ مع تجاوز السطر 4 الذي هو ‎return "yes"، وبالتالي يستخدم المفسر تعليمات القفز للتخطي الانتقائي لأجزاء من مجموعة التعليمات.

تعتمد حلقات Loops بايثون على القفز، فمثلًا يولّد السطر while x < 5 في البايت كود التالي بايت كود متطابقًا تقريبًا مع بايت كود التعليمة if x < 10، حيث تُطبَّق المقارنة في كلتا الحالتين ثم تتحكم التعليمة POP_JUMP_IF_FALSE بالتعليمة التالية التي ستُنفَّذ. ترسل التعليمة JUMP_ABSOLUTE في نهاية السطر 4 الذي يمثل نهاية جسم الحلقة دائمًا المفسر مرة أخرى إلى التعليمة 9 في أعلى الحلقة، وتؤدي التعليمة POP_JUMP_IF_FALSE إلى قفز المفسر إلى ما بعد نهاية الحلقة إلى التعليمة 34 عندما يصبح الشرط x < 5‎ خاطئًا.

>>> def loop():
...      x = 1                  
...      while x < 5:          
...          x = x + 1             
...      return x            
...
>>> dis.dis(loop)  # عرض تعليمات الدالة بصيغة مقروءة

  2           0 LOAD_CONST               1 (1)      # تحميل الثابت 1 إلى المكدّس
              3 STORE_FAST               0 (x)      # x تخزينه في المتغير المحلي 

  3           6 SETUP_LOOP              26 (to 35)  # تجهيز إطار الحلقة (بداية/نهاية ومسار الخروج)
        >>    9 LOAD_FAST                0 (x)      # تحميل x لفحص شرط الحلقة
             12 LOAD_CONST               2 (5)      # تحميل الثابت 5
             15 COMPARE_OP               0 (<)      # مقارنة: هل x أصغر من 5؟
             18 POP_JUMP_IF_FALSE       34          # إذا كان الشرط غير صحيح اقفز إلى نهاية الحلقة (العنوان 34)

  4          21 LOAD_FAST                0 (x)      # تحميل x لتنفيذ جسم الحلقة
             24 LOAD_CONST               1 (1)      # تحميل الثابت 1
             27 BINARY_ADD                          # (x + 1) جمع القيمتين 
             28 STORE_FAST               0 (x)      # x تخزين الناتج في 
             31 JUMP_ABSOLUTE            9          # الرجوع لبداية فحص الشرط (العنوان 9)
        >>   34 POP_BLOCK                          # إنهاء إطار الحلقة بعد الخروج منها

  5     >>   35 LOAD_FAST                0 (x)      # تحميل x بعد انتهاء الحلقة
             38 RETURN_VALUE                        # x إرجاع