سعید قاسمی
سعید قاسمی
خواندن ۶ دقیقه·۵ سال پیش

(DX (Developer Experience چیست و چرا مهم است؟

تو این مطلب می خوام درباره (DX (Developer Experience (معادل فارسی پیدا نکردم بیاین از همین DX استفاده کنیم) صحبت کنم. و میخوام راجع به مباحث زیر توضیح بدم:

  • وقتی میگیم DX از چی حرف میزنیم؟
  • چرا DX مهمه؟
  • چطور DX بهتری داشته باشیم؟
  • تاثیر DX روی کیفیت و سرعت توسعه محصول
  • مزایا و هزینه های DX برای سازمان چی میتونه باشه؟
  • آیا به یک DX Designer نیاز خواهیم داشت؟
DX (Developer Experience)  چیست؟
DX (Developer Experience) چیست؟

وقتی میگیم DX از چی حرف میزنیم؟

این روزها بازار X ها خیلی داغه از (UX (User Experience گرفته تا (CX (Customer Experience و (EX (Employee Experience و امروز راجع به یه X دیگه صحبت کنیم به اسم :

DX (Developer Experience)

این DX همون تجربه کاربری یا UX است برای وقتی که کاربر محصول، کدهای اوپن سورس، API ، پروژه، پلاگین و ... ما یک برنامه‌نویس باشه. در واقع DX کمک می‌کنه برنامه‌نویس‌ها زندگی راحت‌تری داشته باشند و موقع کار با کدها از کارشون لذت ببرند.

چرا DX مهمه؟

به همون دلیل که UX مهمه! وقتی کاربران از محصول ما راضی باشن و چیزی رو که اونا میخواستن رو بهشون دادیم به هدفی که میخواستیم رسیدیم و خیلی خوشحالیم. ولی دولوپر ها چی؟ خوشحال بودنشون چه قدر مهمه؟ این که از کارشون لذت ببرن چه قدر میتونه روی خروجیشون تاثیر بزاره؟ و این خروجی چه قدر روی کیفیت محصول و اهداف بیزینس تاثیر میزاره؟ احتمالا شما هم مثل من به این نتیجه رسیدید که دولوپر خوشحال تاثیر مستقیم روی کیفیت محصول و اهداف بیزینس داره.

هر چند ما اغلب دوس داریم صحبت نکنیم و توی کد ها غرق باشیم (به قول دوستی دولوپرها آدمای darkی هستن) و شاید واسه همین باشه که آخرین X برای ما دولوپرهاست. شاید وقتش باشه از خودمون دفاع بکنیم و از مشکلاتمون صحبت کنیم تا این فلسفه DX رو جا بندازیم. ولی نکته جالب این قضیه اینه که ما دولوپرها باید خودمون DX رو برای خودمون بهتر کنیم و مطالبه گرش باشیم...

چطور DX بهتری داشته باشیم؟

یک نکته ای که باید بهش توجه کنیم اینه که DX ربطی به EX نداره و حوزه کاری DX تماما بر میگرده به کیفیت کدنویسی! و این کد باید چطور باشه و چه پیشنیاز های باید داشته باشه که ما به یک DX خوب برسیم در حالی که EX مربوط میشه فضای کاری و اقدامات منابع انسانی و ... .

و اما موارد مهمی که باعث DX خوب میشه:

1- مستندات

احتمالا برای همه ما دولوپرها پیش اومده که وارد پروژه شدیم که کد های به شدت پیچیده و کثیف داره! و شما گفتید "oh! shit"و بعد، از رفتن به اون شرکت یا گرفتن پروژه پشیمون شده باشید.

مستندات نویسی یکی از مهم ترین اصول DX هست! همیشه برای پروژه تون مستندات بنویسید نه فقط تکنولوژی های استفاده شده بلکه ماژول ها و نحوه استفاده از اون ها و حتی اگه از یک ماژول استفاده کردید و به مشکل خوردید و عوضش کردید این رو هم تو مستنداتتون بنویس و از علت تغییرش بنویسید تا اگه نفر بعدی خواست استفاده کنه متوجه باشه.

ثبات و پایبندی به مستندات خیلی مهمه! اگه چند نفرید و دارید یک مستندات رو مینویسید حواستون باشه با یک اصول و ساختار نوشته شده باشه و حتما در طول پروژه بهش پایبند باشید از تغییر تو پروژه تون انجام دادین چیزی کم و زیاد کردین حتما مستنداتتون رو آپدیت کنید.

نحوه مستندات نویسی و ساختارش خیلی مهمه، اگه مستندات پکیج های خارجی رو دیده باشید با یک "Getting Started" شروع شدن و بعدش درباره نحوه نصب و نیازمندی هاش نوشتن و بعد وارد جزئیات شدن. متاسفانه ما تو کشورمون خیلی به مستندات نویسی پروژه هامون اعتقاد نداریم و وقتی که نیروی جدید قرار به تیممون اضافه بشه کلی باید تلاش کنه تا متوجه ساختار پروژه باشه! و وای اگه متوجه نشده و واسه خودش ساختار جدید تعریف کنه که اون پروژه یک اسپاگتی کدی بیش نیست!

2- یادداشت های امکانات جدید و تغییر در کد قبلی Release Notes and Changelogs

وقتی پروژمون آپدیت میشه حواسمون باشه لیست Release Notes ها رو شفاف بنویسم چه چیزهایی جدید اضافه شده چه چیزهایی فیکس و چه چیزهایی تغییر کده تا دولوپرهایی که میخوان آپدیت کنن متوجه تغییرات باشن.

3- رعایت استانداردها و اصطلاحات

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

4- ابزاهای

گاهی توسعه یک نرم افزار بستگی به نوع نرم افزار و ورژن های مختلف اون داره مطمئن بشیم که این هارو توی مستنداتمون نوشته باشیم

5- توضیح درباره متدها

وقتی متدی نوشته میشه حالت های مختلفش رو تو مستنداتتمون بیاریم مثلا چه زمانی true میشه چه زمانی false میشه چه اتفاقی بیوفته null برمیگردونه ، پارامترهای ورودی چیه و ...

6- متدهای حذف شده و Deprecated شده

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

7- تعیین Namespace

اگر دارید به صورت تیمی کار میکنید Namespaces خیلی میتونه مهم باشه و باعث یک دست شدن ساختار پروژه ها و سریع تر کار کردن دولوپر ها باشه

8- نوشتن Read Me

سعی کنید حتما برای پروژتون Read Me داشته باشید. و به طور خلاصه توضیحات و نحوه نصب و مثال ها و راهنمایی هارو بنویسید.

9- دستورالعمل Code of Conduct

مشخص کردن دستورالعمل یا اصطلاحا Code of Conduct برای پروژه های اپن سورسی و تیمی خیلی مهمه و باعث یک دست شدن و تمیز شدن کد ها میشه به طوری که کدی که هم تیمی شما می نویسه با کد شما فرقی نمیکنه و سریع میتونید کد رو ریویو کنید.


اینا مواردی مهم و تاثیر گذاری روی DX بود که قطعا موارد بسیاری دیگه هم هست که اگه رعایت بشه بسیار زندگی با دولوپر هارو راحت تر میکنه و برای جا انداختن همچین فرهنگی باید از خودمون شروع کنیم سعی کنیم این موارد رو رعایت کنیم. فک نمیکنیم اگه به شرکتی برید که این موارد رو رعایت کرده باشن کار خیلی براتون جذاب خواهد بود؟

تاثیر DX روی کیفیت و سرعت توسعه محصول

رعایت نکات DX و بهبودش میتونه روی کیفیت کدهامون تاثیر بزاره و تکنیکال دبت رو بسیار کاهش بده و دیگه خبری از اسپاگتی کد نیست و تماما کلین کد نوشته میشه و این باعث میشه سرعت دولوپ محصول به مراتب بالاتر بره و اگه نیروی جدیدی به تیممون اضافه میشه سریع میتونه team-up بشه

مزایا و هزینه های DX برای سازمان چی میتونه باشه؟

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

ولی هر چیز خوبی یه هزینه ای داره! سازمان باید هزینه زمانی بهبود DX رو بده و دید بلند مدت داشته باشه دولوپر باید زمان لازم رو برای نوشتن مستندات ، بروز نگه داشتن و پایبند بودن به مستندات و اصول تعریف شده رو داشته باشه. ولی امان از تسک های فورس ...!!!

آیا به یک DX Designer نیاز خواهیم داشت؟

همونطور که گفتم دولوپرها زیاد به صحبت کردن و توضیح دادن علاقه ای ندارد و مستندات نویسی هم از این قائده مستثنی نیست و بیشتر دوس دارن تو دنیای کد نویسی خودشون باشن.

شاید همین امر باعث بشه در آینده منتظر یک پوزیشن جدید DX Designer باشیم! کسی که بتونه مستندات پروژه رو بنویسه ، بروز نگه داره و بهش پایبند باشه و همینطور استفاده از نرم افزارها رو از لحاظ DX بررسی کنه ، درباره پکیج ها و ماژول ها و پروژه های اوپن سورس و انتخابشون نظر بده و سعی کنه ساختار و اصول کد نویسی رو در سازمان حذف کنه.


امیدوارم این مقاله به دردتون خورده باشه و تجربه کدنویسیتون رو بهبود بده و زندگی رو براتون لذت بخش تر بکنه!

اگه نظری داشتید خوشحال میشم باهام در میون بزارید ;)

تجربه کاربریدولوپرتوسعه نرم افزار
Front-End Developer & UI/UX Designer
شاید از این پست‌ها خوشتان بیاید