خمس خطوات لوصف مشكلة برمجية لا يمكن حتى لمبرمج محترف حلّها

مقدمة

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

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

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

اجعل سؤالك للبحث عن خبير وليس عن الحل

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

هذا النوع من الرسائل/الأسئلة شائع جداً في أي مجموعة خاصة بالمبرمجين وخاصة عند المبتدئين. فبدلاً من طرح المشكلة مباشرة يبدأ السائل بالسؤال عن شخص ليساعده ومن ثم شرح المشكلة له إما بشكل خاص او ضمن التعليقات. فمن الأسرع والمفيد الدخول في صلب الموضوع وطرح السؤال كاملاً مباشرة؛ فيجيب من يستطيع أن يجيب مباشرة في التعليقات ومن لا يستطيع يمكنه تجاهل المنشور والبحث عن سؤال يستطيع الإجابة عليه. وبذلك يستفيد أيضاً من لديه نفس المشكلة.
لقد انتشر هذا السؤال لدرجة إنشاء موقع إلكتروني باسم “Don’t ask to ask” لتوضيح هذه المشكلة التي يقع بها المبتدئون عندما يسألون.

لا تقرأ رسالة الخطأ قبل إرسالها

مثال: لقد حدث معي هذا الخطأ
“Error: the variable XYZ is not defined in filename.php at line 15”

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

تذكر أنك أول شخص يواجه هذه المشكلة في العالم

مثال: إنني أحاول الاستفادة من مكتبة برمجية ولكنها لا تعمل وتكتب لي هذا الخطأ
”error: couldn’t initialize XYZ service. Error code: XYZ_SERVICE_INIT_FAILED in LibraryName/file.php at line 1345″

في بعض الأحيان تكون رسالة الخطأ مبهمة او تتضمن مصطلحات لم يستطع المبرمج فهمها أو حتى أن الخطأ موجود في ملف لم يقم المبرمج بكتابته كأن يكون الخطأ داخل كود مكتبة برمجية. وهنا يجب أولاً البحث عن رمز الخطأ الذي ظهر على Google او في قسم FAQ ضمن موقع المكتبة او على صفحة الissues الخاصة بها على Github وأخيراً وليس آخراً Stackoverflow. لأنه غالباً أن هذه المشكلة قد حدثت مع مئات (إن لم يكن آلاف) المستخدمين الآخرين وقد بلّغوا عن هذه المشكلة على إحدى المنصات وقد وصلوا إلى حل أو شرحوا سبب المشكلة. لذلك استثمار 10 دقائق في البحث سيوفر 90 دقيقة من الشرح والسؤال والانتظار.

ساعات من السؤال ستوفر عليك 5 دقائق من قراءة مستند التوثيق (Documentation)

مثال: أنا أواجه مشكلة عند مكاملة/إضافة المكتبة الفلانية في مشروعي؟

مكاملة المكتبات والحلول هو جزء اساسي في حياة كل مبرمج والحمد لله أن للمكتبات مستند (Documentation) يشرح كيفية استخدامها وحالات الاستخدام المتعددة وطرق المكاملة والتنصيب وقد يتضمن أيضاً بعض الأسئلة الشائعة والمشاكل المتوقع حدوثها. ولكن … القراءة مملة والمستند طويل ونحن على عجلة فمن الاسرع تخطي خطوة القراءة ومحاولة استنتاج كيفية استخدام المكتبة او قراءة الاسطر الأولى من التوثيق بحيث نقرأ أقل قدر ممكن للبدء باستخدام المكتبة أو مشاهدة فيديو على يوتيوب يشرح كيفية استخدامها ومن ثم مواجهة بعض الأخطاء وسؤال الأصدقاء او الزملاء في العمل أو حتى على مجموعات البرمجة على منصات التواصل عن حل هذه المشاكل مما سيؤدي لهدر الكثير من وقتك الثمين.نصيحة: لا تنشر سؤالك قبل أن:

• تتأكد من قراءة مستند التوثيق (بالأخص القسم المتعلق بمشكلتك) أكثر من مرة.
• مراجعة الخطوات التي قمت بتنفيذها مرة أخرى.
• البحث ضمن ضفحة المشكلات (issues) عن سؤال مشابه

اسأل عن الحل الذي تراه مناسباً وليس عن المشكلة

مثال: كيف أستطيع اقتطاع آخر ثلاثة محارف من سلسلة (String) بلغة PHP؟

تعرف هذه الحالة باسم “مشكلة XY” في هذه الحالة يكون طارح السؤال يحاول حل مشكلة معينة “X” (في مثالنا: استخراج اللاحقة من اسم الملف) ولكنه يظن أنه وجد الحل وهو استخراج آخر ثلاثة محارف “Y” ولكنه لم يستطع فعل ذلك أيضاً! فيطلب المساعدة لتطبيق الحل الذي يظنه صحيحاً “Y” دون ذكر المشكلة الأساسية “X” فبعد اهدار الوقت على حله المفترض “Y” يتبين أنه يبحث عن حل للمشكلة “X”! لذلك يتوجب شرح الحالة وإظهار الصورة كاملة.
الأصح أن يكون السؤال: أريد استخراج اللاحقة من اسم ملف مخزن في متحول نوعه string وحاولت استخراج آخر ثلاثة محارف باستخدام الكود الموضح أدناه ولكن يظهر لي الخطأ الفلاني.

ملخص

حاول حل المشكلة بنفسك فإن لم تستطع فابذل جهدك عند السؤال وحتى يحظى سؤالك بالاهتمام المطلوب للإجابة عليه بسرعة يجب عليك:

1. شرح كيف حدثت المشكلة بالتفصيل
2. اكتب ماذا تتوقع أن يحدث؟
3. صف ما يحدث الآن؟
4. انشر الجزء المتعلق بالمشكلة من الكود مع السؤال
5. إن وجدت حلاً لمشكلتك انشر الحل مع السؤال