آیا VCR به برق وصل است؟ عیب یابی عقل سلیم برای توسعه دهندگان وب

تابستان های کلاس ششم تا هشتم باورنکردنی بود. من در شمال دریاچه تاهو بزرگ شدم و با برادران و بچه های محله ام از صبح تا روشن شدن چراغ های خیابان دوچرخه سواری می کردم. ما ویدیوهای خانگی از تلاشمان برای ترفندهای BMX می‌سازیم (نسخه Baby-Gap X-Games را در نظر بگیرید). ما با استفاده از دوربین فیلمبرداری mini-DV خانواده خود ضبط کردیم.

پدر کمک می‌کرد تا دوربین فیلم‌برداری را به VCR و تلویزیون وصل کند و در لابلای دکمه‌ها و منوهای کنترل VRC قدم بزند تا بتوانیم فیلم‌ها را به VHS منتقل کنیم. در تابستان 1997، پدرم روند بسیار مهمی را با من در میان گذاشت که من هرگز آن را فراموش نکرده‌ام و از آن زمان تاکنون چارچوبی ارزشمند برای عیب‌یابی بوده است. او گفت: “اگر VCR کار نمی کند، ابتدا باید بررسی کنید که آیا به برق وصل شده است یا خیر. از پایه ترین جزء (پریز دیواری) شروع کنید، سپس مسیر را به سمت جزء بعدی در زنجیره دنبال کنید. در حالت ایده آل، هر جزء را جدا کنید. و پیوند اطمینان حاصل می کند که همه قطعات مطابق انتظار کار می کنند.

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

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

هنگامی که یک جزء خاص را جدا کردید، می توانید همان فرآیند را برای خود آن تکرار کنید. آیا قطعه برق می گیرد؟ آیا سیگنال های مناسبی را دریافت و/یا ارسال می کند که با سایر اجزای سیستم سازگار است؟ آیا آسیب دیده است؟

ابزارهایی برای عیب یابی

پدر یک کامیون پر از ابزار دارد: مولتی متر، سنج منیفولد، دماسنج مادون قرمز (تفنگ لیزری!). شما نیز از جمع آوری ابزارهایی برای کمک به جداسازی و شناسایی مشکلات بهره مند خواهید شد.

در سال 2011، من یک سال را در افغانستان صرف ساختن شبکه های تاکتیکی کردم که از فیبر نوری، ماهواره، اترنت و رادیو استفاده می کردند.

بسیاری از کار من پیکربندی روترها و سوئیچ های سیسکو بود. بهترین ابزار عیب یابی برای آن کار بود ping، traceroute، nslookup، dig و show دستورات من با پینگ کردن هاپ بعدی، هاپ بعدی و هاپ بعدی شروع می کنم. اگر پینگ‌ها موفقیت‌آمیز بود، به مقصد می‌رفتم تا ببینم آیا بسته‌ها مسیر مورد انتظار را دنبال می‌کنند یا خیر. اگر بسته‌ها مسیر مورد انتظار را دنبال نمی‌کردند، من از دستورات show برای بررسی جداول مسیریابی استفاده می‌کردم و بررسی می‌کردم که آیا RIP، OSPF و BGP کار خود را به درستی انجام می‌دهند. وضعیت رابط و گزارش ها را بررسی کنید.

برای توسعه وب، بهترین ابزار عیب یابی عبارتند از:

1. سیاههها و بیانیه چاپ:

لاگ ها مهمترین ابزار برای عیب یابی هستند. الوارها مانند جعبه سیاه هواپیما هستند. آنها هر چیزی را که در برنامه شما اتفاق می افتد ضبط می کنند. آنها می توانند به شما بگویند که چه اتفاقی افتاده است، چه زمانی و گاهی چرا اتفاق افتاده است. سیاههها اولین جایی هستند که وقتی مشکلی پیش می آید باید به آن نگاه کنید. یک مکتب فکری این است که هزاران عبارات چاپی را به کد خود اضافه کنید تا به شما در درک آنچه در حال رخ دادن است کمک کند. فرا گرفتن puts p و JSON.pretty_generate در روبی و console.log در جاوا اسکریپت برای چاپ وضعیت متغیرها و جریان کد. همچنین، از ورود به سیستم خود استفاده کنید و در مورد سطوح گزارش اطلاعات کسب کنید تا اطلاعات مناسب را در گزارش های تولید خود دریافت کنید.

