با سیل عظیم ورود باگ چه کنیم؟ پنج راه که به پایدار کردن محصولتان کمک می‎‌کند

معمولا بعد از اولین انتشار عمومی یک محصول نرم افزاری، شاهد هجوم گزارش های باگ از سمت کاربران هستیم. هیچ محصولی مطلقا بدون باگ نخواهد بود اما این موضوع برای تیم های نرم افزاری، ممکن است استرس آور باشد و آنها را دستپاچه کند. در این مواقع از دست دادن ابتکار عمل و انجام کار های نسنجیده ممکن است مشکلات شما را بیش از پیش افزایش دهد. در این مقاله سعی دارم تجربه های خودم را در مواجهه با هجوم باگ ها در شرکت تحلیلگر امید برای شما بازگو کنم. ما در تحلیلگر امید الگوریتم های معاملاتی برای بازار سرمایه ایران تولید می‌کنیم. این الگوریتم ها به ساده سازی فرایند معامله گری افراد و شرکت های فعال در بازار سرمایه کمک می‌کند. ما پس از انتشار نسخه اول متوجه شدیم که سیستم به شدت باگ دارد، با اینکه تیم ساعت ها و با دقت روی توسعه محصول کار کرده بود. تجربه به صفر رساندن باگ ها در شرایط بحرانی آن زمان، مرا به این واداشت که مهم ترین اقدام هایی که باید برای به حداقل رساندن باگ ها و بهبود فرایند توسعه محصول تان انجام دهید را در این مقاله با شما به اشتراک بگذارم.گزارش دقیقی از تعداد و انواع باگ ها در بیاوریدهرگز بدون داشتن نگاه جامع و سطح بالا از مشکلات سیستم، دست به رفع اشکال آن نزنید. ابتدا گزارش کاملی از باگ های سیستم بنویسید. ممکن است واسط خوبی برای گرفتن تجربه کاربرهایتان و باگ هایی که در هنگام استفاده از سیستم، به آنها بر می خورند نداشته باشید. می‌توانید صفحه ای بعنوان گزارش باگ در محصول خود طراحی کنید یا از ابزار هایی مانند 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 بکنید.مهمتر از تست نوشتن و تست کردن، پیاده سازی فرهنگ تست نوشتن در تیم فنی ست. همه برنامه نویسان تیم باید توانایی نوشتن تست برای کدی که خود می‌نویسند را داشته باشند و هیچ کدی بدون تست، نباید به دست کاربر برسد. برای پیاده سازی این فرهنگ این مراحل بسیار راه گشاست: حتما پس از تعریف هر تسک، سناریو تست های آن مشخص باشد و برنامه نویس موظف به نوشتن unit test برای آن باشد.به code coverage اهمیت بدهید. درست است که تضمین کننده ی تست خوب نیست و یک تست ساده برای یک سناریو موفق می تواند coverage زیادی برای شما به ارمغان بیاورد، اما به شما در به صفر رساندن باگ های ساده کمک می کند. بهتر است بصورت دوره ای برای محصولتان integration test بنویسید و تمام اجزای سیستم را بصورت جامع تست بگیرید. integration test بسیار در تولید کد های بدون باگ کمک می‌کند.حتما در فرایند دیپلوی محصولتان، تمام تست ها اجرا شوند و در صورت خطا خوردن، محصولتان دیپلوی نشود.‌اگر به جنگل رفتید، نه تنها آشغال نریزید، بلکه دور و بر خودتون رو هم تمیز کنید!علاوه بر محصولی که تولید می‌کند، کدِ شما نیز یکی از محصولات تیم است. پس به کیفیت کد نیز حتما نگاه ویژه ای داشته باشید. سعی داشته باشید از این به بعد که باگی تولید نمی‌کنید و برای کدهایتان تست می‌نویسید، به کیفیت کد های نوشته شده نیز توجه کنید و کد های قبلی را نیز refactor کنید. در این مرحله به چند مورد ساده حتما توجه کنیدقواعد ساده ی refactor کردن مانند نامگذاری درست، فانکشن های کوتاه، کلاس های خرد شده را در تیم خود جا بیندازید. برای یادگیری این قواعد از سایت refactoring می‌توانید استفاده کنید.از sonarlint برای سنجش کیفیت کدتان استفاده کنید. می توانید آن را بعنوان پلاگین در IDE خود نصب کنید و همچنین در فرایند CI/CD تان از آن استفاده کنید به گونه ای که اگر تعداد issue های کد، از حدی بالاتر رفت، برنامه build و deploy نشود.برای merge کردن کدهایتان، از سیستم approval استفاده کنید. قواعد را به گونه ای بنویسید که حداقل دو نفر برای مرج کردن یک کد باید تایید بدهند.و حرف آخر: زمانی که علایم بیماری از بین رفت، مصرف دارو هارا قطع نکنیدیک سیستم نرم افزاری به سادگی می‎تواند سرما بخورد! و باگ خیز شود. برای اینکه همیشه stable باشید، نباید توصیه های بالا را متوقف کنید یا در انجام آن کاهلی کنید. بصورت دوره ای (حتی اگر از متدولوژی های agile استفاده نمی‌‌کنید) بررسی کنید که ۵ مورد بالا حتما در تیم های فنی تان انجام می شوند.در نهایت لازم می‌دانم از دوست و معلم خودم، اسد صفری تشکر کنم که در ۴ ماه گذشته، به من و تمامی تیم تحلیلگر امید، کمک کرد تا این تجربه ارزشمند بدست‌آید.اگر شما هم تجربه ای در این زمینه دارید، دوست دارم درباره ش بشنوم و باهم بحث و گفتگو کنیم.