شما خواندن مستندات را متوقف کردید و حالا سیستم‌ها را درک نمی‌کنید

من علوم کامپیوتر را در دانشگاه تحصیل نکردم. من ژئوفیزیک خواندم.

من نرم‌افزار را با خواندن یاد گرفتم. مستندات، کد منبع و GitHub issues را خواندم. پست‌های قدیمی بلاگ و رشته‌گفتگوهای RFC را مطالعه کردم. از بوت‌کمپ استفاده نکردم؛ بلکه از یک مرورگر و منابع خام استفاده کردم.

وقتی Cloudflare Workers را یاد گرفتم، هیچ دوره‌ای در اختیار نداشتم. فقط مستندات و لیست تغییرات (changelog) را داشتم. برای رفع یک مشکل در استقرار (deployment) در ساعت ۱ بامداد، تنظیمات binding را سه بار خواندم. پاسخ‌ها را در رشته‌گفتگوهای GitHub از سال‌ها پیش پیدا کردم.

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

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

هدف قبلاً درک کردن بود. حالا هدف خروجی گرفتن است. مردم این را کارایی می‌نامند، اما در واقع این یک بدهی (technical debt) است.

شما می‌توانید یک circuit breaker بسازید بدون اینکه بدانید حالت half-open چیست. در تست‌های شما کار می‌کند، اما شش هفته بعد در محیط عملیاتی (production) و تحت بار سنگین، شکست می‌خورد. شما شکست می‌خورید چون هیچ مدل ذهنی ندارید. شما «چیستی» را بدون دانستن «چرایی» به دست آورده‌اید.

«چرایی» تنها بخشی است که اهمیت دارد.

خواندن مستندات یک مدل ذهنی می‌سازد. شما موازنه (tradeoffs) و موارد خاص (edge cases) را در پانویس‌ها می‌بینید. اصطکاکی که هنگام خواندن حس می‌کنید، همان جایی است که یادگیری اتفاق می‌افتد.

وقتی Bookmark Brain را ساختم، باید Cloudflare Vectorize را درک می‌کردم. من فقط از API استفاده نکردم؛ بلکه ابعاد embedding، رفتار ایندکس و معیارهای فاصله پرس‌وجو (query distance metrics) را مطالعه کردم. مقاله HNSW را خواندم و با سردرگمی‌ها کنار آمدم تا زمانی که به دانش تبدیل شدند.

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

این موضوع باعث ایجاد شکافی در مهندسی می‌شود.

  • در بازبینی کد (code reviews): یک توسعه‌دهنده بلافاصله متوجه مشکل N+1 می‌شود چون مستندات ORM را خوانده است. توسعه‌دهنده دیگر آن را از دست می‌دهد چون فقط کد را تولید کرده است.
  • در معماری: یک توسعه‌دهنده پارتیشن‌ها و آفست‌های Kafka را درک می‌کند. دیگری فقط واژگان را می‌داند اما ساختار را ندارد.
  • در عیب‌یابی (debugging): عیب‌یابی تابعی از مدل ذهنی شماست. بدون آن، شما فقط چیزها را تغییر می‌دهید و امیدوارید که بهترین نتیجه حاصل شود.

هوش مصنوعی نمی‌تواند یک معماری کامل را در خود جای دهد. هوش مصنوعی تصویر کلی کل کد شما را نمی‌بیند. من دیده‌ام که لایه‌های کش ساخته شده توسط هوش مصنوعی، تمام تست‌ها را پاس می‌کنند و سپس در محیط عملیاتی کرش می‌کنند، چون هیچ انسانی شرایط رقابتی (race conditions) را درک نکرده بود.

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

آیا از آن برای درک موازنه (tradeoffs) استفاده می‌کنید؟ یا از آن برای فرار از درک کردن استفاده می‌کنید؟

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

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

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

Source: https://dev.to/dannwaneri/you-stopped-reading-the-docs-now-you-dont-understand-the-systems-go1

Optional learning community: https://t.me/GyaanSetuAi