Arabic:هندسة البرمجيات

مقدمة

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

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

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

تحميل الفيديو

يوتيوب

قد يقوم يوتيوب بجمع البيانات الشخصية. سياسة الخصوصية

استمرار تجاهل

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

أهداف التعلم

بعد إتمام هذه الدورة، يُتوقع أن تكون قادرًا على تحليل مشروع برمجي جامعي أو مهني وربط قراراته عبر دورة الحياة كاملة.

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

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

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

تمثيل مبسط لدورة حياة تطوير البرمجيات؛ تسميات الصورة بالإنجليزية ويشرح النص العربي معناها.

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

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

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

هندسة المتطلبات

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

المتطلبات الوظيفية تصف ما يفعله النظام. مثال: «يستطيع الطالب حجز مختبر متاح لمدة لا تتجاوز ساعتين». أما المتطلبات غير الوظيفية فترتبط بخصائص الجودة أو القيود، مثل زمن الاستجابة، والتوافر، والأمان، وقابلية الاستخدام، وقابلية الصيانة. صياغة «يجب أن يكون النظام سريعًا» ضعيفة لأنها غير قابلة للاختبار، بينما «يجب أن تظهر نتائج البحث خلال ثانيتين في 95 بالمئة من الطلبات تحت حمل متفق عليه» أوضح وأقرب للقياس.

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

قصة مستخدم ممكنة في مشروعنا: «بصفتي طالبًا، أريد رؤية الأوقات المتاحة لمختبر محدد كي أختار وقتًا لا يتعارض مع محاضراتي». ومن معايير القبول: أن تستبعد القائمة الفترات المحجوزة، وأن تطبق سياسة الساعات المسموحة، وأن تعرض رسالة مفهومة عند عدم وجود وقت متاح.

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

تحميل الفيديو

يوتيوب

قد يقوم يوتيوب بجمع البيانات الشخصية. سياسة الخصوصية

استمرار تجاهل

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

التصميم والمعمارية

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

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

المستخدم
   ↓
واجهة الويب
   ↓
واجهة برمجة التطبيقات
   ↓
خدمة الحجز ─── خدمة الإشعارات
   ↓
قاعدة البيانات

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

طبقة العرض
   ↓
طبقة التطبيق
   ↓
طبقة المجال
   ↓
طبقة البنية التحتية

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

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

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

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

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

مثال على مخطط معماري لنظام معلومات متعدد المكونات؛ استخدمه لملاحظة الحدود والواجهات لا لنسخ البنية حرفيًا.

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

التنفيذ وجودة الشفرة

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

في مشروع الحجز يمكن وضع قاعدة التعارض في دالة مستقلة عن إطار الويب:

def can_book(room, start, end):
    if room.is_closed:
        return False
    return not room.has_conflict(start, end)

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

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

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

الاختبار وضمان الجودة

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

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

نموذج V يوضح مبدأ ربط أنشطة التحديد والتصميم بمستويات مقابلة من التحقق والاختبار.

مثال لاختبار وحدة باستخدام Python:

def test_rejects_conflicting_booking():
    room = Room(closed=False, conflicts=True)
    assert can_book(room, "10:00", "11:00") is False

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

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

تحميل الفيديو

يوتيوب

قد يقوم يوتيوب بجمع البيانات الشخصية. سياسة الخصوصية

استمرار تجاهل

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

التحكم بالإصدارات والتعاون على الشفرة

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

تدفق مبسط في Git بين مساحة العمل والتاريخ المحلي والمستودع البعيد؛ تسميات الرسم بالإنجليزية ويشرح النص العربي الفكرة.

سير عمل بسيط لميزة تحقق جديدة:

git switch -c feature/booking-validation
git add .
git commit -m "إضافة التحقق من تعارض الحجز"
git push -u origin feature/booking-validation

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

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

تحميل الفيديو

يوتيوب

قد يقوم يوتيوب بجمع البيانات الشخصية. سياسة الخصوصية

استمرار تجاهل

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

التوثيق والعمل الجماعي

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

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

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

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

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

النشر وDevOps والممارسات الحديثة

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

مقارنة بين التسليم المستمر والنشر المستمر؛ يوضح النص العربي أن الفرق الرئيس يتعلق بآلية الانتقال إلى بيئة الإنتاج.

يمكن تمثيل خط تحقق مفاهيمي على النحو التالي:

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

الحاويات تساعد على تغليف التطبيق واعتمادياته في وحدة تشغيل قابلة للنقل نسبيًا بين البيئات. مثال Dockerfile مبسط لتطبيق Python:

FROM python:3.13-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "app.py"]

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

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

تحميل الفيديو

يوتيوب

قد يقوم يوتيوب بجمع البيانات الشخصية. سياسة الخصوصية

استمرار تجاهل

يقدم الفيديو السابق شرحًا عربيًا لـ DevOps وCI/CD ودور هذه الممارسات في تحسين دورة حياة المشروع التقني. بعد المشاهدة، حدد خطوة واحدة في مشروعك يمكن أتمتتها دون إخفاء مسؤولية الفريق عن النتيجة.

