در این نوشته قصد دارم درمورد کارهای که از زمان حضورم (شهریور ۹۹) برای ارتقاء تجربه‌ی برنامه‌نویس انجام داده‌ایم، از تجاربی که موفق شدن، تجاربی که شکست خوردند و تجاربی که فوق‌العاده اثرگذار بودند بگم.
قبل از شروع، یه دور بریم DX یا Developer Experience رو ببینیم چی چی هست.
مختصر مفید بگم، تجربه‌ی برنامه‌نویس همون تجربه‌ایه که برنامه‌نویس هنگام توسعه محصول بهش دست پیدا می‌کند. ممکن است مثبت باشد یا منفی. برای مثال فرض کنید یک شرکت برای توسعه بک‌اند خود از فریمورک outdated استفاده کند و فرض کنیم که این فریمورک الکی سخته، در این حالت برنامه‌نویس هنگام توسعه لذت نمی‌برد که هیچ، بلکه اذیت می‌شود و ممکن است از کار زده شود. خیلی شرکت‌ها روی UX تمرکز می‌کنند اما یادمان نرود که برنامه‌نویس هم یه‌جوری کاربر شرکته. (اسکی رفته از متن این پست زیبا)
در کوئرا هم مشکلات DXی مثل سایر شرکت‌ها هست، در ادامه قراره یه سری کارهای که برای ارتقاء DX انجام دادیم را مرور می‌کنیم. امیدوارم مفید واقع شود.
همچنین این تجارب حول محور فرانت‌اند و ابزارهای آن می‌باشند. درمورد معماری دوست دارم در یک نوشته‌ی جداگانه بنویسم. خیلی دوست داشتم وارد جزئیات بشم که چه مزایای و معایبی داشتن ولی سعی کردم هرکدوم با یک مثال یا خطره این مورد رو رفع کنم، حس کردم دیگه خیلی بلند شده.
دو نوع تست داریم، تست دستی و تست اتوماتیک. تست دستی به این صورته که برنامه‌نویس به‌صورت دستی فیچری که پیاده‌سازی کرده رو تست می‌کند اما در تست اتوماتیک، یک کد برای اعتبارسنجی کد می‌نویسیم و هروقت تغییری ایجاد کردیم، با اجرای کد می‌توان فهمید که سیستم طبق خواسته‌های ما کار می‌کند یا خیر.
یکی از کارهای که دوست داشتیم بکنیم این بود که از تست‌های دستی جلوگیری کنیم، به مرور که سیستم بزرگ‌تر می‌شود خیلی احتمال این به‌وجود دارد که ما اشتباه کنیم یا چیزی جا بندازیم.
یاد یه خاطره افتادم، پارسال محمد یه سایدبار استیکی خفن درست کرده بود، کدش یه ذره پیچیده بود بالاخره مجبور بود case ها مختلفی هندل کند. به منم گفتن که برم فلان‌کارو بکنم حالا منه تازه‌وارد بله کداشو پاک کردم و با css اینو هندل کردم و با کلی ذوق کدهاشو پاک کردم و مرج‌ریکوست دادم. حدس بزنید چی شد؟ بلع گند زده بودم، برای حالت سایدبار دراز‌تر صفحه فکر نکرده بودم و با کلی WTF روبه‌رو شدم ??
اگر تست بود همون لحظه می‌تونستم بفهمم که سوتی دادم. خلاصه دست به کار شدیم و شروع کردم تست نوشتن برای کوئراکالج منم مسئول نوشتن بودم.
فکر کنم یه هفته درگیر بودم اما شکست خورد. بنظرم دلیلش این بود که خوب برنامه‌ریزی نکرده بودم و همچنین به اندازه کافی آماده نبودم.
هنگام تست نوشتن کلی سوال برام پیش‌اومده بود که مبهم بودن و این اتفاق باعث شد که کد کثیف شود و قابل استفاده نباشد.
اما یک سری درس یادگرفتم که از اونجایی که نمی‌خوام نوشته طولانی بشه پس نمی‌گم ??
اه تایپ‌اسکریپت، لذت‌بخش‌ترین زبانی که باهاش کار کرده‌ام (البته اگه می‌شه بهش گفت زبان، بالاخره این‌جور بحثا همیشه هستند) کلا خیلی خفنه.
چرا تصمیم گرفتیم تایپ اسکریپت رو وارد جنگ کنیم؟ اگر کاربر کوئرا هستید احتمالا با بخش بانک سوالات آشنایی داشته باشید.
آبان ۹۹ بود که صاحب محصولمون یک دیزاین جدید برای طراحی بانک‌سوالات به ما داد و خب به سلطان واگذار شد ? دیزاین سابق با Django Template پیاده‌سازی شده بود منم با دیدن دیزاین جدید گفتم که خب خیلی سخته بخوام اونجا ترتیبش بدم. پس تصمیم گرفتم بیارمش رو React.
از اونجایی که این محصول برای اولین بار قدمش داخل فولدر ری‌اکت گذاشت، تصمیم گرفتم بیام تایپ‌اسکریپت به پروژه اضافه کنم. فرصت خوبیه که هم یادبگیرم و هم یه ابزار قدرتمند به پروژه اضافه شود.
خوبه اینجا اضافه کنم که اگه پروژتون خوب با TypeScript نوشته‌شده باشه، همین الان بصورت خودکار تست استاتیک نوشته‌اید و خیلی جلو افتاده‌اید.
خلاصه شروع کردم پروژه رو با تایپ‌اسکریپت با کلی بدبختی زدم و تموم شد.
اون موقع فکر SEO نکرده بودم، هرچند درمورد اینکه گوگل با جاوااسکریپت اوکیه و می‌ذاره اجرا شه خونده بودم اما خب دقت نکرده بودم که بعد لود جاوااسکریپت تازه من باید ریکوست می‌زدم داده‌ی رو می‌گرفتم.
محمدجواد تیم لید تلنت هست گفت که سئو رو چکار کردی منم خب تازه‌وارد خام یه تست با Lighthouse گرفتم و اگه یادم باشه فکر کنم از ۱۰۰ نمره‌ی ۷ گرفتم ?
درسته اون تسک هیچوقت مرج نشد ولی نیمه پرلیوان این بود که اولین بار تو عمرم از cherry pick استفاده کردم و کانفیگ تایپ اسکریپت رو منتقل کردم به برنچ دیگه و اون توسط حضرت مرج شد.
اولین نویسنده‌ی تایپ‌اسکریپت در کوئرا هم محمد بود، این فرصتو از دست دادم ولی اوکیه باشه.
اینکه به مرور تایپ‌اسکریپت چه مزایای داشت در یک نوشته دیگری می‌گم ولی فعلا به همینا اکتفا کنید.
(درنهایت امسال تیم تلنت صفحه‌ی بانک‌سوالات با NextJS پیاده‌کرده‌اند.)
هیچی به‌اندازه کدی که فرمت نشده منو دیونه نمی‌کنه ? قبل از شروع این فاز، فرمت شدن کدهامون توسط PyCharm هندل می‌شد. (بله درسته از VSCode استفاده نمی‌کردیم)
وای اونایی که با Prettier کار کرده‌اند، نحوه فرمت شدن کد توسط PyCharm ببینن روانی می‌شین قول میدم.
اگر شمام توی شرکتی کار می‌کنید احتمالا یک سری قوانین کدنویسی داشته باشید. از کجا چیو import کنم، از const let یا var کجا استفاده کنم، فاصله بین توابع و هزار کوفت دیگه.
اون موقع ما این‌هارو نداشتیم و هرکی هرکاری که دلش می‌خواست انجام می‌داد. تا اینکه تصمیم گرفتیم ESLint رو به پروژه اضافه کنیم. حالا تصور کنید که یک پروژه‌ای که تابحال هیچ قانونی نداشته یهو قانون‌گذاری سنگین اتفاق بی‌افته.
همزمان با این کار یک ابزاری برای مطمئن شدن از رعایت قوانین قبل از commit کردن خود استفاده کردیم. همه‌گی دعا می‌کردیم که نیازی نباشه درگیر فیچری بشیم که با React زده شده، چون مجبور بودیم به‌دلیل یک تغییر ساده، کل ایرادهای ESLint رو اصلاح کنیم ?
این کار خیلی اذیت‌کننده بود. اما به مرور باعث جلوگیری از باگ‌های متفاوتی می‌شد. حداقل به‌شخصه تجربه‌ام مثبت بوده و حتی بخاطر ارورهای که می‌داد مجبور می‌شدم درمورد یه سری مباحث مطالعه کنم و موارد جدیدی یادبگیرم. (در CRA بصورت پیش‌فرض این ابزارها فعال هستند)
اگه از من بپرسند بزرگترین چالشی که در فرانت‌اند کوئرا داشتید چی بوده، بدون یه ذره شک می‌گفتم Webpack. (شریک‌های جرم شامل Babel و ts-loader می‌شود)
قصد ندارم بحثو تخصصی کنم.
پس فرض کنید شما درحال نوشتن یک وب‌سایت هستید و با هر تغییری که انجام می‌دهید، ۱۰ ثانیه (نسبت به سرعت سیستم شما ممکن است بیشتر هم شود) طول می‌کشد که تغییرات خود را ببینید تازه اگر سوتی داده باشید بالاخره بازم ۱۰ ثانیه طول می‌کشد که آن تغییرات را مشاهده کنید. همچنین زمان بالا اومدن برنامه شاید یک دقیقه باشد که ممکن است حس کنید یک دقیقه که چیزی نیست، ولی تا امتحان نکنید نمی‌فهمید. قول میدم.
اگر برنامه‌نویس جونیوری مثل من باشید ممکن است این مورد خیلی شما را کند کند (کند کند کند کند ??)
خیلی تلاش کردیم که اینو رفع کنیم.
یه تسک تحقیقاتی درمورد Parcel آوردم ولی درنهایت حس کردم که نمی‌تونه تاثیر خاصی داشته باشد.
بعد مدتی یه تسک تحقیقاتی برای SWC آوردم که ببینم می‌شه ازش استفاده کرد یا نه ولی بخاطر یک سری محدودیت موفق نشدم.
رفتم سراغ ESBuild ولی اونم موفق نشد. تا اینکه بهترین جمعه‌ی فرانتیم رسید. تو خونه بودیم محمد گفت که عبداله این Vite رو دیدی؟ منم گفتم اره یارو سازنده‌ی Vue خیلی حرفش می‌زنه ولی زیاد توجه نکرده بودم بهش.
خلاصه سایتشو باز کردم و یه نیم ساعتی داخلش چرخیدم و بلع. هرچی نیاز دارم رو داشت. به به بالاخره قراره نگران کندی نباشم و قراره عشق و حال کنم. ?
یک ابزاری که خیلی خوب دوتا باندلر ESBuild و Rollup هندل می‌کند اونم با HMR (بدون رفرش، جنگی و سریع تغییرات خود را ببینید)
دیگه نتونستم منتظر شنبه بمونم برم سرکار اونجا ردیفش کنم. همون جمعه یک سره از ۲ ظهری تا ۳ شب نشستم و جمعش کردم و به به. (این لابه‌لاها مجبور بودم یه سری چیزا رو deprecated کنم، بخاطر همین طول کشید وگرنه خودش فکر کنم یه ۶ ساعت وقت گرفت (بدلایل محدودیت‌های خاصی که داشتیم مجبور بودم کارهای اضافه‌ای بکنم))
بعد ریفکتور و اضافه کردن Vite، بالاخره بالا اومد اما تغییر خاصی حس نکردم، سرعت بیلد گرفتن از چندین دقیقه به ۲۰ ثانیه رسید ولی سرعت مشاهده تغییرات، از ۱۰ ثانیه به ۱۰ ثانیه رسید :)))))))) شکست عشقی سنگین خوردم بالاخره بیلد گرفتن اوکیه ولی اصل مشکل رفع نشد. تسلیم نشدم ادامه دادم و بالاخره با کلی تلاش HMR رو راه انداختم و بالاخره ۲ شب سرعت مشاهده تغییرات از ۱۰ ثانیه به ۱ ثانیه رسید. به به جانمی جان. اون لحظه همه خواب بودن و از هیجان داشتم می‌لرزیدم، منتظر روز بعد بودم سریع برسه برم به تیم بگم که اره بالاخره بزرگترین مشکل فرانت Reactمون رفع شده و قراره درست حسابی حال کنیم.
درکنار تمامی اینا به موفقیت‌های دیگه‌ای رسیدیم مثل حجم باندلمون به اندازه‌ی خوبی پایین اومد (با پیاده‌سازی استراتژی خوب برای chunk splitting)
و اینم از این
در نهایت اینم بگم کارهای متفاوتی مثل اضافه کردن React Query، Redux Toolkit و کارهای که فعلا یادم نیست کرده‌ایم ولی خب جا نمی‌شد.
به‌شخصی تجربه‌ی خیلی جذابی در این مسیر داشتم، لذتی که تو حل اینجوری مشکلات هست، تو حل هیچ مشکلی نیست بنظرم. اینکه ببینی هم‌تیمی‌هات بدون اذیت شدن بتونن محصول رو توسعه بدن و کد بزنن، اصلا اوف.
پ.ن۱: سعی کردم مباحث فنی رو باز نکنم و وارد جزئیات نشم پس اگر سوالی داشتید حتما بپرسید و اگر تونستم جواب بدم حتما اینکارو می‌کنم.
پ.ن۲: از همین تربیون به همه‌ی بچه‌های تیم فنی کالج مصطفی، محمد، پیمان، حامد و همه‌ی بچه‌های تلنت مرسی می‌گم.
پ.ن۳: احتمالا دقت کرده باشید که اول خیلی خام بودم و به مرور تجربه‌های بیشتری کسب کرده‌ام که باعث شدند به نتیجه‌های خوبی برسم. پس اگر شما تابحال تجربه‌ی کاری نداشتید، بدونید که همه اشتباه می‌کنند و همه‌ی ما یه روزی تنها چاپ کردن Hello World! بلد بودیم. مهم اینه که از این اشتباهات یادبگیریم و پیشرفت کنیم.
این نوشته توسط من عبداله کشتکار یک توسعه‌دهنده فول‌استک در کوئرا نوشته‌شده است و امیدوارم که خوشتون اومده باشه.
