باگ های جهنمی را چطور خطایابی کنیم!

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

بله، به همین سادگی، یک غیر طراح وقتی با اولین بن‌بست مواجه شد، دست از تلاش می‌کشد و با یک “نمی‌شود” خیلی ساده همه چیز را تمام می‌کند. شخص دیگری سعی می‌کند با عوض کردن قطعات مختلف، چک کردن اتصالات، یا بسته به درکی که از عملکرد قطعات مختلف دارد، مشکل را حل کند، تا اینجا طراح معمولی داریم! اما چطور می‌شود یک طراح خوب بود؟ یا بهتر بگویم یک طراح هوشمند بود؟ در این مقاله سعی می‌کنم به این سؤال جواب بدم و البته خوشحال می‌شوم که دوستان و همراهان عزیز سیسوگ، با دیدگاه‌هایشان این مقاله را کامل‌تر کنند.

از طراحی تا تعمیرکاری!

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

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

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

خلاصه، اگر بخواهم این بحث را جمع بندی کنم، باید بگویم که: “ممکن است هر تعمیرکار خوب، یک طراح خوب نباشد، ولی حتماً هر طراح خوب یک تعمیرکار خوب هم هست.”

خطایابی نیاز به شناخت دارد!

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

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

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

بگذارید برای ملموس شدن موضوع، یک مثال بزنم. خیلی از دوستان برای این که سریع‌تر محصولی رو آماده کنند تمام بخش‌های مورد نیاز پروژه را خودشان طراحی نمی‌کنند و از کتابخانه‌های آماده استفاده می‌کنند. در مواردی حتی داکیومنت‌های آن را نیز مطالعه نمی‌کنند. وقتی برنامه آن طور که باید کار نمی‌کند، درست نمی‌دانند مشکل از کجا می‌تواند باشد. چرا که نمی‌داند آن کتابخانه از چه منابعی استفاده کرده و یا با چه روشی مسئله را حل کرده است. آیا با دیگر کتابخانه‌ها اختلال دارد یا نه؟! این تازه آن نقطه‌ای است که جهنم شروع می‌شود! در نتیجه برای پیدا کردن منشأ یک خطا، نیاز است که عملکرد جزء به جزء اجزای دستگاه را بدانید تا بتوانید در ساده‌ترین حالت ممکن ریشه خطا را پیدا کنید. البته که با سعی و خطا نیز می‌شود مشکل را پیدا کرد. ولی نکته اینجاست چقدر زمان صرف پیدا کردن مشکل می‌کنید.

با خودتان صادق باشید، همه چیز نویز نیست!

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

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

برای دابل چک کردن این مسئله به این مورد استناد می‌کنند که ریست یا عملکرد نامتعارف دستگاه، پریودیک و قابل پیش‌بینی نیست. گاهی یک ساعت بعد، گاهی بعد از ۱ روز و گاهی هم ۱۰ دقیقه بعد از شروع به کار دستگاه اتفاق می‌افتد.

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

در مواردی حتی تقصیر را گردن کامپایلر و باگ‌های احتمالی کامپایلر می‌اندازند.

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

و هرگز فراموش نکنید که نویز از رگ گردن به مدار شما نزدیک‌تر است.

چه باگی جهنمی است؟!

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

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

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

ممکن است فکر کنید که شوخی می‌کنم. ولی متأسفانه باید بگم نه شوخی نمی‌کنم، واقعاً چنین اتفاقی برای خود من افتاده است. در فصل زمستان دستگاهی را برای کنترل گاز ورودی به توربین طراحی کرده بودم که به خوبی کار می‌کرد، اما در تابستان دچار مشکل شد 😐

و یا دستگاهی که اخیراً به مدت سه یا چهار هفته، به معنی واقعی کلمه بیچاره‌ام کرد تا خطایابی کنم و مشکلش رو پیدا کنم! مشکل این بود که دستگاه در داخل کشور بدون هیچ مشکلی کار می‌کرد اما در خارج از کشور کار نمی‌کرد! (دستگاه به شدت وطن دوست تشریف داشتند!) بعد از گمانه زنی در خصوص دلیل مشکل، مشکل پیچیده‌تر هم شد و زوایای تاریکی را نشان داد :/، در یک سری کشورها کار می‌کرد و در برخی کشورها کار نمی‌کرد!!

