اگر برنامه‌نویسی می‌کنید و دیتابیسِ باگ ندارید همین حالا دست نگه دارید 1393/05/25

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

اگه شما برنامه‌نویس، طراح یا توسعه دهنده‌ی نرم‌افزار هستید از شما می‌خوام تا به این سوال ساده من جواب بدین که «در همین لحظه نرم‌افزاری که بر روی آن کار می‌کنید چند عدد باگ (bug) دارد؟». اگر نمی‌توانید عدد مشخصی در جواب سوال من بدهید و حتا اگر این عدد بزرگ باشه و یا بدونید که باگ‌هایی هست که چندین هفته از شناسایی اون‌ها گذشته ولی کاری روشون انجام نشده به احتمال زیاد پروسه برنامه‌نویسی شما با مشکلی جدی روبرو است. چگونه می‌خواهید مشکلات نرم‌افزارتان را حل کنید وقتی اطلاعات منسجم و دقیقی در مورد آنها ندارید؟

حال فرض کنید که من به شما خبر بدم که باگی در کدی که همین یک ساعت پیش نوشته‌اید پیدا کرده‌ام. اگر از شما این سوال را بپرسم که چقدر طول می‌کشد تا این باگ را رفع کنید به احتمال زیاد پاسخ شما «در حد چندین دقیقه» خواهد بود.
حالا این مورد را مقایسه کنید با وضعیتی که باگ پیدا شده توسط من، مربوط به کدی است که شما یک ماه قبل نوشته‌اید. حالا اگر سوالم را از شما تکرار کنم، به احتمال زیاد شما نخواهید توانست زمان دقیقی را برای رفع باگ تخمین بزنید. با این توضیح کوتاه می‌توان به این نتیجه رسید که هر چه باگ‌ها سریعتر شناسایی و رفــع شوند به همان مقدار سرعت تولید نرم‌افزار بیشتر می‌شود و هزینه نگهداری آن کاهش پیدا خواهد کرد.

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

از طرفی حساب کردن روی حافظه برنامه‌نویس‌ها جهت نگهداری باگ‌های موجود اشتباه بزرگی هست که خیلی از تیم‌ها انجام می‌دهند. بدون مرجعی که تمام باگ‌های شناسایی شده نرم‌افزار در آن نوشته شده باشد نمی‌توان اطمینان داشت که نرم‌افزار بدون ایراد است. علاوه بر اینکه هر فرد حضور ذهن و حافظه محدودی برای نگهداری باگ‌ها در حافظه خود دارد، اغلب در تیم‌ها باگ‌ها در بین حافظه افراد تیم پخش شده‌اند. به همین دلیل بایستی لیست تمام باگ‌ها را در فایل یا نرم‌افزاری نگهداری کرد که اون فایل رو باگ دیتابیس نام‌گذاری می‌کنیم. بدین ترتیب حداقل خیال‌مان راحت است که لیست کاملی از باگ‌های نرم‌افزار را داریم.

اگر فکر می‌کنید که نرم‌افزارهای موجود برای نگهداری باگ‌ها خیلی پیچیده هستند و این تنها دلیل شما برای نداشتن باگ دیتابیس است، خبر خوبی برای شما دارم. شما می‌تونید از یک فایل spreed sheet (همانند فایل‌های ایکسل) با چند ستون ساده استفاده کنید که این فایل از طریق سرویس‌هایی همچون Google drive قابل ویرایش توسط تمام افراد تیم باشد.

حالا سوال این هست که کمترین چیزی یک باگ دیتابیس باید داشته باشد چی هست؟
۱) نام یابنده باگ
۲) مسئول بررسی باگ
۳) وضعیت باگ (که یکی از این پنج حالت‌ است: باز / امکان بازتولید باگ وجود ندارد / در حال حل مشکل / حل شده / بسته)
۴) توضیحات باگ شامل: (الف) شرح قدم به قدم نحوه بازتولید باگ در محصول، (ب) اتفاقی که انتظارش می‌رفت که بیافتد ولی نیافتاده و (ج) اتفاقی غیرمنتظره‌ای که در حال حاضر می‌افتد.

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

۱) به قسمت امانت نرم‌افزار برو و کتابی را به عضوی امانت بده
۲) به قسمت اعضای کتابخانه نرم‌افزار برو و سعی کن همان عضو را حذف کنی
آنچه انتظار داشتم اتفاق بیافتد: برنامه به من اخطار دهد که امکان حذف عضوی که دارای امانت فعال است وجود ندارد.
آنچه به نادرست اتفاق می‌افتد: برنامه بدون دادن هیچ اخطاری عضو را حذف می‌کند و وضعیت آن امانت نامشخص می‌شود.

فرهاد به هر طریقی متوجه تعییرات در باگ‌دیتابیس می‌شود و به دنبال سطری می‌گردد که اسم او به عنوان مسول بررسی باگ نوشته شده. او توضیحات باگ را به دقت مطالعه می‌کند و سعی می‌کند باگ گزارش شده را بازتولید کند. در صورتی که توضیحات مراحل بازتولید باگ کافی نباشد او وضعیت باگ را به حالت «غیرقابل بازتولید» تغییر می‌دهد. در داستان ما نگار خیلی خوب مراحل بازتولید باگ را توضیح داده است و فرهاد وضعیت باگ را به «در حال حل مشکل» تغییر می‌دهد. پس از نیم ساعت فرهاد مشکل را کاملن حل کرده و وضعیت باگ را به حالت «حل شد» تغییر می‌دهد. توجه کنید که هنوز باگ «بسته» نشده است. در واقع تنها کسی که اجازه تغییر وضعیت باگ به حالت «بسته» را دارد یابند باگ یعنی نگار است. در این مرحله نگار پس از بررسی دوباره نرم‌افزار می‌تواند وضعیت باگ را در صورت حل مشکل به حالت «بسته» و در صورت حل نشدن به حالت «بـاز» برگرداند و توضیحاتی را برای فرهاد بنویسد.

هدف من از این نوشته یادآوری اهمیت باگ دیتابیس برای تولید محصول نرم‌افزاری بود. مهم نیست که شما محصولی را تک نفره تولید می‌کنید و یا اینکه عضوی از یک تیم ۵ نفره هستید، در هر حالت نمی‌توانید اهمیت باگ دیتابیس را جهت تولید نرم‌افزاری بدون‌ایراد نادیده بگیرید. با این اوصاف به نظر می‌رسد با توجه به توضیحاتی که در بالا خواندید در صورتی که تا به حال باگ دیتابیسی نداشته اید، کار را با فایلی کوچک شروع کنید و در صورت نیاز از نرم‌افزارهای موجود برای مدیریت باگ‌ها استفاده کنید.