2. اشکال زدا:

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

استفاده کنید step، next، continue، p و puts و l= برای چاپ دوباره جایی که هستید:

require 'byebug'

def sum(a, b)
  byebug
  a + b
end

def subtract(a, b)
  a - b
end

def multiply(a, b)
  a * b
end

def my_cool_math_thing(a, b)
  byebug
  answer1 = sum(a, b)
  answer1 + subtract(a, b) + multiply(a, b)
end

my_cool_math_thing(1, 2)

3. ابزارهای توسعه دهنده مرورگر: ابزارهای توسعه دهنده مرورگر در هر مرورگر وب مدرن تعبیه شده است. آنها به شما امکان می دهند HTML، CSS و جاوا اسکریپت یک صفحه وب را بررسی کنید، همچنین درخواست های شبکه را نظارت کنید، گزارش های کنسول را مشاهده کنید و جاوا اسکریپت را اشکال زدایی کنید. ابزارهای توسعه دهنده مرورگر برای رفع اشکال مشکلات سمت مشتری ضروری هستند.

4. REPLs: REPL مخفف Read-Eval-Print Loop است. REPL یک محیط برنامه نویسی تعاملی است که به شما امکان می دهد کد را در زمان واقعی بنویسید و اجرا کنید. REPL ها برای آزمایش سریع قطعه کد و کاوش ویژگی های زبان مفید هستند. می توانید از کنسول در ابزارهای توسعه دهنده مرورگر خود به عنوان REPL سمت کلاینت استفاده کنید و چارچوب سمت سرور شما احتمالاً دارای REPL داخلی است (مثلاً rails console). با استفاده از REPL، می توانید به سرعت با بیت های کد آزمایش کنید تا ببینید چگونه رفتار می کنند.

5. تست های خودکار: تست های واحد، تست های خودکاری هستند که رفتار یک واحد کوچک کد را به صورت مجزا تایید می کنند. من دوست دارم برای هر اشکال گزارش شده توسط کاربر، تست های واحد بنویسم. به این ترتیب، من می‌توانم باگ را در یک محیط کنترل‌شده بازتولید کنم و تأیید کنم که رفع آن همانطور که انتظار می‌رود کار می‌کند و ما شاهد رگرسیون نخواهیم بود. فریمورک های مختلف تست جاوا اسکریپت مانند Jest، cypress، mocha و jasmine وجود دارد. ما از Rspec و Minitest برای تست های واحد و یکپارچه سازی در برنامه ریل خود استفاده می کنیم.

6. Git Bisect: من فقط چند بار در حرفه ام از این استفاده کرده ام، اما تشخیص اینکه چه زمانی یک باگ معرفی شده است می تواند بسیار مفید باشد. شما با گفتن به git شروع می کنید که commit فعلی بد است و commit قبلی خوب است. سپس Git یک commit را در وسط محدوده بررسی می کند. شما commit را تست می کنید و به git می گویید که خوب است یا بد. سپس Git یک commit را در نیمه راه بین آخرین و کامیت فعلی پرداخت می کند. شما این روند را تکرار می کنید تا زمانی که commit را که باگ را معرفی کرده است پیدا کنید. این نوعی جستجوی باینری در تاریخ برای یافتن یک باگ است.

7. تجزیه و تحلیل کد استاتیک: ابزارهای تحلیل کد استاتیک کد شما را بدون اجرای آن تجزیه و تحلیل می کنند. آنها می توانند اشکالات احتمالی، آسیب پذیری های امنیتی و بوی کد را شناسایی کنند. من دوست دارم از لینترهایی مانند Rubocop و ESLint برای تشخیص خطاهای نحوی و اعمال سبک کد استفاده کنم.

