المهارات التي تنقص المطورين المبتدئين (قائمة تحقق عملية)

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

ما هي المهارات التي تنقص المطورين المبتدئين فعلياً؟

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

• العمل مع git — التفرّع، انضباط الـ commits، وحل التعارضات بهدوء.
• كتابة الاختبارات — لكودك الخاص، لا فقط جعله يعمل مرة واحدة.
• مراجعة الكود — شرح منطقك وتقبّل الملاحظات دون دفاعية.
• التواصل الكتابي — تقارير الأعطال، أوصاف طلبات الدمج (PR)، وتحديثات الحالة غير المتزامنة القائمة بذاتها.

إلى أي مدى تفهم git فعلاً؟

معرفة الأوامر (`add`، `commit`، `push`) ليست هي نفسها فهم سير العمل. المطوّر المبتدئ الذي يدفع تعديلاته مباشرة إلى الفرع الرئيسي، ويكتب رسائل commit مثل "إصلاح" أو "تعديلات"، ويتجمد لحظة ظهور تعارض دمج (merge conflict) يشكّل عبئاً على الفريق مهما كانت جودة كوده. ما يهم فعلياً هو العمل ضمن فرع (branch) مستقل حتى لا يعطّل العمل غير المكتمل أحداً آخر، وكتابة رسائل commit تشرح لماذا تم التعديل لا فقط ماذا تغيّر، والقدرة على فتح ملف متعارض، قراءة النسختين، وحلّ التعارض بوعي بدلاً من التخمين والأمل بأن يعمل الكود.

هل سبق أن كتبت اختباراً لكودك الخاص؟

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

هل تجيد إعطاء مراجعة الكود وتقبّلها؟

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

هل تواصلك الكتابي واضح بما يكفي للعمل غير المتزامن؟

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

كيف تبني هذه المهارات قبل أن تحصل على وظيفة؟

• افتح عدداً من طلبات الدمج (pull requests) على مشروع مفتوح المصدر حقيقي — عملية المراجعة هناك تعلّمك سير عمل git ومراجعة الكود معاً.
• أضِف مجموعة اختبارات أساسية لمشروع شخصي، مهما كان صغيراً، ودوّن الحالات الحدّية التي فكّرت في اختبارها.
• تدرّب على كتابة وصف طلب دمج وتقرير عطل لمشاريعك الشخصية وكأن شخصاً غريباً سيتصرف بناءً عليهما دون أي سياق إضافي.
• اطلب من زميل مراجعة كودك وطبّق فعلياً ملاحظة واحدة على الأقل لا توافقه عليها، لتبني عادة فصل الأنا عن نتيجة العمل.