برنامه نویسی

تئوری اشکال زدایی – انجمن DEV

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

در چند پست بعدی در این مجموعه، “نظریه” کمتر شناخته شده در پشت اشکال زدایی را توضیح خواهم داد. همه ما روش اشکال زدایی را می دانیم (تا حدی) اما یک زیربنای نظری نیز وجود دارد که اکثر ما هرگز در دانشگاه یاد نگرفتیم (مطمئنم که این کار را نکردیم). درک این نظریه به شما کمک می کند تا رویکرد روشمندتری را برای حل مشکل به کار ببرید و درک شما از کد خود را بهبود بخشد.

قبل از ادامه، می‌خواهم اشاره کنم که بیشتر محتوای این مجموعه در کتاب من «اشکال‌زدایی عملی در مقیاس: اشکال‌زدایی بومی ابری در Kubernetes و تولید» (Apress) پوشش داده شده است.

همچنین در حالی که به موضوع کتاب می پردازیم، کتاب جدید من “Java 8 تا 21: کاوش و کار با ویژگی های پیشرفته جاوا 21” (BPB) نسخه شماره 1 جدید در برنامه نویسی جاوا در آمازون است و اکنون در دسترس است. .

https://www.youtube.com/watch?v=sJkPV7njpVY

سادگی و پیچیدگی اشکالات

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

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

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

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

پذیرش روش اشکال زدایی

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

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

اعتبار سنجی و حذف

پس از این، ما باید تأیید کنیم که نتایج آزمایش‌ها و محیط ما با مفروضات اولیه ما مطابقت دارد. در روحیه استحکام، توصیه می‌شود دو شکل تأیید وجود داشته باشد زیرا ممکن است یکی از آنها ناقص باشد. در مورد اهمیت تایید دوگانه در این پست نوشتم.

پس از انجام این تأییدها، با الهام از نقل قول معروف آرتور کانن دویل، به مرحله حذف می رویم:

“وقتی غیرممکن ها را حذف کردید، هر چه باقی می ماند، هر چقدر هم که غیرممکن باشد، باید حقیقت باشد.”

به عبارت دیگر، ما باید مشکل خود را «شرلوک هلمز» بشناسیم و احتمالات را رد کنیم تا زمانی که معقول‌ترین توضیح برایمان باقی بماند.

با درک عمیق‌تر باگ، می‌توانیم به سمت حل مشکل حرکت کنیم. فرآیند حل و فصل باید شامل پر کردن مشکل، ایجاد یک مورد آزمایشی ناموفق، تأیید راه حل پیشنهادی برای حل پرونده آزمایشی، و مرتکب شدن اشکال و رفع اشکال باشد.

خواندن اسناد: یک تصور غلط

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

نکته کلیدی در اینجا این است که بدانید چه چیزی، کجا و چه زمانی باید مشکل را جستجو کنید. موتورهای جستجو و پلتفرم هایی مانند Stack Overflow اشکال زدایی را متحول کرده اند و به ما امکان می دهند مستقیماً پیام های خطا را وارد کرده و راه حل های بالقوه را پیدا کنیم. این روش بدون خطا نیست، اما نقطه شروع خوبی است.

اهمیت طرح بازی

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

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

  • آیا کاربر می تواند این را بازتولید کند؟

  • آیا می توانم این را در دستگاه خود بازتولید کنم؟

  • آیا موضوع به طور مداوم اتفاق می افتد؟

  • آیا موضوع قهقرایی است؟

پاسخ به این سوالات برنامه بازی شما و روند فرآیند اشکال زدایی شما را شکل می دهد. در پایان، صبر و استراتژی می تواند در زمان گرانبها صرفه جویی کند و از ناامیدی غیر ضروری جلوگیری کند.

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

کلمه پایانی

اشکال زدایی، علیرغم اینکه ناامیدکننده تلقی می شود، بخشی ضروری از توسعه نرم افزار است که لحظات یادگیری و رشد شخصی را ارائه می دهد. یک رویکرد روشمند برای اشکال زدایی شامل شناسایی ناحیه کد مسئول اشکال، فرموله کردن یک برنامه استراتژیک بازی، جداسازی و تولید مجدد اشکال برای آزمایش و در نهایت حل مشکل است. یک تصور غلط رایج این است که خواندن مستندات می تواند ساعت ها در رفع اشکال صرفه جویی کند. با این حال، بیشتر در مورد دانستن این است که کجا و چه چیزی را جستجو کنید. صبر و یک استراتژی واضح می تواند از اتلاف زمان غیر ضروری جلوگیری کرده و فرآیند اشکال زدایی را کارآمدتر کند.

در قسمت بعدی، ما به طرح بازی برای اشکال زدایی عمیق تر خواهیم پرداخت، به ویژه تمرکز بر مسائلی که بازتولید آنها دشوار است. ما بیشتر استراتژی ها و ابزارهایی را بررسی خواهیم کرد که می توانند به مقابله موثر با چنین اشکالات گریزان کمک کنند.

نوشته های مشابه

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

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

دکمه بازگشت به بالا