8. پیام های خطا و ردیابی پشته: متأسفانه اکثر پیام‌های خطا شبیه شخصیت شرور یک فیلم اکشن بد هستند. آنها ترسناک هستند! حروف قرمز بزرگ، اغلب با زبان مرموز. اما، پیام های خطا بهترین دوست شما هستند. آنها به شما می گویند که چه چیزی اشتباه بوده و کجا اشتباه شده است. آنها می توانند رمزآلود باشند، اما اغلب حاوی اطلاعات ارزشمندی هستند که می تواند به شما در شناسایی علت اصلی یک اشکال کمک کند. ردیابی پشته مانند نقشه مسیر اجرای کد ناموفق است. آنها دنباله ای از فراخوانی های تابع را که منجر به خطا شده است به شما نشان می دهند. این نقشه شما از تمام اجزایی است که باید بررسی شوند — به ترتیب! معمولاً، من مطمئن هستم که کد شخص ثالث همانطور که انتظار می رود کار می کند (مثل پریز دیواری است، برق احتمالاً روشن است، اما گاهی اوقات لازم است پانل شکن را بررسی کنید). به خودتان لطف کنید و ابزارهای نظارت بر خطا و هشدار را در تولید راه اندازی کنید تا بدانید چه زمانی خطایی برای کاربر رخ می دهد. ما از Sentry در محل کار استفاده می کنیم و من در گذشته از Rollbar استفاده کرده ام.

9. ابزارهای مدیریت پایگاه داده: اگر با یک پایگاه داده کار می کنید، ابزارهایی برای مدیریت و جستجو در پایگاه داده خواهید داشت. توسعه دهنده وب اغلب داده های CRUD (ایجاد، خواندن، به روز رسانی، حذف) از یک پایگاه داده است. پایگاه داده اغلب کمترین مخرج مشترک در پشته است. شما می توانید از ابزار مدیریت پایگاه داده برای بررسی داده ها در پایگاه داده، اجرای پرس و جو و بررسی خطاها استفاده کنید. همچنین می توانید از ابزار مدیریت پایگاه داده برای بررسی وضعیت سرور پایگاه داده و اطمینان از اجرای آن مطابق انتظار استفاده کنید. به اندازه کافی SQL یاد بگیرید تا بتوانید به برخی از سوالات اساسی پاسخ دهید — (من هنوز SQL Zoo را توصیه می کنم!). اگر از ریل استفاده می کنید rails dbconsole یک میانبر برای ورود به رابط پایگاه داده و شروع پرس و جو است. اخیراً با برخی از مشکلات حافظه Redis دست به گریبان بودم و آن را پیدا کردم redis-cli ارزشمند بودن و آنقدر یاد گرفته اند که خطرناک باشند.

• چند کاربر با آنها ایمیل دارند test در آن؟
• چه می کند weather_days میز شبیه است؟

مقداری redis-cli اصول اولیه، برای شما!

10. LLM و StackOverflow: یادگیری پرسیدن سؤالات صحیح از موتور جستجوی خود (Google، GitHub یا StackOverflow) یا ابزار چت LLM مانند ChatGPT یا Claude می تواند به شما کمک کند سریعتر راه حل ها را پیدا کنید. هرچه پشته شما بالغ‌تر باشد، احتمال بیشتری وجود دارد که افراد دیگری دقیقاً با همان مشکل شما مواجه شوند و در مورد آن سؤال کرده باشند یا مشکلاتی را در GitHub ایجاد کرده باشند. همانطور که جان استوارت در مورد مهندسی سریع شوخی می کند، برای تبدیل شدن به یک “نوع-پرسش-مرد” خوب می تواند مفید باشد.

دوره مبارزه با نجات غریق

در آموزش اولیه ارتش، چندین مهارت اساسی نجات جان مانند CPR، استفاده از تورنیکت و درمان شوک را یاد گرفتیم. در گرمای لحظه، فراموش کردن اصول اولیه و گم شدن در هرج و مرج آسان است. بسیاری از موضوعات در آموزش های پایه از چارچوب های ساده و بیهوده ای استفاده می کنند تا بتوانید آنها را در گرمای لحظه به خاطر بسپارید. به عنوان مثال، زمانی که مصدومی را پیدا می کنید، باید ABC ها را به خاطر بسپارید: راه هوایی، تنفس، گردش خون.

آ. راه هوایی آنها را چک کنید، مشخص است؟ اگر نه، آن را پاک کنید.
ب. تنفس آنها را چک کنید، آیا آنها نفس می کشند؟ اگر نه، آنها را دهان به دهان بدهید.
سی. گردش خونشون رو چک کن نبض دارن؟ در غیر این صورت، خونریزی را متوقف کنید (از یک تورنیکت استفاده کنید) و پاهای آنها را بالا بیاورید.

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

