اشکال‌زدایی یکی از مشکلاتی بود که در حرفه برنامه نویسی با آن روبرو شدم. این باگ‌ها توسط آزمایش‌کنندگان، کاربران و یا خودم شناسایی می‌شدند. حل کردن برخی از این باگ‌ها به روش‌های متفاوتی نیاز دارد. برطرف کردن اشکالاتی که توسط کاربران شناسایی می‌شود، معمولاً دشوارتر است چون آن‌ها هیچ سررشته‌ای از باگ‌ها ندارند و نمی‌توانند جزئیات دقیقی را ارائه دهند.
در این مقاله می‌خواهم روش‌های خود را برای حل کردن این باگ‌ها به اشتراک بگذارم. امیدوارم این رویکردها برای برنامه نویسان ارزشمند باشد و بتواند روشی را برای حل مشکلات در اختیار آن‌ها قرار دهد. به عنوان یک نکته این موضوع را بگوییم که برنامه همواره می‌تواند با باگ‌های مختلفی برخورد داشته باشد اما یکسری باگ‌های همیشگی هستند که باید یک بار برای همیشه در برنامه حل شوند.
1. در مورد مشکل تحقیق کنید
کاربران معمولاً در توصیف کردن اشکالات ناتوان هستند. آن‌ها در گزارشات خود فقط می‌گویند که فلان چیز کار نمی‌کند. این توضیحات کمک چندانی نخواهد کرد زیرا قسمت درگیر شده به درستی توضیح داده نمی‌شود.
2. مقادیر مرزی را شناسایی کنید
مقدار مرزی به محدوده‌ای اطلاق می‌شود که الگوریتم باید در آن فعالیت داشته باشد. به عنوان مثال مقدار مرزی می‌تواند نمایه‌ای از یک آرایه باشد که در فیلد 0 تا 100 قرار دارد. مقادیری که بیرون از این محدوده هستند، باید نادرست در نظر گرفته شوند. بیشتر مواقع، اشکالات از مقادیر مرزی نشات می‌گیرد زیرا الگوریتم به دلیل اجرای نادرست با مشکل مواجه خواهد شد.
3. علت دشوار بودن بازتولید یک مشکل را بررسی کنید
معمولاً ماهیت اشکالات به خودی خود شامل سرنخ‌هایی هستند. آیا فایلی از شبکه‌های در دسترس سیستم گم شده است؟ آیا کاربر مورد نظر فاقد مجوزهای لازم است؟ آیا شبکه ناپایدار شده است؟ آیا پارامترهای پیکربندی یا مسیرهای خاصی در توالی داده‌های لازم برای دسترسی به اطلاعات گم شده است؟ به یاد داشته باشید که همیشه سرنخی برای پی بردن به ماهیت مشکل وجود دارد. گاهی اوقات با بررسی کردن محلی که مشکل در آن دیده شده، می‌توانیم به راهکارهای مفیدی دست پیدا کنیم. باید اطلاعات ارسالی از کاربران را به دقت مورد بررسی قرار دهیم زیرا آن‌ها معمولاً در توضیحات خود انتزاعی عمل می‌کنند.
4. اگر اشکالات تنها برای یک ماشین یا کاربر خاص رخ می‌دهد، احتمالاً محیط یا پیکربندی آن تفاوت دارد
تنظیمات سیستم عامل، محیط نرم‌افزار، نسخه‌های استفاده شده از کتابخانه‌ها و هر چیز دیگری که بتواند روی سیستم تاثیر گذاشته و در دستگاه کاربر متفاوت باشد، نشان‌دهنده مسیر پیش‌روست؛ مخصوصاً اگر نتوانیم مشکل را در سایر دستگاه‌ها بازتولید کنیم.
5. پیدا کردن ارورهای مربوط به چندوظیفگی و اشتراک منابع، دشوار است
چندوظیفگی با استفاده از یک منبع مشترک سعی دارد فرآیندها را به طور همزمان اجرا کند. این موضوع باعث بی‌ثباتی داده‌ها می‌شود زیرا فرآیندها به طور جداگانه انجام داده نمی‌شوند. برای حل این موضوع می‌توانید بخش بحرانی در مشکل را مشخص کرده و برای اطمینان از قفل‌های نرم‌افزاری استفاده کنید. بخش بحرانی به مناطقی گفته می‌شود که در آن تنها یک کار به طور همزمان انجام داده می‌شود. داده‌های ناهمخوان، ناشی از بخش‌های بحرانی برنامه نویسی نشده هستند.
6. اگر ردیابی ارور با تمام این استراتژی‌ها امکان‌پذیر نیست، باید روش‌های خاص دیگری را پیاده‌سازی کنیم
پردازنده اینتل در محاسبات ممیز شناور خود دارای یک باگ بود که توسط پروفسوری در سال 1994 کشف شد. برخی از ورودی‌ها در جداول محاسباتی پردازنده وجود نداشتند. این خطا به قدری کمیاب بود که میلیون‌ها نفر بدون پی بردن به آن از پردازنده استفاده می‌کردند. بدون اینکه بتوان این اشکالات را مشاهده کرد، چه کسی می‌توانست از تعداد محاسبات نادرست در رندر کردن تصاویر، محاسباتِ برداری یا بازی‌ها مطلع شود.
اینتل در ابتدا قصد نداشت پردازنده‌های جدیدی را به این کاربران بدهد. اما آن پردازنده‌ها مطمئن نبودند و می‌توانستند شهرت اینتل را به خطر بیاندازند، به همین خاطر اینتل تصمیم گرفت پردازنده‌های معیوب کاربران را با پردازنده‌هایی جدید تعویض کند. اگر در ردیابی کردن مشکل موفق نبودیم، می‌توانیم از «log» در کدها استفاده کنیم. فرضاً ما قطعه کدی که باعث این مشکل شده را پیدا کرده‌ایم، اگر log را در کنار این اسنیپت قرار دهیم، می‌توانیم به تمام شرایط مربوط به بازتولید آن خطا دست پیدا کنیم.
شما معمولاً تا حدودی با ماهیت یک خطا آشنا هستید و شرایط لازم برای بررسی آن را می‌دانید. معمولاً یک log باید بخشی از هر سیستم باشد. برای ردیابی کردن یک شرایط خاص می‌توانیم ثبت وقایع (logging) دشوارتر و مفصل‌تری را به صورت موقت فعال کنیم. اضافه کردن test condition به برنامه، امکان ضبط و بررسی خطاها را به ما می‌دهد زیرا در صورت مشاهده هرگونه شرایط مشکوکی به ما هشدار خواهد داد.
7. بعضی‌ها سخت‌افزار را سرزنش می‌کنند
مموری‌های بی‌ثبات می‌توانند باعث ایجاد نتایج نامشخصی شوند. این مشکلات علاوه بر خود برنامه، رفتار کامپیوتر را نیز به طور کلی تحت تاثیر قرار می‌دهند. با کنار هم قرار دادن سلسله مراتبی از مشکلات متداول و کم‌تکرار می‌توانیم این فرضیه‌ها را مد نظر قرار دهیم.
8. درست کد نوشتن را یاد بگیرید
مدل‌سازی ضعیف داده‌ها، نبود اعتبارسنجی فرضیات در کد، برنامه نویسی ضعیف، عدم استفاده از متدهای درست انسجام و اتصال می‌تواند منشا بسیاری از مشکلات باشد. کدهایی که به خوبی نوشته شده باشند، کمتر دچار خطا خواهند شد.
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید