معمولا بعد از اولین انتشار عمومی یک محصول نرم افزاری، شاهد هجوم گزارش های باگ از سمت کاربران هستیم. هیچ محصولی مطلقا بدون باگ نخواهد بود اما این موضوع برای تیم های نرم افزاری، ممکن است استرس آور باشد و آنها را دستپاچه کند. در این مواقع از دست دادن ابتکار عمل و انجام کار های نسنجیده ممکن است مشکلات شما را بیش از پیش افزایش دهد.
در این مقاله سعی دارم تجربه های خودم را در مواجهه با هجوم باگ ها در شرکت تحلیلگر امید برای شما بازگو کنم. ما در تحلیلگر امید الگوریتم های معاملاتی برای بازار سرمایه ایران تولید می‌کنیم. این الگوریتم ها به ساده سازی فرایند معامله گری افراد و شرکت های فعال در بازار سرمایه کمک می‌کند. ما پس از انتشار نسخه اول متوجه شدیم که سیستم به شدت باگ دارد، با اینکه تیم ساعت ها و با دقت روی توسعه محصول کار کرده بود. تجربه به صفر رساندن باگ ها در شرایط بحرانی آن زمان، مرا به این واداشت که مهم ترین اقدام هایی که باید برای به حداقل رساندن باگ ها و بهبود فرایند توسعه محصول تان انجام دهید را در این مقاله با شما به اشتراک بگذارم.
هرگز بدون داشتن نگاه جامع و سطح بالا از مشکلات سیستم، دست به رفع اشکال آن نزنید. ابتدا گزارش کاملی از باگ های سیستم بنویسید. ممکن است واسط خوبی برای گرفتن تجربه کاربرهایتان و باگ هایی که در هنگام استفاده از سیستم، به آنها بر می خورند نداشته باشید. میتوانید صفحه ای بعنوان گزارش باگ در محصول خود طراحی کنید یا از ابزار هایی مانند Hotjar یا jira script استفاده کنید.
تعداد و انواع باگ ها، اینکه شما چقدر در بحران هستید را بهتر گزارش می‌کنند. سپس باگ ها را root cause کرده و بر اساس ریشه ی وقوع شان دسته بندی کنید. ما برای اینکار از سایت coggle استفاده کردیم و به این نمودار رسیدیم.
معمولا مشاهده خواهید کرد که ۸۰ درصد باگ ها برای بیست درصد سیستم است! که به آن قانون پارتو میگوییم! به کمک این روش، با دیدی دقیقتر و بهتر میتوانید برای کاهش باگ ها برنامه ریزی کنید.
بعد از برنامه ریزی برای ریفکتور و حل مشکلات سیستم، برای تیم خود یک گارد درست کنید. معمولا اگر استفاده کنندگان سیستم به نیرو های فنی توسعه دهنده سیستم دسترسی داشته باشند، به آنها مدام مراجعه می‌کنند و خواستار رفع باگ می شوند و تمرکز را از تیم فنی می گیرند. باید اینگونه دسترسی هارا قطع کرده و سعی کنید فضای با آرامشی برای تیم فنی درست کنید تا با تمرکز، و به دور از task switching های پرتکرار، به رفع مشکلات سیستم بپردازند.
بهتر است در بخش هایی که باگ دارند، از تمامی تحرکات سیستم در پایین ترین سطح کد یعنی هر فانکشن لاگ بگیرید. برای این کار حتما از Aspect oriented programming استفاده کنید. در این دیدگاه از برنامه نویسی، بعنوان مثال می توانید بگویید تمامی function ها با سطح دسترسی public که در پکیج x وجود دارد لاگ شوند. بهتر است فرمت لاگ، فرمتی خوانا باشد تا خواندن و سرچ زدن آن راحت باشد. می توانید از فرمت json استفاده کنید و در هر لاگ، اسم فانکشن، ورودی ها و خروجی، مدت زمان اجرا شدن و زمان صدا خوردن را لاگ کنید. برای مدیریت و جستجو در لاگ ها از elasticsearch و پنل کیبانا استفاده کردیم که در پیدا کردن باگ ها بسیار به ما کمک کرد.
حتی اگر توانستید باگ های سیستم را به صفر برسانید، تا زمانی که تست اتوماتیک نداشته باشید، تضمینی برای برگشت ناپذیری به حالت ناپایداری و buggy بودن سیستم وجود ندارد. Automated test به شما کمک می کنند که در هربار build و deploy نرم افزارتان در سرور، از صحت عملکرد نرم افزارتان اطمینان حاصل کنید. برای من بسیار اتفاق افتاده که با تغییر در کد بخشی از محصول، تست های بخش دیگری از محصول fail شده اند. این اتفاق طبیعی است و اهمیت تست اتوماتیک را نشان می‌دهد. اگر تیم شما تابحال برای نرم افزار خود تست ننوشته است، آنها را ملزم به یادگیری unit test و integration test بکنید.
مهمتر از تست نوشتن و تست کردن، پیاده سازی فرهنگ تست نوشتن در تیم فنی ست. همه برنامه نویسان تیم باید توانایی نوشتن تست برای کدی که خود می‌نویسند را داشته باشند و هیچ کدی بدون تست، نباید به دست کاربر برسد. برای پیاده سازی این فرهنگ این مراحل بسیار راه گشاست:
علاوه بر محصولی که تولید می‌کند، کدِ شما نیز یکی از محصولات تیم است. پس به کیفیت کد نیز حتما نگاه ویژه ای داشته باشید. سعی داشته باشید از این به بعد که باگی تولید نمیکنید و برای کدهایتان تست می‌نویسید، به کیفیت کد های نوشته شده نیز توجه کنید و کد های قبلی را نیز refactor کنید. در این مرحله به چند مورد ساده حتما توجه کنید
یک سیستم نرم افزاری به سادگی میتواند سرما بخورد! و باگ خیز شود. برای اینکه همیشه stable باشید، نباید توصیه های بالا را متوقف کنید یا در انجام آن کاهلی کنید. بصورت دوره ای (حتی اگر از متدولوژی های agile استفاده نمیکنید) بررسی کنید که ۵ مورد بالا حتما در تیم های فنی تان انجام می شوند.
در نهایت لازم می‌دانم از دوست و معلم خودم، اسد صفری تشکر کنم که در ۴ ماه گذشته، به من و تمامی تیم تحلیلگر امید، کمک کرد تا این تجربه ارزشمند بدست‌آید.
اگر شما هم تجربه ای در این زمینه دارید، دوست دارم درباره ش بشنوم و باهم بحث و گفتگو کنیم.