من به این باگ‌ها می‌گویم باگ‌های جهنمی یا شاید هم خجالتی! چون به سادگی نمی‌شود شرایط ایجادش را مهیا کرد. به همین دلیل پیدا کردن منشأ آن کار بسیار دشواری است و باید تمام حالت‌های ممکن و نا‌ممکن را در خصوص زمینه ایجاد باگ در نظر گرفت.

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

اما واقعاً چطور می‌شود این دسته خطاها را ردیابی کرد؟ سعی می‌کنم چند پارامتری را که فکر می‌کنم در پیدا کردن این گونه خطاها مؤثر هستند را بررسی کنم.

سعی کنید باگ را ببینید!

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

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

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

چکار باید کرد؟

به خودتان هم شک داشته باشید.

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

برای هر احتمال روش تستی داشته باشید که مطمئن شوید عملکرد درستی دارد! مثلاً اگر قرار است عملکرد پورت سریال را بررسی کنید رشته ثابتی را ارسال کنید و با اتصالات مورد استفاده در پروژه همان رشته را باید در سیستم مانیتورینگ (مثلاً کامپیوتر) دریافت کنید.

سعی کنید اول احتمال‌های سخت افزاری رو بررسی کنید و بعد به سراغ نرم افزار بروید. یعنی مثلاً اگر ماژول SD کار نمی‌کند، اول تغذیه و ارتباط پین به پین رو چک کنید و حتماً از اتصال آنها مطمئن شوید، بعد به سراغ موارد نرم افزاری بروید. مثلاً سرعت کلاک SPI و یا صحت از صفر و یک شدن پایه‌ها و همه چیز را مو به مو بررسی کنید، هر چقدر هم که بدیهی به نظر برسد! تا مشکل را پیدا کنید.

بگذارید با یک مثال که اخیراً اتفاق افتاده، موضوع را مقداری روشن‌تر کنم. دستگاهی داشتم که از ماژول GSM (نکات مهم در طراحی برد بر اساس GSM) برای ارسال یک سری اطلاعات استفاده می‌کرد. دستگاه به محض این که سعی در کانکت شدن به سرور داشت ریست می‌شد :|، گاهی هم بدون مشکل کار می‌کرد حتی روزها ولی در برخی مواقع هم به محض اتصال به اینترنت ریست می‌شد.

اولین و قوی‌ترین احتمال قسمت تغذیه مدار بود. چرا که هنگام تبادل جریان کشی‌های لحظه‌ای وجود دارد و اگر نتوانیم کاهش ولتاژ را جبران کنیم دستگاه ریست خواهد شد. دلیل این که گاهی هم ریست نمی‌شود احتمالاً کیفیت سیگنال شبکه است. وقتی شبکه پوشش خوبی داشته باشد جریان کمتری مورد نیاز است. سه روز تمام به بررسی این احتمال گذشت و مشکل حل نشد.

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

این مثال به خوبی نشان می‌دهد که در خطایابی نباید هیچ احتمالی را کنار گذاشت حتی بی ربط‌ترین احتمال‌ها را.

اگر باگ به آزمایشگاه نمی‌آید، آزمایشگاه را پیش باگ ببرید!

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

ممکن است تمام این نکات بدیهی به نظر برسد، اما پیداکردن هر سرنخ کوچک و بی اهمیتی به حل مسئله کمک کند.

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

فکر می‌کنم اگر این نکات خیلی بدیهی و پایه‌ای رو برای خطایابی و پیدا کردن ریشه یک مشکل انجام بدهید، هیچ مشکلی نباشد که نتوانید خطایابی کنید. این مقاله صِرف یادآوری گام‌هایی است که احتمالاً همه میدانیم باید انجام بدهیم، ولی در شرایطی فراموششان می‌کنیم و سر درگم می‌شویم!