الصيانة وقابلية الصيانة

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

تعامل المعايير الحديثة لجودة المنتجات البرمجية، ومنها ISO/IEC 25010:2023، قابلية الصيانة باعتبارها خاصية جودة مهمة يمكن تحليلها عبر جوانب مثل الوحداتية، وقابلية التحليل، وقابلية التعديل، وقابلية الاختبار، وإعادة الاستخدام. هذه الجوانب مترابطة: فصل المسؤوليات وتحسين الاختبارات يسهلان التغيير، والتوثيق الجيد يسرع التحليل، والواجهات المستقرة تقلل أثر التعديل.

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

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

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

سيناريو مشروع متكامل

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

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

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

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

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

مهام تفاعلية

اختبار: اختبر معرفتك

ما الصفة الأهم في صياغة متطلب برمجي جيد؟ (أن يكون واضحا وقابلا للتحقق) (!أن يكون طويلا جدا) (!أن يذكر أداة برمجية محددة دائما) (!أن يكتب بعد الانتهاء من التنفيذ)

ما الهدف الرئيس من معمارية البرمجيات؟ (تنظيم القرارات البنيوية المهمة وعلاقات المكونات) (!اختيار لون واجهة المستخدم) (!زيادة عدد الملفات في المشروع) (!استبدال جميع الاختبارات اليدوية)

ما الذي يميز اختبار الوحدة؟ (فحص جزء صغير من المنطق في عزل نسبي) (!اختبار النظام في الإنتاج فقط) (!قياس سرعة الشبكة وحدها) (!مراجعة الوثائق من دون تشغيل الشفرة)

ما الغرض من اختبار الانحدار؟ (التأكد من أن التغيير الجديد لم يفسد سلوكا سابقا) (!قياس رضا المستخدمين فقط) (!حذف الاختبارات القديمة) (!استبدال التحكم بالإصدارات)

لماذا يستخدم الفريق فرعا في Git؟ (لعزل مجموعة تغييرات قبل دمجها) (!لإلغاء تاريخ المشروع) (!لتشغيل قاعدة البيانات تلقائيا) (!لمنع أي مراجعة للشفرة)

ما الفائدة الأساسية من طلب الدمج؟ (عرض تغيير مقترح للمراجعة والتحقق قبل دمجه) (!تشفير المستودع بالكامل) (!استبدال المتطلبات بالشفرة) (!حذف الحاجة إلى الاختبارات)

ما المقصود بالتكامل المستمر؟ (دمج التغييرات والتحقق منها آليا بوتيرة متقاربة) (!نشر كل تغيير إلى الإنتاج من دون فحص) (!كتابة الوثائق مرة واحدة فقط) (!تأجيل الاختبار حتى نهاية المشروع)

ما وظيفة سجل القرار المعماري؟ (توثيق سياق قرار معماري وبدائله وأسبابه ونتائجه) (!حفظ كلمات المرور) (!تسجيل حضور الفريق) (!استبدال مخزن الشفرة)

ما السلوك الذي يدعم قابلية الصيانة؟ (فصل المسؤوليات مع اختبارات وتوثيق مناسبين) (!زيادة الاقتران بين الوحدات) (!تكرار المنطق في مواضع كثيرة) (!منع إعادة الهيكلة تماما)

ما فائدة خطة الاسترجاع عند النشر؟ (العودة بسرعة إلى إصدار مستقر عند ظهور مشكلة خطرة) (!حذف سجل الإصدارات) (!إيقاف المراقبة بعد النشر) (!تجنب اختبار الإصدار قبل النشر)

لعبة الذاكرة

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

السحب والإفلات

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

كلمات متقاطعة

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

مهام مفتوحة

سهل

1. صياغة قصة مستخدم: اكتب قصة مستخدم لمنصة الحجز الجامعية، وحدد صاحب الدور والهدف والقيمة التي يريدها بلغة واضحة.
2. معيار قبول: حوّل متطلبا غامضا مثل «النظام سريع» إلى معيار قبول قابل للقياس والاختبار، واشرح اختيارك في فقرة قصيرة.
3. مخطط مكونات: ارسم على الورق أو بأداة مجانية مخططا يوضح واجهة المستخدم وخدمة الحجز وقاعدة البيانات وخدمة الإشعارات، ثم اكتب وصفا عربيا لمسؤولية كل مكون.
4. سجل التزام: أنشئ مستودعا تجريبيا ونفذ ثلاثة تغييرات صغيرة مع رسائل التزام عربية دقيقة، ثم التقط صورة لسجل الالتزامات من دون إظهار بيانات شخصية.

متوسط

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

متقدم

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

مجالات تعلم مرتبطة

هندسة البرمجيات تحليل المتطلبات معمارية البرمجيات اختبار البرمجيات التحكم بالإصدارات التكامل المستمر جودة البرمجيات إدارة المشروعات البرمجية أمن البرمجيات

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

مسرد

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