السلام عليكم ورحمة الله،
اللهم إلا إن كنت أحد كهنة زِن الذين يستطيعون التركيز والارتفاع عن الأرض، فعلى الأغلب أنك قد ارتكبتَ على الأقل خطأ ما أو أكثر في برامجك التي كتبتها (تسمى بقّات bugs في العالم البرمجي). والمبرمج الناضج هو ذلك الذي يسارع للاعتراف بأخطائه وتعددها، بينما المبرمج المبتدئ على الأغلب يحتفظ بعزة نفس تمنعه من تقبل أن الخطأ هو من الكود الذي كتبه.
اسأل أي مبرمج مبتدئ في الشارع وسيعطيك سيل لا ينتهي من المبررات الممتعة: المستخدم جاهل! نظام التشغيل سيء! اللغة بلهاء ولا تستطيع فهم تفكيره المتقدم! خطأ في المترجم! صانع اللغة أحمق! فيروس في الجهاز! الكود الذي سرقه من أحدهم هو المخطئ! وهكذا...
عندما نتخطى هذه المرحلة ونتواضع لنعترف بأن برامجنا خاطئة حتى يثبت العكس، عندها ننتقل للخطوة التالية: كيف نكشف هذه الأخطاء قبل تصديرها للمستخدمين؟
هنا يا سيدي الكريم تبرز أهمية أدوات تتبع الأخطاء ( debugging tools)، والتي تعدّ طوق النجاة لنا معشر المبرمجين، وبدونها نعود للعصر الحجري ونتتبع الأخطاء باستخدام أسلوب printf اللعين.
إذا لم تكن تعرف ما هو ال debugger من قبل، فاسمح لي أن أعرفك به سريعاً (كما أنك مدين لي الآن بحياتك البرمجية). ببساطة ال debugger هو أداة تتيح لك مراقبة سير برنامجك عن كثب ومعرفة حالته في أية لحظة.. سيعطيك معلومات مثل مكان التنفيذ الحالي في البرنامج، قيم المتغيرات والذاكرة، سجل النداءات التي أوصلت البرنامج لوضعه الحالي، ورسائل عديدة عن أية أخطاء أو تجاوزات يرتكبها البرنامج. ببساطة، هو المجهر الذي تختبر برنامجك تحته.
أدوات تتبع الأخطاء هذه مطلوبة في كل جوانب البرنامج. وهذه الجوانب تتعدد في البرامج الحديثة. مثلاً، مواقع الإنترنت على الأغلب تستخدم عدة تقنيات برمجية وليس لغة برمجة واحدة (مثلاً جافاسكريبت و php). قد تكون بعض الألعاب محظوظة باستخدامها لغة واحدة (مثلاً سي شارب لأغلب ألعاب يونيتي)، لكن هذا محصور للألعاب البسيطة. بل إن الألعاب تتعامل مباشرة مع معالج إضافي غير المعالج المركزي، ألا وهو معالج الرسوميات GPU. وهو أيضاً يقوم بتنفيذ كود معقد ويسهل ارتكاب الأخطاء فيه. بل العديد يجدون أن أخطاء معالج الرسوميات من أكثر الأخطاء غموضاً وإحباطاً. ولكن مع كل ذلك، وحتى الآن، لا يوجد برنامج تتبع أخطاء كامل القدرات لتتبع أخطاء معالج الرسوميات. على كلٍّ سنعود لموضوع معالج الرسوميات بعد قليل.
كم هو مزعج ومحبط أن تبذل الوقت والتفكير في كتابة الكود، ثم تنفذه وتفاجأ برسالة خطأ صماء، تجعلك تعود وتشكك في كل ما كتبته وتضرب أخماساً بأسداس حتى تخمن مصدر الخطأ. خبرتي الشخصية جعلتني أتخلى عن مجرد محاولة تشغيل برنامجي خارج ال debugger بعد أن أفرغ من كتابة الكود لأول مرة.
من حسن الحظ أن أغلب التقنيات البرمجية الشائعة لها أدوات تتبع أخطاء مرفقة معها (مع بعض الاستثناءات التي سنمر عليها بعد قليل). وهذه نقطة تستحق التوقف عندها قليلاً... لأن التقنيات الداخلية (أو الغير منتشرة) قليلاً ما تحظى بأدوات تتبع أخطاء. ولعمري هذا واحد من أهم أسباب كراهيتي لاستقدام مثل هذه التقنيات في مشاريعي البرمجية. ولكن ستفاجأ بمقدار المبرمجين الذين يسلكون هذا الطريق في مشاريعهم. ودعني أتحدث عن المشاريع التي تقع ضمن اختصاصي: الألعاب.
كم لعبة استخدمَتْ لغة سكريبت خاصة بها؟ بل حتى إن بعض تقنيات السكريبت المنتشرة في الألعاب مثل "لوا" (LUA) لم تحظى بوسائل تتبع أخطاء احترافية إلا بعد فترة طويلة من تطويرها وانتشارها. أو خذ مثلاً نظام كيزميت (Kismet) الأصم في محرك أنريل ٣، أو حتى لغة UnrealScript في المحرك نفسه. تخيل! لغتَي سكريبت في محرك واحد وكلتاهما بدون أدوات تتبع أخطاء!
على درجة ربما أقل، نجد التقنيات البرمجية التي يحاول أصحابها دعمها بأدوات تتبع أخطاء، إلا أن هذه الأدوات نفسها مليئة بالأخطاء. ويشرفني هنا استخدام محرك يونيتي كمضرب مثل. في هذه الحالة نحن نتحدث عن محرك واسع الانتشار ويستخدم لغة برمجة شهيرة وهي سي شارب #C (رفقاً بالمحرك سأتناسى الفترات التي كان يستخدم فيها نسخته الخاصة من جافا سكريبت أو لغة بوو التي اندثرت بستين داهية من غير رجعة).
فعلى الرغم من أن لغة سي شارب يقف وراءها فيجوال ستوديو العملاق كواحد من أفضل ال debuggers في ��لعالم، إلا أن طريقة تكامل السي شارب مع يونيتي جعلت من تتبع أخطاء ألعاب يونيتي في فيجوال ستوديو مغامرة في المجهول. السبب في ذلك يعود لاستخدام تقنية مونو (Mono) للربط بين المحرك ولغة سي شارب، لكن هذه التفصيلة لا تهمني كمستخدم نهائي أبني لعبتي في محرك يونيتي. المهم هو أن أستطيع في أية لحظة تشغيل اللعبة والتحقق خطوة بخطوة من سير وحالة الكود. لكن ما نحصل عليه في الواقع هو نسخة debugger معوّقة في فيجوال ستوديو. فهذا ال debugger يعمل ببطء، يعطي قيماً محوّرة عن الواقع أحياناً، يفشل في الخطيّ في الكود عند أماكن معينة، وينهار هو نفسه متى ما شاء أو يتسبب بانهيار فيجوال ستوديو بأكمله. وهذا الكلام من خبرتي الشخصية في المحرك إلى أن تركت العمل في شركة يونيتي في العام السابق.
الآن ننتقل للاحتجاج على أدوات تتبع الأخطاء لبرمجة الرسوميات الفورية.
ستفاجأ يا سيدي الكريم أنّ أقدَم وأكبر التقنيات إرثاً في عالم الرسوميات تفتقد حتى الآن لأدوات تتبع أخطاء محترمة... نعم... اسمح لي أن أقدم لك أوبن جي إل (OpenGL)... العجوز الذي ظهر منذ بدايات التسعينات في القرن الماضي والذي يصر على التعمير كملكة بريطانيا حتى الآن من خلال نظام أندرويد الذي يشغل أكثر من نصف الأجهزة الصغيرة في العالم.
منذ أن ظهر أوبن جي إل وحتى السنتين الأخيرتين، لم تتوافر وسائل محترمة لتتبع الأخطاء في هذه التقنية. بقيت مفقودة لثلاثة عقود عجاف! إلى أن جاء شخص وحيد يدعى بالدر كارلسن قام بتطوير أداة تدعى ريندر دوك (RenderDoc) متخصصة بتتبع أخطاء الرسوميات، ونجحت بالسماح لشريحة معينة من برامج أوبن جي إل أخيراً بأن توضع تحت المجهر ويتم تشريحها بطريقة علمية نوعاً ما.
يبدو أن تتبع الأخطاء ترفٌ يجب ألا نتوقعه. في حالة دايركت ثري دي (Direct3D) فإن ما أنقذ الموقف هو صدور جهاز إكس بوكس لأول مرة، والذي يعتبر من أنجح خبرات التطوير على الإطلاق حتى الآن بين منصات الكونسول. فقد تم دعم هذه المنصة بطقم أدوات تطوير كاملة مستقرة موثوقة واحترافية، شاملة لأول مرة برنامجاً يدعى بيكس (PIX) - اختصاراً ل (Performance Investigator for XBox). هذا البرنامج الرائع تم نقله سريعاً إلى منصة الويندوز، ليصبح دايركت ثري دي ٨ أول إصدار سعيد الحظ يدعم تتبع أخطاء الرسوميات بشكل رسمي، ويستمر برنامج بيكس حتى الآن على كل من إكس بوكس وويندوز بتحديثات دورية لدعم آخر مزايا الرسوميات الفورية كتتبع الأشعة (raytracing).
الحديث عن هذه الأدوات لا ينتهي، وعلى الرغم من أنني أحب الثرثرة عنها إلا أنني لا أريد أن أطيل هذه التدوينة أكثر من هذا. لذلك سنتوقف هنا اليوم، وربما نعود لاحقاً ما لم تنكمش الكرة الأرضية أو تنفجر الرؤوس النووية في مخازنها وتودينا في ستين داهية في خضم قطار الكوارث الذي لا يبدو أنه ينوي التوقف.
في النهاية الرسالة بسيطة: ابتعد عن التقنيات التي لا تدعمها أدوات تتبع أخطاء محترمة، وإلا على نفسها جنت براقش!
والسلام عليكم ورحمة الله!