نود و هفت چیزی که هر برنامه‌نویسی باید بداند: چگونه به یک باگ نگاه کنیم؟


برخی توسعه دهندگان برچسب «باگ» روی مسائل خارج از عرف نرم افزاری می‌گذارند و برخی دیگر صرفاً به «مشکل» اکتفا می‌کنند؛ خواه این مسائل را باگ بنامییم خواه مشکل، آن‌ها وجود دارند و به راحتی می‌توانند موفقیت نرم‌افزار ما را تحت الشعاع قرار دهند و یکی از مهارت های اصلی هر توسعه‌دهنده ی حرفه یی، این می‌تواند باشد که چگونه باگ های یک نرم‌افزار را رصد کند و تمام تلاش خود را به کار گیرد تا آن‌ها را مرتفع سازد.

برای رفع باگ ها، ما پیش از هر چیز به یک ‌Bug Report (باگ ریپورت) نیاز داریم تا بیش از پیش، با خصوصیات باگ احتمالی آشنا شده و دیگر اعضای تیم را نیز در جریان قرار دهیم؛ یک باگ ریپورت خوب از ویژگی‌های زیر برخوردار است:
- نحوه ی کار با نرم‌افزار به گونه یی که منجر به مشاهده ی باگ شود را ارائه می‌دهد؛ علاوه بر این، به ما می‌گوید که این باگ هر چند وقت یک بار پدید می‌آید.
- به نظر شما چه اتفاقی باید افتاده باشد که این باگ ایجاد شده؟
- گزارشی کامل از اتفاقاتی که رخ داده‌اند به منظور درک بهتر ماهیت باگ و در صورت امکان، ارائه ی دلیل اصلی پدید آمدن باگ

کمیت و کیفیت اطلاعاتی که ما از یک باگ پیدا می‌کنیم دارای ارتباطی مستقیم با فرایند Debugging (دیباگینگ یا رفع مشکل) است. به یاد داشته باشیم زمانی که با یک باگ در نرم‌افزار خود مواجه می‌شویم، تحت هیچ عنوان دست به انکار آن نزده و یا مشکل بوجود آمده را به گردن سایر اعضای تیم نیندازید! بلکه تا حد ممکن اطلاعات مرتبط در مورد باگ مربوطه کسب نمایید و در صدد رفع آن برآیید.

لیست نظرات
کاربر میهمان
دیدگاه شما چیست؟
کاربر میهمان
محسن
محسن
در مورد Debugging یک نکته خیلی مهم ثبت اطلاعات دقیق هست
اینکه باگ در چه مرحله ای از پروژه و در نتیجه چه فعالیتی کشف شده، حتی ثبت تاریخ هم همی تونه مفید باشه که بدونیم در چه زمانی از رشد پروژه این باگ وجود داشته
هست چون ممکن هست در ادامه بعضی از قسمت
بعد از اون ثبت اطلاعات مربوط به
Debugging
هست که فعالیت های انجام شده منجر به تغییر کدوم قسمت ها شدن، چون این احتمال وجود داره که بخش های دیگری از پروژه در نتیجه اینکار دچار مشکل بشن و در نتیجه نیاز باشه تغییرات برگرده به حالت اول و بعد با دقت بیشتری
Debugging بشه
بشه Debugging