تجربه برنامه‌نویس یا DX چیست و چطور DX بهتری خلق کنیم؟
اگر مخاطب محصول نرم‌افزاری ما برنامه‌نویس‌ها هستند، با داشتن یک تجربه کاربری بهتر، شانس بیشتری برای معرفی و توصیه خواهیم داشت
DX چیه و چرا مهمه؟
DX مخفف Developer Exprience همون تجربه کاربری یا UX است برای وقتی که کاربر نرم‌افزار ما یک برنامه‌نویس باشه. در واقع DX کمک می‌کنه برنامه‌نویس‌ها زندگی راحت‌تری داشته باشند و موقع کار با برنامه‌ها و APIها از کارشون لذت ببرند.
ممکنه بخواهید بدونید چرا مهمه DX داشته باشیم؟ یعنی خب مگه برنامه‌نویس کارش این نیست که با نرم‌افزارها و APIهای مختلف کار کنه؟ چه لزومی داره این تجربه لذت‌بخش باشه؟ خب وقتی کتابخانه برنامه‌نویسی یا SDK یا API ما DX خوبی داشته باشه، برنامه‌نویس‌ها خوشحال‌ترن، بیشتر معرفیش می‌کنن و زمان طولانی‌تر از محصول نرم‌افزاری ما استفاده خواهند کرد
چطور DX خوبی ارائه کنیم؟
یک سری توصیه‌های عمومی برای ارائه یک تجربه برنامه‌نویس خوب وجود داره که اینجا مفصل بهشون پرداخته شده و من به تعدادی از مهم‌ترین‌هاشون خیلی لیست‌وار اشاره می‌کنم:
- مستندات خوب و کامل
- لیست تغییرات (Changelog) و Release Note خوب
- رعایت استانداردها
- deprecate کردن متدهای قدیمی به جای حذف یا تغییر منطقشون
اینکه از بین کلیه موارد اشاره شده در این مقاله فقط این ۴ مورد رو انتخاب کردم به این خاطر است که به نظرم ریشه بسیاری از ایرادات در حوزه DX به همین ۴ مورد برمی‌گرده.
البته فرض من اینه که ایرادات واضح مثل اینکه API در صورت مشکل هم به جای کد مناسب خطا، کد 200 برگردونه نداشته باشیم. در واقع فرض اصلی اینه که محصولی که می‌خواهیم DX بهتری داشته باشه، حداقل‌های یک محصول نرم‌افزاری رو داره و حالا می‌خواهیم تجربه کاربر برنامه‌نویس‌ها با این محصول رو قشنگ‌تر و لذت‌بخش‌تر کنیم.
هر کدوم از این ۴ توصیه برای داشتن DX بهتر، نیازمند پست جداگانه‌ای هستند اما تا اون موقع برای اینکه گام به گام تجربه دولوپرها رو از library,SDK,API یا هر محصول نرم‌افزاری دیگری که داریم بهتر کنیم کمی باید روی مدل ذهنی خودمون کار کنیم.
یک کار خوب می‌تونه این باشه که ببینیم بزرگان صنعت چه می‌کنن؟ مثلاً این راهنمای مایکروسافت برای نوشتن API رو ببینید که چطور بخش‌های مختلف اجرای یک کار تمیز رو توضیح داده.
اگر می‌خواهیم لیست تغییرات داشته باشیم، بریم ببینیم یک changelog خوب چطوری نوشته می‌شه.
استانداردهای پلتفرمی که براش محصول ارائه کردیم رو بخونیم و منطبق بر اون به دولوپرها سرویس بدیم. موارد کوچک اما مهم مثل نامگذاری صحیح و منطقی متغیرها و توابع رو رعایت کنیم که خودش بخشی از مستندسازی محسوب می‌شه.
نسخه‌بندی رو به شکل مناسبی اجرا کنیم. مثلاً به روش semver و از همه مهم‌تر به این فکر کنیم وقتی در نسخه جدید، منطق یا نامگذاری توابع و پارامترها رو عوض می‌کنیم چه بلایی سر کدهای قدیمی میاد؟ همه تلاشمون رو بکنیم به جای breaking change (که گاهی اجتناب ناپذیر هستند) تا جای ممکن از روش deprecation استفاده کنیم یعنی ضمن حفظ منطق و توابع قدیمی، یک روش یا منطق جدید معرفی کنیم و ضمن تشویق دولوپرها به استفاده از روش جدید، متدهای قدیمی رو به عنوان منسوخ شده علامت بزنیم و توضیح هم بدیم که به جای این متد منسوخ از چه متد دیگه‌ای باید استفاده کرد.
فعلاً این نوشته رو قبول کنید تا برسیم سر فرصت درباره روشهای بهبود DX تک به تک به صورت مفصل‌تر صحبت کنیم. شما چه ایده‌ای برای بهبود DX دارید؟