تجربه توسعه‌دهندگی یا همان DX

احتمالا همه ما با مفهومی به نام UX یا همون «تجربه کاربری» آشنا هستیم یا حداقل اسمش به گوشمان خورده اما اصطلاح DX شاید کمتر به زبان آمده باشه و یا راجع بهش صحبت شده باشه. Developer Experience یا همون «تجربه توسعه‌دهندگی» زمانی به کار برده می‌شود که محصول ما یک API است و مخاطب اون برنامه‌نویس‌ها و توسعه‌دهندگان هستند.

DX چیست؟

دی اکس درباره احساس توسعه‌دهندگان – وقتی که با یک API تعامل دارند- صحبت می‌کند . از آنجایی که معمولا دولوپرها رو آدم‌های باهوشی دانیم ممکن است زیاد به این بُعد توجه نشود و فقط زمانی اهمیت پیدا کند که کمپانی (‌با محصول API) در برابر رقیب‌هاش (با محصولی مشابه)  احساس خطر کند.

در حالی که مفهوم Developer Expericence حتی در داخل یک کمپانی با معماری سرویس‌گرا هم می‌تواند از هدر رفتن وقت دولوپرها در تعامل با سرویس‌ (یا API) های مختلف داخلی جلوگیری کند.

چرا تجربه توسعه‌دهندگی اهمیت دارد؟

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

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

برای داشتن DX بهتر، باید چه کارهایی انجام داد؟

حالا که به اهمیت این تجربه پی بردیم باید بدونیم چه کارهایی باعث بالاتر رفتن این معیار میشه و مشتریان رو خوشحال‌تر نگه می‌داره.

• فرآیند فهم API رو آسان‌تر کنید:

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

• استفاده از API رو آسان‌تر کنید:

  گام‌های «غیرکدی» استفاده از محصول رو تا جایی که ممکن است کم کنید؛ ثبت‌نام برای استفاده از محصول، تماس با بخش فروش برای گرفتن خدمات و هر چیزی که باعث می‌شود روند کاری یک برنامه نویس رو مختل و کند کند. برای برنامه‌نویسان با زبان‌های مختلف SDK تهیه کنید. این کار باعث می‌شود کاربران با انگیزه بیشتری به سمت محصول شما بیایند.  اگر فکر می‌کنید تهیه و نگهداری از اس‌دی‌کی‌هایی که برای آی‌پی‌آی تان تهیه کردید زمان زیادی را از منابع انسانی شما میگیرد آنها رو به پروژه های متن‌باز تبدیل کنید و روی گیت‌هاب قرار بدهید. این طوری مشتریانتان در توسعه و رفع باگ‌های احتمالی SDK ها مشارکت کرده و روند رشد رو تسریع می‌کنند.

• خطایابی API رو آسان‌تر کنید:

  دیباگ کردن به خودی خود کار طاقت‌فرسا و خسته‌کننده‌است چه برسد در مورد برنامه‌ای باشه که از یک API استفاده میکند. راه‌حل این کار یک API Dashboard ئه. این دشبورد جایی‌ست که برنامه نویس به آنجا مراجعه کرده و لاگ ریکوئست‌ها و کال‌بک‌هایش را میبیند و از این طریق عیب‌یابی برایش راحت‌تر انجام می‌شود.

• فرآیند کمک‌گرفتن توسعه‌دهندگان رو آسان‌تر کنید:

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

امیدوارم نکات بالا که سعی کردم خلاصه بیانشان کنم به دردتان خورده باشد؛ فیدبک‌های شما می‌تواند به بهتر شدن و بالا رفتن کیفیت مطالب کمک کنه ; )