غرغر جانبی: آیا نباید دروس اولیه نجات غریق برای عموم رایگان باشد؟! یکی باعث بشه این اتفاق بیفته!

یادگیری سریع از طریق عیب یابی

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

به عنوان یک مدرس آکادمی برنامه، به اندازه کافی خوش شانس بودم که با حمایت از دانشجویان توسعه وب، یادگیری خود را تسریع بخشم. در حین کار بر روی برنامه درسی، آنها با باگ‌ها و خطاهای جدیدی مواجه می‌شوند که آنها و سایر TA را از بین می‌برد، و من می‌توانم به یافتن و حل اشکالات کمک کنم. این تجربه فرصت‌هایی را برای من فراهم کرد تا با خطاهای جدید و متفاوت (گاهی خلاقانه و گیج‌کننده) مواجه شوم و تمام روز را به عیب‌یابی بگذرانم، به‌جای اینکه به تنهایی خودم را بسازم و فقط با اشکالاتی که ایجاد کرده‌ام مواجه شوم. من در حدود 2 سال 6-8 برابر بیشتر از مجموع 5 سال قبل یاد گرفتم.

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

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

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

این تجربه شهود و تشخیص الگو را ایجاد کرد و به شناسایی سریع علل ریشه کمک کرد.

به عنوان مثال، آیا می خواهید شایع ترین علت اصلی اشکالات در برنامه های وب را بدانید؟ املا!

از آنجایی که املایی یکی از رایج ترین اشتباهات است، ترجیح می دهم از آن استفاده کنم barewords بر فراز @instance_variables در روبی (با تشکر آودی). به این ترتیب، اگر یک متغیر را اشتباه املایی کنم، Ruby به جای ایجاد یک متغیر جدید، یک خطا ایجاد می کند. همچنین، دلیل مناسبی برای استفاده از TypeScript به جای جاوا اسکریپت و ابزارهای linting مانند ESLint است. این یک مثال ساده از نحوه نوشتن کد قوی تر از طریق عیب یابی است.

نکات و ترفندها

مسیر درخواست و پاسخ را طی کنید – این راه است. از اساسی ترین مؤلفه (کلاینت) شروع کنید و مسیر را به مؤلفه بعدی در زنجیره (سرور) دنبال کنید. در حالت ایده آل، هر جزء و پیوند را ایزوله کنید تا مطمئن شوید که همه قطعات همانطور که انتظار می رود کار می کنند. نحوه عملکرد سیستم های زیربنایی و نحوه تعامل آنها با یکدیگر را درک کنید.

1. مشتری: آیا مشتری مطابق انتظار درخواست را ارسال می کند؟ آیا درخواست به نقطه پایانی صحیح ارسال می شود؟ آیا درخواست با سربرگ و متن صحیح ارسال می شود؟

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

2. سرور: آیا سرور مطابق انتظار درخواست را دریافت می کند؟ آیا سرور مطابق انتظار پاسخ را ارسال می کند؟

- Look in the server logs to see if the request and the expected URL, headers, and request body are being received.
- Is the expected server code executing?
  - Is the route defined that knows how to pick which code should execute based on the request path?
  - Is the code that should be executing actually executing?

3. هر جا:

• از جریان کنترل پیروی کنید، آیا اجرا از شاخه های راست شرطی ها پیروی می کند؟
• آیا روش ها با آرگومان های مورد انتظار فراخوانی می شوند؟
• آیا تابع مقدار مورد انتظار را برمی گرداند؟
• آیا انواع اشیاء انواع مورد انتظار هستند؟
• آیا پاسخ‌های APIها و کتابخانه‌ها آنطور که کد شما انتظار دارد قالب‌بندی می‌شوند؟
• آیا اعتبار و ثابت ها و محیط ها همان چیزی هستند که انتظار دارید؟
• آیا پیام باید به کلاس منتقل شود یا یک نمونه؟
• آیا این به آنچه در جاوا اسکریپت انتظار دارید اشاره می کند؟

تماس های خود را

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

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