نمای کلی اجرایی و اهمیت معماری
انتشار interactive-refactoring-in-gopls نشان‌دهنده یک تغییر پارادایم در نحوه ارتباط سرورهای زبان با کلاینت‌های IDE است که یک شکاف معماری دیرینه را در پروتکل سرور زبان (LSP) پر می‌کند. از لحاظ تاریخی، LSP بر روی یک مدل سخت‌گیرانه بدون پارامتر برای اقدامات و تبدیل‌های کد عمل کرده است. به جز تغییر نام نماد از طریق RPC اختصاصی PrepareRename، سرورهای زبان مجبور بودند یا نیت کاربر را به طور کامل از بافت‌های درخت نحوه استاتیک (AST) استنتاج کنند یا به طور کلی از بازسازی‌های پیچیده صرف‌نظر کنند. این امر برای جریان‌های کاری توسعه‌دهنده ظریفی که نیازمند پارامتری‌سازی زمان اجرا بودند، مانند انتخاب تگ‌های سریال‌سازی، پیکربندی قراردادهای نام‌گذاری، یا نگاشت پیاده‌سازی‌های رابط در بسته‌های مختلف، اصطکاک ایجاد می‌کرد.
این نسخه با همکاری نزدیک تیم Dart، یک استاندارد باز پیشنهادی برای گفتگوهای تعاملی چندمرحله‌ای مستقیماً در مشخصات LSP (microsoft/language-server-protocol#1164) معرفی می‌کند. با عبور از راه‌حل‌های موقت خاص ویرایشگر که اکوسیستم را تکه‌تکه می‌کنند، gopls نسخه 0.24.0 و افزونه رسمی VS Code Go نسخه 0.56.0 یک مکانیزم عمومی ایجاد می‌کنند. سرورهای زبان اکنون می‌توانند قبل از محاسبات ویرایش متن، از کاربران ورودی‌های پویایی مانند مسیرهای فایل هدف، انواع فرمت، یا پارامترهای نوع را درخواست کنند. این تکامل معماری تضمین می‌کند که بهبودهای اساسی ایجاد شده در gopls فوراً هر ویرایشگر سازگاری، چه VS Code، Neovim یا Emacs را غنی می‌کند، بدون اینکه خلوص پروتکل قربانی شود یا منطق به افزونه‌های سمت کلاینت غیرمتمرکز گردد.
بهبودهای اصلی و ارگونومی توسعه‌دهنده
یکپارچه‌سازی بازسازی تعاملی، مجموعه‌ای از جریان‌های کاری پیشرفته توسعه‌دهنده را باز می‌کند که قبلاً غیرممکن بودند یا به شدت محدود بودند. در میان بهبودهای اولیه، مدیریت بازطراحی‌شده تگ‌های ساختار (struct tags) قرار دارد. قبلاً، فعال کردن «افزودن تگ‌های ساختار» یک پیش‌فرض سخت‌افزاری سفت‌وسخت از تگ‌های json با قالب‌بندی camelCase را تحمیل می‌کرد. با قابلیت‌های تعاملی جدید، توسعه‌دهندگان اقدام کد را فعال کرده و به صورت متوالی با اعلان‌های ورودی برای مشخص کردن ترکیبات سریال‌سازی سفارشی (مانند json,yaml,db) و انتخاب استراتژی‌های دقیق نام‌گذاری مانند snake_case یا PascalCase روبرو می‌شوند. به همین ترتیب، «حذف تگ‌های ساختار» از یک پاک‌سازی بی‌رویه به یک مدل حذف هدفمند تغییر می‌کند و امکان فیلتر کردن دقیق کلیدها را فراهم می‌کند.
یکی دیگر از قابلیت‌های اساسی، پیاده‌سازی پویای رابط (interface) است. ساخت استاب‌های متد برای برآورده کردن رابط‌های پیچیده قبلاً نیازمند پیش‌نویس کردن دستی الگوها یا ابزارهای خط فرمان خارجی بود. اکنون، فراخوانی «افزودن متدها برای پیاده‌سازی یک رابط» یک اعلان جستجوی نماد پویا را باز می‌کند که فضای کاری و کتابخانه استاندارد (به عنوان مثال، maphash.Hasher) را پرس‌وجو می‌کند. اگر رابط انتخاب شده از پارامترهای نوع استفاده کند، gopls به اعلان‌های بعدی منتقل می‌شود تا استدلال‌های نوع مشخص را قبل از تولید استاب‌های متد کاملاً نمونه‌سازی شده و ایمن از نوع، کامل با بلوک‌های دریافت‌کننده مناسب، ضبط کند. پیاده‌سازی‌های پیش‌نمایش برای جابجایی‌های اعلامیه بین فایلی و بین بسته‌ای، نگهداری پایگاه کد در مقیاس بزرگ را بیشتر ساده می‌کند، خطاهای کپی و پیست دستی و سربار مدیریت واردات را کاهش می‌دهد.
ماتریس مقایسه معماری
| متریک / بعد | مبنای قبلی (gopls < v0.24.0) |
نسخه فعلی (interactive-refactoring-in-gopls) |
تأثیر معماری |
|---|---|---|---|
| تأخیر تبدیل | اجرای تک‌مرحله‌ای آنی که صرفاً بر اساس بافت AST استاتیک است. | تبادل JSON-RPC ناهمزمان چندمرحله‌ای که تأخیر تعامل کاربر ناچیزی را ایجاد می‌کند. | امکان ثبت دقیق نیت بدون فدای عملکرد ارزیابی AST در سمت سرور را فراهم می‌کند. |
| ردپای حافظه | سربار حافظه بیکار کم؛ ردیابی وضعیت حداقل در سمت کلاینت برای بازسازی‌ها. | افزایش جزئی استمرار بافت در طول جلسات گفتگوی فعال برای کش کردن ورودی‌های کاربر. | مدیریت کارآمد وضعیت گذرا تضمین می‌کند که هیچ نشت حافظه‌ای در جلسات قطع شده LSP وجود ندارد. |
| انطباق با API مربوط به LSP | به مدل‌های اجرای استاندارد textDocument/codeAction بدون پارامتر پایبند بود. |
LSP استاندارد را از طریق پیشنهاد microsoft/language-server-protocol#1164 گسترش می‌دهد. |
یک استاندارد جهانی و چند ویرایشگر برای گفتگوهای پویا هدایت شده توسط سرور ایجاد می‌کند. |
| قابلیت حمل ویرایشگر | تکه‌تکه شده؛ گفتگوهای پیشرفته نیازمند کد سفارشی سمت کلاینت به ازای هر ویرایشگر بودند. | در سراسر VS Code، Neovim، Emacs، و هر کلاینت LSP که از این پیشنهاد پشتیبانی می‌کند، جهانی است. | منطق جریان کاری UI را از پیاده‌سازی‌های خاص کلاینت جدا می‌کند. |
تغییرات اساسی و نکات مهاجرت
معرفی بازسازی تعاملی کاملاً با تعاملات پروتکل قبلی gopls سازگار است. اقدامات کد بدون پارامتر موجود، عیب‌یابی‌ها، ارائه‌دهندگان هاور و اکتشافات تکمیل به کار خود بدون تغییر ادامه می‌دهند. با این حال، بهره‌برداری کامل از قابلیت‌های جدید بازسازی تعاملی چندمرحله‌ای مستقیماً نیازمند پشتیبانی خاص سمت کلاینت برای برنامه‌های افزودنی گفتگوی پیشنهادی LSP است.
توسعه‌دهندگان باید اطمینان حاصل کنند که محیط‌های توسعه‌شان gopls نسخه 0.24.0 (یا بالاتر) را به همراه یک پیاده‌سازی سازگار کلاینت، مانند افزونه رسمی Go برای VS Code نسخه v0.56.0 اجرا می‌کنند. کاربرانی که از کلاینت‌های حداقل LSP (به عنوان مثال، پیکربندی‌های خاص Neovim یا افزونه‌های قدیمی‌تر Emacs LSP) استفاده می‌کنند که هنوز پیشنهاد افزونه LSP بازسازی تعاملی را اتخاذ نکرده‌اند، در صورت وجود، به طور ظریف به رفتارهای پیش‌فرض و غیرتعاملی اقدام کد بازمی‌گردند و اطمینان حاصل می‌کنند که هیچ خرابی فاجعه‌بار کلاینت یا عدم همگام‌سازی پروتکل رخ نمی‌دهد.
راهنمای ارتقای گام‌به‌گام
برای پذیرش و استفاده از قابلیت‌های بازسازی تعاملی در جریان کاری توسعه Go خود، این مراحل پیکربندی و به‌روزرسانی را دنبال کنید:
به‌روزرسانی افزونه Go و باینری
gopls: اطمینان حاصل کنید که محیط شما نسخه‌های مورد نیاز را با به‌روزرسانی ابزارهای خود از طریق افزونه‌های VS Code یا مستقیماً از طریق زنجیره ابزار Go اجرا می‌کند:go install golang.org/x/tools/[email protected]تأیید کنید که افزونه VS Code Go شما به نسخه
v0.56.0یا بالاتر به‌روزرسانی شده است.پیکربندی تنظیمات کلاینت LSP خود (اختیاری): اگر از Neovim با
nvim-lspconfigیا یک کلاینت سفارشی استفاده می‌کنید، اطمینان حاصل کنید که گزینه‌های راه‌اندازی سرور شما در صورت نیاز توسط مدیر افزونه