درسی از یک نرم افزار ۱۵ دقیقه ای

یکی از دوستانم (که برنامه نویس نیز نبود) آرشیو موسیقی مفصلی داشت. یک روز این موضوع برایش پیش آمد که بتواند فایل های صوتی تکراری موجود در هارد دیسکش را یافته و تصمیمی راجع به آنها بگیرد. شروع کرده بود به این که لیست فایل ها را بررسی کند و به صورت دستی فایل های تکراری را پاک کند. بعد از مدت کوتاهی از من پرسید: فرید امکان این وجود دارد برنامه ای بنویسی که فایل های تکراری را پیدا کرده و لیستی از انها به من نمایش دهد؟ چون تعداد فایلهای موجود در آرشیو من خیلی زیاد است.

نرم افزار 15 دقیقه ای

به او گفتم کار سختی نیست. امتحان میکنم. بعد از آن در حدود ۱۵ دقیقه (زمان کار را با toggl.com ثبت کردم) توانستم برنامه ساده ای بنویسم که در درایو خاصی فایل های صوتی تکراری را پیدا کرده و در یک فایل متنی گزارشی به کاربر ارائه دهد.

دوستم از نرم افزار استفاده کرد و با توجه به این که تعداد فایها صوتی موجود در آرشیو او بسیار زیاد بود، این برنامه کمک زیادی در یافتن فایل های تکراری بر اساس نام، به او کرد.

بعد از دیدن عکس العمل دوستم در مورد نرم افزار خیلی ساده ای که تهیه شده بود به این نکته بیشتر فکر کردم که موفقیت یک پروژه نرم افزاری (چه کوچک چه بزرگ) به این که چه مقدار کار فنی عجیب و غریبی برای آن انجام شده است وابسته نیست. یا به این که چه فناوری هایی در آن استفاده شده است.

عامل اصلی در موفقیت یک پروژه نرم افزاری استفاده درست از فناوری های موجود جهت رفع نیازهای اصلی کاربر هدف است.

در صورتی که نیاز اصلی کاربر رفع نشده باشد. واقعا مهم نیست که چه فناوری هایی و چه معماری های مرتبط و منظمی در نرم افزار استفاده شده است.

این درسی بود که من گرفتم از نیاز ساده یک دوست.

خوب باگ بزنیم (Useful bug reports)

مبحث گزارش خطا یا به اصلاح دنیای نرم افزاری آن باگ زدن (bug report) در تمامی رشته ها و در تمامی محصولاتی که به صورت روزمره از آنها استفاده می کنیم وجود دارد. خطا یا خرابی همیشه وجود داشته و خواهد داشت. مهارت این که به صورت سازنده خطاها و خرابی های یک محصول را به دست اندکاران آن برسانیم نیز مهارت مهمی است. بهتر است نگاهی اجمالی به نکات سازنده در ثبت خطا یا همان باگ زدن داشته باشیم.

چرا خوب گزارش دادن باگ اهمیت دارد؟

مهمترین دلیل آن صرفه جویی در زمان است. فرض کنید یک برنامه نویس که شما اصلا آن را ندیده اید قرار است باگ ثبت شده توسط شما را (شاید مدت ها بعد از زمانی که شما آن را ثبت کرده اید) رفع کند. او هیج گونه آشنایی با پیش زمینه های ذهنی شما در زمان مشاهده باگ ندارد.و با نحوه نگارش شما هم آشنا نیست. پس باید پروتکل ثابتی وجود داشته باشد که او متوجه جزئیات خطایی که شما ثبت می کنید شود.

فاکتور های متفاوتی در سازمان ها وجود دارند که خصویات یک باگ یا به طور کلی (work item) را مشخص می کنند. ولی به طور کلی هر باگ می تواند شامل اطلاعات زیر باشد.

  • عنوان
  • مراحل ایجاد دوباره باگ و نتایج آن
  • اطلاعات فنی مورد نیاز برای بررسی باگ در محیط ایزوله شده (مانند backup پایگاه داده و …)
  • اولویت باگ
  • شدت باگ

بخش های متفاوت دیگری حتما در بدنه هر باگ وجود دارد به طور مثال این که مربوط به چه سیستمی است و …

عنوان

عنوان باگ یکی از مهمترین بخش های باگ است. عنوان باگ باید به حدی ساده و قابل فهم باشد که با نگاهی سر سری به آن اطلاعات کلی در مورد مکان مشاهده و نحوه مشاهده باگ به برنامه نویس مربوطه بدهد.

