“هشتاد و پنج تا باگ از واحد تست گزارش شده، لیستش را ایمیل کردم برای همه. توی لیست باگ‌های هرکس به تفکیک مشخص شده. تا شنبه ظهر باید همه باگ‌ها رفع شده باشد!”
این جمله را آقای رییس راس ساعت 4 بعد از ظهر روز چهارشنبه، وقتی که اعضای تیم توسعه یک چشم‌شان به مانیتور و چشم دیگر به ساعت بود و هرکس داشت توی ذهنش برنامه تعطیلات آخر هفته‌اش را مرور میکرد، مثل نارنجک توی سالن تیم توسعه پرتاب کرد!
قیافه تیم توسعه بعد از شنیدن حرف های رییس نیاز به توضیح ندارد. پس از یک سکوت سنگین برای گذر از بهت و هضم شرایط پیش آمده، همه به سرعت رفتند سراغ ایمیل‌هاشان. در حالی که خداخدا می‌کردند که باگ‌های قابل توجهی به نامشان ثبت نشده باشد.
آیا این وضعیت برای شما هم آشنا است؟
اصولا این یک قانون نانوشته است که رخدادهای غیر مترقبه همیشه دقیقه نود می‌افتند تا اوقات فراغت و تعطیلات را به آدم زهرمار کنند: آخر روز، آخر هفته، آخر سال! از این قانون گریزی نیست. اما چیزهای دیگری در بعضی رخدادهای مثل این هست که شاید بشود از آن اجتناب کرد. مثل باگ های زیاد، یا اجبار برای اضافه کار.
ببینیم در خصوص چنین رویدادی چه رویکردهایی قابل اتخاذ است:
همینه که هست!
بسیاری از افراد اعم از مدیر یا برنامه نویس، هستند که این شرایط را طبیعی می‌دانند : “باگ جزیی از نرم افزار است و از آن راه گریزی نیست”. “از ما بزرگترها، مایکروسافت و گوگل هم نرم‌افزارهای‌شان باگ دارد. ما که جای خود داریم!” . “گروه تست، کارش همین است که باگ‌های کار ما را پیدا کند”.
تا جایی که من دیده‌ام و در جاهایی که کار کرده‌ام، این رویکرد غالب است. اینکه برنامه نویس کارش نوشتن کد است. وجود باگ نیز طبیعت کار کدنویسی است و کاری نمی‌شود برایش کرد. و به هرحال تسترها هستند و باگ‌ها توسط آنها پیدا می‌شود. همه چیز منطقی و هرکس مشغول کار خود. بسیار هم عالی!
فرصتی برای بهبود
رویکرد دیگر اما این است که آیا می‌توان شرایط اینچنینی را بعنوان فرصتی برای بهبود درنظر گرفت؟ اگر چه از باگ گریزی نیست و می‌دانیم نرم افزار بدون باگ قابل تصور نیست اما آیا نمی‌شود تعداد باگ را کاهش داد و به حداقل رساند. آیا هیچ کدام از باگ‌ها و موارد اعلام شده قبل از ارسال به تست، در فرایند توسعه به راحتی و با هزینه اندک قابل شناسایی و رفع نبوده‌اند؟
خوشبختانه قبل از ما خیلی‌ها دنبال پاسخ این پرسش‌ها رفته‌اند و راهکارهایی نیز ارائه کرده‌اند:
- استفاده از روال‌های تست اتوماتیک و استقرار CI: این کار مستلزم ایجاد Unit Test های مناسب است که به صورت روزانه یا به ازای هر Commit کد اجرا شده و اشکالات و خطاها را به توسعه دهنده اطلاع دهند. شما را نمی‌دانم اما برای من پیش آمده که وقتی کدی را تغییر داده ام در جای دیگری از برنامه که در مخیله‌ام نمی‌گنجید منجر به خطا شده. وجود Unit Test بسیار به این موضوع کمک میکند. اگر هم که با رویکرد TDDانجام شود که چه بهتر. چون تست هایی که نوشتن آنها به بعد موکول می‌شود، ممکن است مشمول فراموشی، سهل انگاری یا کمبود وقت شوند و هرگز نوشته نشوند.
- توجه بیشتر به تست و همکاری تسترها در زمان توسعه نرم افزار
- بررسی باگ‌ها و شناسایی دلایل رخداد آن. مثلا پاسخ به سوالاتی از این دست: اکثریت باگ ها مربوط به کدام بخش از برنامه است و آیا نمی‌شود با تقویت Unit Testها ، تغییر معماری یا راهکارهای دیگر، باگ‌های مربوط به آن را کاهش داد؟
- مرور کد: اینکه کدهای نوشته شده، توسط سایر اعضا یا دست کم توسط نرم افزارهای مربوطه Review شوند. البته بعضی برنامه نویسان دوست ندارند کسی به کدی که نوشته‌اند نگاه چپ بکند و خطایی در آن پیدا کند. این برنامه نویسان به هر حال باید بین حس همکاری و اعتماد به هم تیمی‌ها یا پنجشنبه و جمعه سرکار آمدن و باگ رفع کردن یکی را انتخاب کنند.
- Refactoring: کدهای تمیز، خوانا ، متدهای کم حجم و به دور از کدهای Duplicate منطقا احتمال باگ کمتری دارند.
- پرهیز از اضافه کاری: خود اضافه کاری و کد زدن در شرایط خستگی، فشار و استرس نیز در بروز کدهای بی‌کیفیت‌تر و باگ‌های بیشتر بی‌تاثیر نیست.
نمی‌دانم شما کدام رویکرد را می‌پسندید. ترجیح می‌دهید همه چیز همانطور که هست بماند، یا اینکه معتقدید می‌شود قدمی برای بهبود شرایط برداشت؟ انتخاب با شما است. فقط فارغ از هر انتخابی به نظرم هوای هم‌تیمی‌هایی که کلی باگ در لیست به نامشان ثبت شده و باید پنجشنبه و جمعه سرکار بیایند را هم داشته باشید. اشکالی ندارد اگر دو سه تا از باگ های آنها را هم شما برطرف کنید. به هرحال این محصول همه شما است و همه در موفقیت یا شکست آن سهیم هستید. این چیزی است که در فرهنگ ما اسمش مرام و معرفت است و در ادبیات چابک هم به آن collective ownership گفته می‌شود.
دی ماه 1396