انتخاب ویرایشگر را با جدول «برای این زبان آن IDE» عوض نکن. آن جدول‌ها سریع کهنه می‌شوند و معمولاً یک نام را برای همه کارها تکرار می‌کنند. سؤال درست این است که روز کاری تو بیشتر از چه نوعی است و کدام محیط همان نوع را با اصطکاک کمتر انجام می‌دهد. ویرایشگر قرار نیست هویت تو باشد. قرار است بین قصد تو و اجرای کد فاصله را کوتاه کند.
اگر این فاصله را با قابلیت‌های تبلیغاتی اندازه بگیری، گمراه می‌شوی. تکمیل هوشمند، چت داخل ویرایشگر، و پوسته زیبا اگر دیباگر به برنامه واقعی وصل نشود یا جستجو در مخزن کند باشد، وقت را برنمی‌گردانند. یک هفته کار روی باگ خودت معیار بهتری از یک بعدازظهر با پروژه نمونه است.
اول شکل کار را نام ببر
قبل از نصب هر چیز تازه، بنویس این ماه بیشتر چه می‌کنی. یک زبان با ریفکتور زیاد در یک مخزن بزرگ. چند زبان در یک روز، با فایل پیکربندی و اسکریپت کنار هم. توسعه روی پلتفرمی که زنجیره ابزارش را خودش مالک است، مثل اپ بومی موبایل. یا کار از راه دور روی ماشینی غیر از لپ‌تاپ خودت. این‌ها ویرایشگرهای متفاوت را توجیه می‌کنند. «بهترین برای JavaScript» این فرق را پاک می‌کند.
اگر بیشتر وقتت در یک اکوسیستم است که ریفکتور، رفتن به تعریف، و تحلیل نوع سنگین است، محیط یکپارچه‌ای که همان زبان را عمیق می‌فهمد اغلب می‌ارزد. نه به‌خاطر اینکه لوگویش کنار آن زبان آمده. به‌خاطر اینکه تغییر نام، استخراج تابع، و دیباگ را بدون چسباندن افزونه ناقص انجام می‌دهد. اگر بیشتر بین زبان‌ها و مخزن‌ها می‌پری، یک ویرایشگر سبک با پروتکل زبان (LSP) ممکن است عادت دستت را ثابت نگه دارد و برای هر زبان فقط سرور زبان را عوض کند. ثبات میانبر گاهی از عمق یک زبان ارزشمندتر است.
پلتفرم را جدا ببین. جایی که اجرای شبیه‌ساز، امضا، و ابزار رسمی فقط در IDE سازنده درست کار می‌کند، جنگیدن برای ویرایشگر محبوب معمولاً هزینه خالص است. آنجا ویرایشگر را تابع زنجیره ابزار کن. برای بقیه کارها آزاد هستی. لازم نیست یک انتخاب همه‌جا برنده باشد. لازم است بدانی کی در حال استثنا هستی.
چه چیزی را در آزمایش یک‌هفته‌ای بسنج
آزمایش را روی کاری بگذار که همین هفته باید انجام شود. یک باگ، یک ریفکتور کوچک، یک تست. در پایان هفته این‌ها را جواب بده. آیا از خطا به خط مسئول رسیدی، یا فقط متن را دیدی؟ آیا اجرای دیباگ با نقطه توقف روی کد خودت کار کرد، نه فقط روی نمونه سالم؟ آیا جستجو و رفتن به تعریف در مخزن واقعی سریع بود یا فقط در پروژه کوچک؟ آیا قالب‌بندی و تحلیل با همان قواعدی است که CI تیم اجرا می‌کند؟
مورد آخر را جدی بگیر. محیطی که محلی یک شکل نشان می‌دهد و در pipeline شکل دیگری، تو را به جنگ با diff بیهوده می‌اندازد. ویرایشگر خوب برای تیم، همان قراردادی را اجرا می‌کند که مخزن اجرا می‌کند. زیبایی پیش‌فرض فروشنده اگر با آن قرارداد نجنگد خوب است. اگر بجنگد، باید خاموش شود.
افزونه را هم بخشی از هزینه بدان. ویرایشگری که روز اول سبک است و روز دهم بدون ده افزونه قابل استفاده نیست، ممکن است شکننده‌تر از یک IDE سنگین و منسجم باشد. هر افزونه یک به‌روزرسانی و یک حالت شکست است. اگر قابلیت برای کار روزانه حیاتی است و فقط با افزونه غیررسمی می‌آید، آن را در حساب یک‌هفته‌ای بنویس نه در تبلیغ روز اول.
لایه هوش مصنوعی معیار اصلی نیست
چت و تکمیل مدل داخل ویرایشگر می‌تواند مفید باشد و نباید دلیل اصلی انتخاب باشد. مدل‌ها و افزونه‌هایشان سریع عوض می‌شوند. دیباگر، سرور زبان، و سرعت کار با فایل‌های زیاد کندتر عوض می‌شوند و هر روز به آن‌ها برمی‌خوری. اگر دو محیط در این سه تا نزدیک‌اند، آن وقت لایه کمک مدل را مقایسه کن. اگر در این سه تا فاصله زیاد است، چت بهتر جبران نمی‌کند.
هر طور که انتخاب کردی، خروجی مدل را هنوز خودت بخوان. ویرایشگری که پیشنهاد بزرگ را با یک کلید می‌پذیرد، خطر پذیرفتن نفهمیده را زیاد می‌کند. این خاصیت زبان برنامه‌نویسی نیست. خاصیت جریان کار است. محیطی بهتر است که diff را قبل از وارد شدن به فایل راحت نشان دهد. این را در همان هفته آزمایش نگاه کن: آیا می‌فهمی چه چیزی وارد کد شده یا فقط حس جلو رفتن داری.
و داده را فراموش نکن. اگر ویرایشگر زمینه را به سرویس بیرونی می‌فرستد، محدوده مخزن و رازها باید برایت روشن باشد. راحتی تکمیل، مجوز فرستادن کد مشتری یا کلید را نمی‌دهد. این سؤال را از جدول مقایسه زبان‌ها درنمی‌آوری. از تنظیمات خود محیط درمی‌آوری، روز اول نه بعد از عادت کردن.
کی عوض کردن درست است
عوض کن وقتی اصطکاک مشخص و تکراری داری: دیباگ وصل نمی‌شود، ریفکتور اساسی را دستی انجام می‌دهی، یا محیط با قواعد تیم نمی‌خواند. عوض نکن چون رتبه‌بندی تازه‌ای دیدی یا چون کسی در یک زبان خاص یک نام را گفته. هزینه عوض کردن، افت سرعت چند هفته‌ای و چسباندن دوباره میانبر و ابزار جانبی است. این هزینه فقط وقتی برمی‌گردد که درد قبلی واقعاً هر روز بوده باشد.
اگر تیم یک محیط را استاندارد کرده تا دیباگ و نسخه ابزار یکی باشد، انحراف شخصی را ارزان فرض نکن. حق داری ابزار خودت را داشته باشی اگر خروجی‌ات با قرارداد مخزن یکی است. حق نداری بقیه را وارد تنظیم خصوصی‌ای کنی که فقط روی ماشین تو کار می‌کند. انتخاب ویرایشگر تا جایی شخصی است که مسئله مشترک را شخصی نکند.
در نهایت محیط را مثل هر ابزار دیگر با کار بسنج. یک هفته، روی مسئله واقعی، با معیار دیباگ و هماهنگی با CI. اسم زبان در عنوان مقاله کسی دیگر این آزمایش را حذف نمی‌کند. اگر بعد از هفته هنوز برای کار اصلی به محیط قبلی برمی‌گردی، جواب را گرفته‌ای حتی اگر فهرست‌ها چیز دیگری بگویند.
پرسش‌های کوتاه
یک ویرایشگر برای همه زبان‌ها؟ اگر مدام بین زبان‌ها می‌پری، ثبات عادت معمولاً بهتر از بهینه محلی هر زبان است. استثنای پلتفرم رسمی را جدا کن.
IDE سنگین یا ویرایشگر سبک؟ اگر ریفکتور و تحلیل عمیق هر روز کار توست، سنگینی منسجم می‌ارزد. اگر بیشتر فایل‌های متفاوت و فرمان‌های کوتاه است، سبکی با LSP اغلب کافی است.
چطور بفهمم عادت شده‌ام نه اینکه ابزار بهتر است؟ ببین کار آزمایشی واقعاً مسئله این هفته بود یا نمونه راحت. اگر دیباگ و CI را در آزمایش راه نینداختی، هنوز انتخاب نکرده‌ای.