همیشه این گونه تصور کنید که کسی آن طرف پنل مدیریت lifecycle نرم افزار قرار دارد (هر سیستمی که هست مثلا TFS) باید عنوان باگ ها به گونه ای انتخاب شود که او به راحتی و با گذر سریع چشمی بتواند باگی را به کسی (یا تیمی) به صورت اولیه assign کند. اگر عنوان به خوبی انتخاب نشود حتما آن فرد (هر کسی که هست) با مشکلات عدیده ای مواجه خواهد شد.چند نمونه از عنوان های خوب و بد را بررسی خواهیم کرد

بد: فرم ویرایش کالا کار نمی کند.

خوب: عدم ذخیره سازی تغییرات دسته بندی ها در فرم ویرایش کالا

بد: enter کار نمی کند.

خوب: دکمه enter در هنگام  inline editing در گرید کالاها فوکوس را به فیلد بعدی نمی برد

مراحل ایجاد دوباره باگ

قبل از این که اقدام به ثبت باگ جدید بکنید ابتدا تمام سعی خود را انجام دهید که الگوی ایجاد کننده باگ را پیدا کنید. اگر این مرحله درست انجام نشود به احتمال زیاد چیزی برای گفتن در متن باگ نخواهید داشت.

پس از اینکه الگوی باگ را پیدا کردید نیاز است که مراحلی که منجر به برخورد با باگ می شوند را یادداشت کنید. این مورد خیلی مهم است. مراحلی که تهیه میکنید باید خیلی دقیق و کارا باشند.

به عنوان برنامه نویس تنها اطلاعاتی که نیاز دارم تا بتوانم باگ را رفع کنم آیتم های زیر هستند

  • مراحلی که نیاز است باگ را ببینم.
  • نتیجه ای که کاربر انتظار داشت ببیند.
  • چیزی که الان می بیند.

برای نوشتن مراحل به صورت دقیق همیشه بررسی کنید که آیا تمام مراحلی که انجام داده اید برای ایجاد باگ الزامی بوده اند؟ سپس مراحل را یک به یک و واضح یادداشت کنید. الگوی مشخصی برای نوشتن این مراحل وجود ندارد. فقط وضوح را همیشه رعایت کنید.

نکته: اگر در جایی برای توضیح دادن مراحل ایجاد باگ یا نتایج مشکلی در نگارش دارید بهترین گزینه تصویر یا حتی فیلم ای است که از نسخه مورد بررسی تان گرفته اید.

یک نمونه از مراحل ایجاد باگ که خوب نوشته شده است به صورت زیر است. البته هیچ قانون مشخصی برای نوشتن جزئیات در این مراحل وجود ندارد. و جزئیات بر اساس شرایط تیم قابل تغییر هستند

یک: انتخاب کالا از لیست کالا و درخواست ویرایش از منو

دو: ویرایش دسته بندی های کالا

سه: ذخیره تغییرات

اطلاعات فنی مورد نیاز برای بررسی باگ

این اطلاعات عموما شامل backup از پایگاه داده مربوطه یا اطلاعات محیطی مانند سیستم عامل، browser و غیره است.

نکته مهمی که اغلب فراموش می شود تنظیمات general یا تنظیمات مربوط به هر کاربر است. اگر حس می کنید (یا حتی وقتی حس نمی کنید!) که باگ ممکن است به دلیل پاره ای از تنظیمات محیطی یا داخلی نرم افزار است بهتر است، یک کپی از تمام متغیر های محیطی و تنظیمات در کنار باگ بگذارید. تا جایی که مسائل امنیتی بروز نکند.

نکته: یک سری ابزار برای گرفتن متغیر های محیطی وجود دارد. خوب است که نرم افزار شما امکانی مشابه برای dump گرفتن از تنظیمات داخلی خودش داشته باشد.

اولویت باگ

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

شدت باگ

شدت باگ در تعیین اولویت باگ تاثیر بسیار مهمی دارد. اسامی مختلفی در سازمان های مختلف برای شدت باگها می گذارند. ولی به صورت نسبی باگ ها را می توان از “باگ کشنده” تا باگ “پیشنهاد بهبود” دسته بندی کرد. (در میان این دو دسته، دسته های زیادی قرار خواهد گرفت). باگ کشنده باگی است که به هر صورتی مانع ادامه کار با نرم افزار می شود و پیشنهاد بهبود باگی است که معمولا در متن آن شاهد توضیحی مبنی بر این که ” بهتر است کار X انجام شود.” خواهیم بود.

نتیجه

باگ زدن یکی از مهمترین فعالیت هایی است که همه روزه برنامه نویس ها، تحلیل گرها، و مدیران پروژه را درگیر می کند. از ذات باگ امانی نیست. قطعا بهترین نرم افزار ها و محصولات دنیا هم همراه با اشکال خواهند بود. ولی فرایند درست و مدیریت شده برای انتقال این اشکالات به تیم تولید می تواند نقش مهمی در کیفیت کلی نرم افزار ایفا کند. پس خوب باگ بزنیم.