ابدأ التنقيح debugging باختبار الاحتمالات الأسهل في التحقق

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

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

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

مثال عملي علي هذا ما حدث معي في الفترة الماضية؛ حيث كنتُ أعمل علي تطبيق سيستخدمه موظفو الأمن في فرع vodafone في مصر، و كنتُ في أحد الليالي أقوم بالتأكد من أن البرنامج يعمل جيداً علي الجهاز الذي تخصصه vodafone للاختبارات، و ذلك الجهاز كان عبارة عن حاسوب يعمل بـWindows XP موجود في المبني الرئيس لفرع vodafone في "القرية الذكية"، بحيث يمكن للشركات التي تقوم ببناء تطبيقات لـvodafone أن تلج إليه في أي وقت باستخدام برنامج TeamViewer، و باستخدام ذلك الجهاز يمكن للمبرمج أن يقوم بالتعامل مع خادم يعمل بنظام unix مخصص بدوره للاختبارات. كما كان بالإمكان استخدام جهاز الـwindows للولوج إلي جهاز آخر يتم استضافة قواعد البيانات الاختبارية عليه.

المهم أنني في تلك الليلة كنتُ قد أنهيتُ عمل الـdeployment للبرنامج، و تأكدتُ من أن كل الملفات مرفوعة علي جهاز الاختبار و مُنصَّبة علي جهاز الـunix، و أن قاعدة البيانات بها بيانات الاختبار التي سنتمكن من خلالها من عرض إمكانيات البرنامج علي من سيستخدمونه. و لكن حينما قمتُ بتجربة عمل البرنامج وجدتُه في ظروف معينة لا يقوم بالعمل بشكل صحيح، بل يُلقي بـ"null pointer exception" نظراً لأنه يُصادِف قيمة null في أحد الأوامر التي يقوم بها !، و الإشكالية كانت أن لديَّ نفس البرنامج بنفس الهيئة علي جهازي الذي أقوم بالتطوير، عليه و لم تظهر هذه المشكلة في أي مرة أجريتُ فيها نفس الاختبارات من قبل و من بعد !

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

المهم أنني قمتُ بالبحث عن صحة هذا الاحتمال و أنا أظن أنه في الغالب سيكون إضاعة للوقت؛ ففي نهاية الأمر لسنا نلعب مع أطفال صغار في الشارع لنجد مثل هذه الحماقات و الألعاب الصبيانية. و لكن (و لدهشتي الشديدة) وجدتُ أن هناك سجل record في جدول table داخل قاعدة البيانات قم تم حذفه، و أهمية هذا السجل أنه (مع بقية سجلات ذلك الجدول) يحمل قيمة ثابتة يقوم البرنامج بقراءتها بشكل دوري و الاعتماد عليها في عمله. و بالطبع حينما كان التطبيق يقرأ القيمة الغير موجودة كانت تعود بـnull، و هكذا يقع الغلط الذي حيرنا كثيراً.

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

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