باگها، خطاها، exceptionها، مشکلات، هر چیزی که در لحظه نامشان را بگذارید، باز هم باگها عمیقا به شکست مرتبط هستند. به طور مشخصتر، شکست شخصی خودمان در نوشتن کد بی نقص. این «شکستها» میتوانند به میزان عظیمی از گیجی و ناامیدی ختم شوند، اما رضایت نهایی که در ترمیم آن کد و تصحیح یک اشتباه به دست میآورید، یکی از بهترین احساسات در توسعه نرمافزار است.
این ترن هوایی احساسی میتواند باعث شود که برطرف کردن یک باگ، حس خروج غیر قابل پیشبینی از «کار واقعی» را داشته باشد. گرچه یک نکته در اینجا وجود دارد: این که کد شما باگ داشته باشد، بسیار پیشبینی شده است. باگها همیشه وجود دارند.
به همین علت مهم است که روند کار را در چشمانداز نگه دارید. باگها فقط نوعی ناراحتی تصادفی نیستند، بلکه یک بخش کامل از چرخه توسعه هستند. شما باید با همان سختی و خودآزماییای که باقی توسعه نرمافزار خود (طراحی، پیادهسازی، آزمایش، گسترش و...) را انجام میدهید، به سراغ باگها بروید. خطایابی هم به هیچ وجه برای داشتن مکالمات، تکرارها و انعکاسهای خود کم ارزش نیست.
به همین صورت، در اینجا سه سوال را مشاهده میکنید که باید از خودتان یا همکارانتان بپرسید، تا با هر باگ به عنوان یک نقطه داده با ارزش و فرصتی برای ارتقای نرمافزار و روند کار خود رفتار کنید.
جدول محتویات:
- الگوی اصلی پشت این باگ چیست؟ در چه جای دیگری وجود دارد؟
- تاثیر آن چه بود؟
- چه کاری میتوانیم انجام دهیم تا از باگهای این چنینی جلوگیری کنیم؟
الگوی اصلی پشت این باگ چیست؟ در چه جای دیگری وجود دارد؟
پس از یک دوره خواندن سورس کد، لاگ برداری و دنبال کردن stack traceها، طبیعی است که یک مشکل را از یک دیدگاه متفکرانه ببینید. در این سطح، باگ شما «فقط یک کاراکتر فراموش شده یا «فقط فراخوانی متد کتابخانه استاندارد اشتباهی» بوده است. تمرکز خود را عریضتر کنید، و ارتباطی که این اشتباه به نواحی دیگر کد شما داشته است را در نظر بگیرید. هیچ خط کدی بی والد نیست. به این فکر کنید که کدام کد از نظر منطقی در مسیر اجرایی قرار دارد. چگونه به این باگ ربط داشت، و حال که این رفتار تغییر کرده است چه اتفاقی خواهد افتاد؟
برادران این باگ در کجا هستند؟ این الگو در چه جای دیگری بروز میدهد؟ تمام کدها شامل شباهتهایی از طریق چکیدگی و تکثیر میشوند. چه مسیرهای موازیای برای موردی که در آن خطا را پیدا کردید وجود دارند؟ آیا این مسیرها هم همین اشتباه را کردهاند؟
مثال:
شما دارید به سمت سناریو تجدید پذیری راهنمایی میشوید که در آن رسیدهای پرداخت با تاریخهای اشتباه تولید میشوند. پس از مقداری تحقیق، پی خواهید برد که تاریخی که به تابع رندر کردن منتقل میشود، «undefined» است، اما یک کتابخانه کاربردی ک برای قالببندی تاریخها استفاده میشود، احتمالا این ورودی را به عنوان یک فراخوانی به Date.now() تفسیر میکند. این یعنی سند مورد نظر همیشه به جای تاریخی که از دادههای اصلی گرفته است، این تاریخ را نشان میدهد.
پس از یک پیام کوتاه، شما فراخوانیهای خود را با استفاده از این متد کتابخانه رسیدگی میکنید. یک جستجوی سریع ۷ تماس را نشان میدهد، و پس از تحقیق پی میبرید که یکی از آن تماسها یک مشکل یکسان دارد.
تاثیر آن چه بود؟
تاثیر کاربری واقعی چه بود؟ آیا شکستی وجود داشت که واضح نبوده باشد؟ آیا باید نسبت به کاربر، اعضای گروه، یا دیگر سهامداران پیگیری انجام شود؟ برطرف کردن باروری از دست رفته چقدر هزینه داشت، و تاثیر آن به کاربران نرمافزار چه بود؟
این اطلاعات میتوانند در دو جهت کاربردی باشند:
اکثر باگها مهم نیستند، میتوانند به سادگی رفع شوند و نیازهای حیاتی کسب و کار را تحت تاثیر قرار نمیدهند.
برخی باگها واقعا مهم هستند.
فکر کردن به صورت کلی درباره یک باگ، میتواند یک بخش مهم از معادله را در هنگام گرفتن تصمیمات درباره این که چه روندهایی برای سازمان شما مناسب هستند، فراهم کند.
مثال:
در مورد یک برچسب زمان که به صورت اسرار آمیزی نمیگذرد، شما توانستید به سادگی مشکلات را مجددا ایجاد کنید و از ابزار توسعه مرورگر خود استفاده کنید تا آن را به نقطه دسترسی ویژگی اشتباه دنبال کنید. قطعه مورد نظر یک خط کد اعمال شده به دو موقعیت بود، و به ایجاد زمان با یک آزمون regression، برابر با همان روز ختم میشد.
شما به پیش شخص مورد نظر در گروه مالی که مشکل را ایجاد کردند باز میگردید، و توضیح میدهید که چرا تاریخها اشتباه بودند. پس از یک مکالمه، پی میبرید که این اسناد از پیش برای هیچ کار مهمی استفاده نشده بودند، اما برخی پیشبینیها وجود دارند که نیاز دارند تا این اسناد صحیح باشند؛ پس فردا مجددا آن را اجرا میکنند، و باز هم بررسی میکنند تا ببیند که تاریخها صحیح هستند یا نه.
چه کاری میتوانیم انجام دهیم تا از باگهای این چنینی جلوگیری کنیم؟
وقتی که همه چیز آرام میشود و یک patch در جای خود قرار دارد، وسوسه میشوید که سریعا به کار ادامه دهید. آدرنالین در حال فرونشینی است و احتمالا عملیات بعدی جلب توجه شماست. گرچه، قبل از آن یک سوال دیگر وجود دارد و این سوال، مهمترین سوالی است که باید در جهت سلامت طولانی مدت و صحیح بودن کد خود بپرسید.
به این فکر کنید که باگ مورد نظر چگونه معرفی شد، چرا پردازش فعلی شما از آن جلوگیری نکرد، و چه کاری میتواند به طور متفاوت انجام شود تا در آینده جلوی این باگ را بگیریم؟ آیا قدمهایی هستند که بتوانید بردارید و این کلاس باگها را از چرخه توسعه پروژه خود حذف کنید؟
مثال:
در مثال تاریخ ما، مقدار «undefined» بود؛ زیرا نام اشتباهی برای دریافت ویژگی یک آبجکت استفاده شده بود. متاسفانه، چیزی نبود که توسط دستگاه شما گرفته شود، اما در پایتون این مقدار یا یک «KeyError» حین رانش خواهد بود، یا این که در هنگام نوشتن، توسط یک type system از آن جلوگیری خواهد شد.
این خطا از زیر آزمایشهای دستی در رفت، زیرا تاریخ فعلی در دید پیادهساز یا هر کسی که به آن نگاه کرد، صحیح به نظر میآمد. احتمالا استفاده از یک ابزار بهتر برای نمایش زمان فعلی، آن را واضحتر میکرد.
ظاهرا مسیر کد ۱۰۰ درصد در آزمایش پوشش داده شده بود، اما اظهارات موجود فقط درباره مقادیر نتایج رندر شده بودند و تاریخ بررسی نشده بود.
بینشی از مشکل:
رفتار کتابخانه «Moment.js» برای استفاده ما مناسب نبود، و ارزشش را دارد که در جهت حذف کردن یک مشکل، آن را برکنار کنیم.
یک راه حل:
در داخل کامپوننت رندر کردن دادهها که تابع جداگانه را فراخوانی میکند، ما میتوانیم به دنبال یک آرگومان undefined بگردیم و یک exception ایجاد کنیم. موقعیت تغییری که از روی عمد به این رفتار تکیه میکرد تا Date.now() را منتقل کند، صحیح است.
در همین حین، تمام باگها هم اگر هزینه جلوگیریشان در مقابل تاثیر منفیشان ناچیز است، لزوما ارزش جلوگیری را ندارند.
به صراحت تعیین کردن یک راه حل احتمالی و تصمیم گرفتن درباره این که ارزش رسیدگی توسط سازمان شما را دارد یا نه، یک تمرین خوب و یک بخش پربار از این روند است. گاهی وسوسه خواهید شد که بنویسید همه باگها یک تصادف هستند، اما دنبال کردن این روش شما را تشویق خواهد کرد که خلاق باشید و تصمیمات متفکرانهای برای سلامت طولانی مدت کد خود بگیرید.
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید