با باگ ها چه کنیم؟

“هشتاد و پنج تا باگ از واحد تست گزارش شده، لیستش را ایمیل کردم برای همه. باگ‌های هرکس به تفکیک مشخص شده. تا شنبه ظهر باید همه باگ‌ها رفع شده باشد!”

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

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

آیا این وضعیت برای شما هم آشنا است؟

اصولا این یک قانون نانوشته است که رخدادهای غیر مترقبه همیشه دقیقه نود می‌افتند تا اوقات فراغت و تعطیلات را به آدم زهرمار کنند: آخر روز، آخر هفته، آخر سال! از این قانون گریزی نیست. اما چیزهای دیگری در بعضی رخدادهای مثل این هست که شاید بشود از آن اجتناب کرد. مثل باگ های زیاد، یا اجبار برای اضافه کار.

ببینیم در خصوص چنین رویدادی چه رویکردهایی قابل اتخاذ است:

همینه که هست!

بسیاری از افراد اعم از مدیر یا برنامه نویس، هستند که این شرایط را طبیعی می‌دانند : “باگ جزیی از نرم افزار است و از آن راه گریزی نیست”. “از ما بزرگترها، مایکروسافت و گوگل هم نرم‌افزارهای‌شان باگ دارد. ما که جای خود داریم!” . “گروه تست، کارش همین است که باگ‌های کار ما را پیدا کند”.

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

فرصتی برای بهبود

رویکرد دیگر اما این است که آیا می‌توان شرایط این چنینی را بعنوان فرصتی برای بهبود درنظر گرفت؟ اگر چه از باگ گریزی نیست و می‌دانیم نرم افزار بدون باگ قابل تصور نیست اما آیا نمی‌شود تعداد باگ را کاهش داد و به حداقل رساند. آیا هیچ کدام از باگ‌ها و موارد اعلام شده قبل از ارسال به تست، در فرایند توسعه به راحتی و با هزینه اندک قابل شناسایی و رفع نبوده‌اند؟

خوشبختانه قبل از ما خیلی‌ها دنبال پاسخ این پرسش‌ها رفته‌اند و راهکارهایی نیز ارائه کرده‌اند:

  • استفاده از روال‌های تست اتوماتیک و استقرار CI و CD  – Continuous Delivery : این کار مستلزم ایجاد Unit Test های مناسب است که به صورت روزانه یا به ازای هر Commit کد اجرا شده و اشکالات و خطاها را به توسعه دهنده اطلاع دهند. شما را نمی‌دانم اما برای من پیش آمده که وقتی کدی را تغییر داده ام در جای دیگری از برنامه که در مخیله‌ام نمی‌گنجید منجر به خطا شده. وجود Unit Test بسیار به این موضوع کمک میکند. اگر هم که با رویکرد TDDانجام شود که چه بهتر. چون تست هایی که نوشتن آنها به بعد موکول می‌شود، ممکن است مشمول فراموشی، سهل انگاری یا کمبود وقت شوند و هرگز نوشته نشوند.
  • توجه بیشتر به تست و همکاری تسترها در زمان توسعه نرم افزار
  • بررسی باگ‌ها و شناسایی دلایل رخداد آن. مثلا پاسخ به سوالاتی از این دست: اکثریت باگ ها مربوط به کدام بخش از برنامه است و آیا نمی‌شود با تقویت Unit Testها ، تغییر معماری یا راهکارهای دیگر، باگ‌های مربوط به آن را کاهش داد؟
  • مرور کد: اینکه کدهای نوشته شده، توسط سایر اعضا یا دست کم توسط نرم افزارهای مربوطه Review شوند. البته بعضی برنامه نویسان دوست ندارند کسی به کدی که نوشته‌اند نگاه چپ بکند و خطایی در آن پیدا کند. این برنامه نویسان به هر حال باید بین حس همکاری و اعتماد به هم تیمی‌ها یا پنجشنبه و جمعه سرکار آمدن و باگ رفع کردن یکی را انتخاب کنند.
  • Refactoring: کدهای تمیز، خوانا ، متدهای کم حجم و به دور از کدهای Duplicate منطقا احتمال باگ کمتری دارند.
  • پرهیز از اضافه کاری: خود اضافه کاری و کد زدن در شرایط خستگی، فشار و استرس نیز در بروز کدهای بی‌کیفیت‌تر و باگ‌های بیشتر بی‌تاثیر نیست.

نمی‌دانم شما کدام رویکرد را می‌پسندید. ترجیح می‌دهید همه چیز همانطور که هست بماند، یا اینکه معتقدید می‌شود قدمی برای بهبود شرایط برداشت؟ انتخاب با شما است. فقط فارغ از هر انتخابی به نظرم هوای هم‌تیمی‌هایی که کلی باگ در لیست به نامشان ثبت شده و باید پنجشنبه و جمعه سرکار بیایند را هم داشته باشید. اشکالی ندارد اگر دو سه تا از باگ های آنها را هم شما برطرف کنید. به هرحال این محصول همه شما است و همه در موفقیت یا شکست آن سهیم هستید. این چیزی است که در فرهنگ ما اسمش مرام و معرفت است و در ادبیات چابک هم به آن collective ownership گفته می‌شود.

مهیار ابراهیمی وفا

دی ماه 1396

درباره اسد صفری

اسد صفری – مربی تحول چابک سازمان و تیم های نرم افزاری. مدارک حرفه ای: CSP - CSM - PSM - PSPO - CDA - Management 3.0 برخی تجربیات: رئیس دفتر تحول چابک شرکت داده ورزی سداد(بیشتر از ده تیم نرم افزاری) - مربی چابک شرکت رامند (تیم های موبایل و گیم سازی) - مدیر تولید نرم افزار SimplyDesk برای شرکت فرانسوی PCI - مربی مشاور شرکت های:خدمات انفورماتیک، ارکید فارمد، فراداده، الفبا برخی از سوابق مشاوره کوتاه مدت و تدریس : علی بابا، فناپ، تجارت الکترونیک پارسیان، بیمه سامان، مهندسین مشاور تجارت (بانک تجارت)، بیمه ایران، پارس آنلاین، شرکت رهنما، ورانگر، انتشارات پزشکی کوثر، فولا آلیاژی یزد، پارک علم فناوری کردستان و ... . عضو انجمن های بین المللی Agile Alliance - Scrum Alliance

1 دیدگاه در “با باگ ها چه کنیم؟

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

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

این سایت از اکیسمت برای کاهش هرزنامه استفاده می کند. بیاموزید که چگونه اطلاعات دیدگاه های شما پردازش می‌شوند.