مقدمة في هندسة البرمجيات

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

هذا المقال هو الأول في سلسلة مخصصة لأساسيات هندسة البرمجيات.

مقدمة في هندسة البرمجيات: التعريف والمعنى

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

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

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

• التخطيط
• التحليل
• التطوير
• التنفيذ
• البرمجة
• التصميم
• الاختبار
• التحقق والتحقق الصحي (V&V)

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

إذا كنا نتحدث عن هندسة البرمجيات، فمن الطبيعي أن نحدد مصطلح "البرمجيات" أيضًا. تعرّف ويكيبيديا، نقلًا عن معيار ISO/IEC 2382:2015، البرمجيات بأنها "مجموعة من برامج الحاسوب والوثائق والبيانات المرتبطة بها. وهذا على النقيض من العتاد، الذي يُبنى منه النظام والذي يقوم بالعمل.".

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

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

طبقات البرمجيات

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

الأجهزة

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

البرنامج الثابت (BIOS)

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

Hypervisor

يُعد برنامج المحاكاة الافتراضية أداة أساسية لإدارة عمليات المحاكاة الافتراضية – فهو برنامج ينشئ الأجهزة الافتراضية ويشغلها.

نظام التشغيل

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

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

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

Middleware

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

التطبيق

الطبقة البرمجية الأخيرة هي طبقة التطبيقات. يستخدم معظمنا التطبيقات على أساس يومي. ومن الأمثلة المثالية على التطبيقات متصفح الويب. ومن الأمثلة الأخرى MS Teams أو Outlook أو Excel.

أنشطة هندسة البرمجيات الأساسية

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

1. المواصفات: يحتاج مهندس البرمجيات إلى مواصفات لبدء عمله. عادةً ما تكون المواصفات نوعًا من الوثائق التي تساعدك على فهم ما يُفترض أن تقوم به البرمجيات.

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

3. التحققفي هذه المرحلة، يتم التحقق من البرمجيات الفعلية مقابل المواصفات المقابلة.

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

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

هندسة البرمجيات مقابل علوم الحاسوب

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

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

هندسة الأنظمة مقابل هندسة البرمجيات

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

لتوضيح المفهوم ورسم حدود بين الجزء البرمجي وغير البرمجي من النظام، يمكننا النظر إلى مثالين:

رقم 1 – سيارة حديثة ونظام ABS (نظام الفرامل المانعة للانغلاق)

يتضمن الهيكل المبسّط لمثل هذا النظام:

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

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

رقم 2 – نظام مصرفي لإدارة القروض

لكوني لست خبيراً مصرفياً، يمكنني أن أتخيل، على سبيل المثال:

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

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

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

البنية المعمارية العامة لنظام البرمجيات

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

إن أبسط بنية نظام لمظام برمجي حديث هي بنية العميل-الخادم. وهناك عنصران أساسيان:

• العميل – ليس الشخص الذي يستخدم الكمبيوتر، بل تطبيق يعمل على ذلك الكمبيوتر
• الخادم – ليس الخادم الفعلي، بل التطبيق الذي يعمل على الخادم والقادر على معالجة الطلبات الواردة من العميل.

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

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

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

بنية ثلاثية المستويات

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

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

لذا يمكن وصف المستويات الثلاثة بإيجاز على النحو التالي:

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

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

بدون خادم (سحابي)

هل من الممكن الحصول على نظام حديث دون خادم؟ بنية بلا خادم؟

إلى حد ما، نعم – السحابة هي الكلمة المفتاحية!

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

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

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

المرونة وقابلية التوسع مع نموذج سحابي

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

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

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

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

الاستقرار

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

ادفع مقابل ما تحتاجه فقط

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

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