فارغالتحصیل دانشگاه امیرکبیر | برنامهنویس فرانت کافهبازار/بلد
چطور باگ‌هامون رو همه‌جا گسترش دادیم | YektaUI از بدعت تا توسعه
احتمالا اگه اندکی با یکتانت آشنا باشین میدونید که دولوپرهای سمت فرانت‌اند بیشتر وقتشون رو به توسعه پنل‌ها می پردازن. سال پیش یکی از همین روزا بود که فهمیدیم چقدر کد مشابه داریم که تو پنل‌های مختلف استفاده میکنیم. نمونه‌اش کامپوننت پشتیبانی(Ticketing)مون بود که برای هر پنل از یک کد مشابه استفاده می‌شد اما هر باگ فیکس یا افزودن فیچری بهش مستلزم این بود که به تک‌تک پنل‌ها سر زده بشه یا اطلاع‌رسانی کنیم که تو هر پنل این قسمت‌ها رو آپدیت کنید! خب این روش درست نبود. شاید دلمون میخواست هر فیچری که میزدیم رو یکبار بزنیم و بقیه جاها هم آپدیت بشن. یا اصلا دلمون میخواست و شوق این رو داشتیم که باگ‌هامون رو زودتر تو همه پلتفرم‌ها توسعه دهیم. چرا باید این فرآیند دیپلوی کردن یه باگ انقدر طول بکشه؟!
کد تکراری، منشأ همه شرارت‌ها
یک اصل در معماری نرم‌افزاری هست به اسم Don't Repeat Yourself) DRY) . با این مفهوم که کد تکراری منشاء همه‌ی شرارت‌هاست. این شد که جرقه یک کیت فرانت شکل گرفت تا از ایجاد چنین کدهایی جلوگیری کنه و به افزایش کیفیت کدها هم منجر بشه. ما اسمش رو گذاشتیم YektaUI. سعی میکنم در متن زیر به دلایل ایجاد این کیت فرانت که توسعهاش تا الان توسط تمام بچه‌های فرانت‌اند یکتانت انجام شده اشاره کنم، درمورد خصوصیاتش توضیح بدم و نحوه‌ی توسعهاش رو شرح بدم.
داستان یکتانت و پلتفرم‌ها
مجموعه یکتانت تا حدود یک سال قبل، شامل پنل‌های یکتانت و نجوا می‌شد. اما یکتانت فقط به همین موارد ختم نشد. از سال پیش تاکنون پنل پلتفرم‌های تریبون و جریان هم توسط یکتانت لانچ شد.تعداد پنل‌ها تا این لحظه تقریبا به هفت پنل میرسه. تمامی این پلتفرم‌ها نیاز به زیرساختی داشتند تا سرویس‌هایی مثل احراز هویت(Authentication)، پشتیبانی(تیکتینگ) و موارد مالی رو پوشش بدن. از این جهت، زیرساخت موارد ذکر شده، در یک سال اخیر ایجاد شد و تمامی پلتفرم‌ها تونستند از این زیرساخت‌ها استفاده کنند.
استک و کتابخانه‌های مورد استفاده در تمامی پنل‌ها در حال حاضر موارد زیر است:
- SCSS
- Bootstrap 4
- BootstrapVue
- Nuxt
- Vue
اما آیا لازم بود که هر پلتفرم، فارغ از پلتفرم‌های دیگر نیازمندی‌های خودش رو پیاده‌سازی کنه؟ این مسئله باعث میشه تا وقت زیادی از توسعه‌دهندگان، صرف کدهایی بشه که قبلا توسط اعضای دیگه یکتانت زده شده. ما دنبال توسعه سریعتر و باکیفیت‌تر بودیم. این جرقه‌ی شروع کیت بود. اما چون شروع این کار ممکن بود وقت زیادی از افراد رو بگیره باید با دلایل محکم‌تری به سمتش می رفتیم.
ادله کافی جهت ایجاد و توسعه
احتمالا بهترین جواب‌ها، از بهترین سوالات شروع به شکل‌گیری می‌کنند. سوال‌های ما چی بود که نتیجه‌اش شد ایجاد یک کیت فرانت اند؟ میتونم بگم این‌ها بودند:
- کامپوننت‌های مشترک را چطور استفاده کنیم/توسعه بدهیم؟
- توابع و utilityهای پراستفاده، از کجا قابل دسترسی باشند؟
- استایل کدهامون رو چگونه و بر چه اساس یکی کنیم؟ آیا امکان دارد همه این استایل را رعایت کنند؟
- چطور از دانش افراد مختلف به طور عملی استفاده کنیم؟
- چطور میتونیم از طریق توسعه با کمک یکدیگر، کیفیت توسعه را افزایش دهیم؟
- با توجه به گسترش تیم‌ها و زیاد شدن محصولات، ابزارهای داخلی را به چه صورت منتشر کنیم؟
احتمالا جواب این سوالات رو میتوانستیم با توسعه YektaUI پیدا کنیم. باتوجه به موارد ذکر شده و با استناد به این مفهوم که زودتر کد رو بزنیم تا اینکه بیشتر از حد راجع به مسئله فکر کنیم، توسعه رو شروع کردیم. این توسعه چه چیزهایی رو شامل می‌شد؟
۱.کامپوننت‌ها
دریا دریا کامپوننت. همه‌اش برای خودمون. در همه‌ی پنل‌ها به اندازه کافی کامپوننت‌های مشترک داشتیم که هرکدوم فیچر‌های خاص خودشون رو داشتند و لازم بود تا این موارد در کنار یکدیگر قرار بگیرند و پازل بزرگ ما رو شکل بدن.
مهمترین کامپوننت‌ها را میتونیم به کامپوننت‌های فرم(form) تخصیص بدیم. صحبت در مورد توسعه این کامپوننت‌ها، خودش چندین سلسله مطلب رو میطلبه، اما از جهت بیان کلی نیازمندی‌هامون، میتونم موارد زیر رو اشاره کنم:
- در فرم‌ها labelها به چه صورت نمایش داده شوند
- خطای هر input و هر form را به چه صورت نمایش دهیم
- صحت و validation محتوای inputها را چطور اعتبار‌سنجی کنیم
- چهارچوب و layout فرم به چه نحوی باشد تا کاربر با آن ارتباط بیشتری برقرار کند
تعدادی از موارد بالا توسط متخصص UX انجام میشه اما باتوجه به اینکه این پوزیشن در حال حاضر در یکتانت تعریف نشده، قسمتی از فعالیت دولوپر فرانت‌اند و مدیر محصول به تعیین چنین تصمیماتی تخصیص پیدا میکنه.
سوالات بالا، سوالات خیلی خوبی بودند. اما جواب‌ها مدت زمانی حدود دو ماه را از ما گرفت تا بتونیم تعداد زیادی مقاله بخونیم و کتابخونه‌های مختلف رو بررسی کنیم تا پاسخ کاملی براش پیدا کنیم; ولی نتیجه لذتبخش بود.
سری بعدی کامپوننت‌های پر استفاده برای ما، جدول‌ها(table) بودند. چندین نوع جدول مختلف در پروژه‌ها داشتیم با چندین فیچر مختص هرکدام(هنوز هم داریم. این قسمت هنوز درست نشده :دی) که هر فردی که از یه پروژه به پروژه دیگری منتقل می‌شد نیاز داشت تا با جدول‌های پروژه جدید آشنا بشه ( همونطور که گفتم هنوزم باید یاد بگیره :) ). تعداد زیادی کامپوننت تیکتینگ داشتیم که مشتری‌ها از طریق این قسمت‌ها میتونستند سوالاتشان رو مطرح کنند و از ما پاسخ دریافت کنند و این کامپوننت‌ها نیز بسته به پروژه، پیاده‌سازی متفاوتی داشتند ( این یکی مورد درست شده!). یک جلسه کامل از جلسات فرانت چپتر(در مورد فرانت چپتر‌مون از اینجا بخونید) رو به این اختصاص دادیم که بتونیم کامپوننت‌های مشترک رو شناسایی کنیم و نسخه کامل رو به YektaUI اضافه کنیم.
از طرفی استایل‌ها و ظاهر تمامی پنل‌ها منحصر به فرد ه. پس یکی از چالش‌های تیم فرانت این بود که کامپوننت‌هایی رو ایجاد کنن که قابلیت کاستوم شدن رو داشته باشند و بتونند با تمامی پنل‌ها هماهنگ باشند. تم بوت‌استرپ (Bootstrap Theming) و استایل‌های scss آن، از جهت به کارگیری تنظیمات مختلف css ای در هر پنل، راه‌حل ما جهت شخصی‌سازی هرکدوم از پنل‌ها بود. رنگ‌بندی‌ها، سایزبندی‌ها و موارد مشابه را از طریق override کردن تم‌های اصلی به صورت پویا در هر پنل تغییر دادیم.
۲.توابع مشترک و utilityها
تبدیل اعداد به حروف، نمایش اعدادی که نشان دهنده مبلغ هستند به صورت ویرگول‌گذاری شده. ارسال ریکوئست‌ها با درنظرگرفتن احزار هویت میانی مانند JWT و … مواردی بود که تقریبا در تمامی پنل‌ها از اون‌ها استفاده می‌شد. سعی کردیم این موارد رو نیز تا حد امکان به YektaUI اضافه کنیم.
با این روند، به جای صرف وقت جهت پیاده‌سازی‌های متعدد، باعث شد تا وقت مورد نظر رو جهت بهینه کردن کارایی استفاده کنیم و یا برحسب نیاز تنها به افزودن فیچرهایی که موجود نیست بپردازیم.
۳.کد استایل
Every major open-source project has its own style guide: a set of conventions (sometimes arbitrary) about how to write code for that project. It is much easier to understand a large codebase when all the code in it is in a consistent style. -Google Style Guides
با توجه به پویایی سازمان، و اینکه برنامه‌نویسای یکتانت پس از حل چالش‌های مربوطه در قسمتی که در اون فعالیت دارند ممکن است برحسب نیاز شرکت یا تمایل خودشون، به توسعه پروژه‌های دیگه شرکت که در حال توسعه است یا قراره توسعهاش شروع بشه مشغول بشن، لازم داشتیم تا یک استایل کد زدن یکسان و مناسب داشته باشیم و همچنین به این کد استایل وفادار بمونیم تا هنگام این جابه‌جایی، با مشکل و فوت وقت مواجه نشویم. در واقع عدم وجود این استایل موارد زیر رو به دنبال داشت:
- پایین بودن سرعت خوانایی کد
- عدم رعایت ثبات (consistency) استایل در بین تیم‌های مختلف
- مشخص نبودن سطح خطای کد (error, warning یا خطایی که disabled شده است)
ابزارهایی که کمکمان می‌کردند تا به تمامی موارد بالا برسیم eslint و prettier بودند.
ابزار eslint جهت مدیریت قواعد در javascript استفاده میشه. نهادها و سازمان‌های مختلفی قواعد درنظرگرفته خود را جهت استفاده توسط eslint منتشر کرده اند که میتوانید این موارد را دراین لینک بیابید.
از جمله مزیت‌های eslint ایجاد قواعد و قوانین شخصی‌سازی شده یا custom است. در حین توسعه پروژه‌ها در سازمان نیاز داشتیم تا تعدادی قواعد شخصی‌سازی شده رو به این صورت به قوانین دیگه اضافه کنیم. نامگذاری کامپوننت‌ها و متغیرهای boolean از جمله مواردی است که نیاز به رعایت داشتند. این قواعد از ابتدای توسعه پروژه‌ها وجود نداشتند و با توجه به احساس نیاز و مطرح شدنش در یکی از جلسات چپتر فرانت تصمیم گرفتیم هرکدوم رو به قواعد مورد نیازمون اضافه کنیم و با مستندسازی این موارد در پلتفرم slite اون رو در بین تیم‌ها به اشتراک بذاریم.
استفاده از استایل یکسان، باعث شد تا بتونیم با صرف زمان کمتری جهت درک کد، به فهم نوآوری‌های استفاده شده در کدها بپردازیم و کیفیت به عنوان مسئله اصلی در کدها بجای دغدغه نحوه کد زدن در اولویت قرار بگیره.
مرج ریکوئست‌ها و روند تایید فیچر‌ها
این پروژه در حال حاضر بر روی بستر داخلی یکتانت قرار داره و به صورت open source درنیومده. روند ایجاد تغییرات در YektaUI به صورت زیر ه:
- ایجاد branch و توسعه feature یا برطرف کردن bug در branch مربوطه
- ایجاد درخواست merge request
- انجام review کد توسط دو نفر از افراد دیگر فرانت و بیان بازخورد
- رفع نواقص و اعمال بازخوردها
- مرج با کد اصلی و ایجاد ورژن جدید
مرحله‌ای که در توسعه فنی شخصی افراد تاثیر جدی‌ای داشته و کیفیت کدها را به مراتب چندین مرحله بهتر کرد، مرحله review کدها بود. در ابتدای این امر، این کار توسط تنها یکی از اعضای فنی(علی محمدی) صورت می‌‌گرفت. اما با توجه به توسعه گسترده این کیت، تصمیم بر این شد تا reviewها به افراد مختلف واگذار شود که تاثیر به سزایی در تعامل افراد با یکدیگر با این کار صورت گرفت.
دردم از یار است و درمان نیز هم
احتمالا در هر سودی ضرری هم نهفته است. کلیت مزیت‌ها و مضرت(!)هایی که در توسعه این پروژه دخیل بودند رو میتونیم به موارد زیر خلاصه کنیم:
مزیت‌ها
- اشتراک‌گذاری کدهای مشترک
- تعامل فنی بیشتر کارمندان با یکدیگر
- افزایش کیفیت و کارایی خروجی
- تسریع در تغییرات مشترک بین پلتفرم‌های سازمان
مضرت‌ها
- نیاز به سپری شدن سلسله مراتبی از توسعه، جهت ایجاد و تایید تغییرات
- نیازمند صرف زمان جهت هماهنگی و ایجاد قواعد و مدیریت پروژه
- نیازمند صرف زمان جهت انتقال تمامی کامپوننت‌های پنل‌ها
- سرعت کم در تغییرات به دلیل عدم وجود تست‌ها برای کامپوننت‌ها
در رابطه با سپری شدن سلسله مراتب مورد نیاز جهت ایجاد تغییر در کدها، با وجود اینکه ممکن است از سرعت توسعه در وهله اول کم بکنه، اما همین سلسله مراتب منجر به افزایش کیفیت کدها میشه. خالی از لطف نیست که بیان کنیم با گذشت زمان، سرعت انجام شدن این سلسله مراتب نیز افزایش یافته و انتظار می‌رود با صرف زمان‌های بیشتری در گسترش پروژه، زمان سپری شده توسط این سلسله مراتب نیز کاهش پیدا کنه.
با توجه به اینکه یکتانت در حال رشد ه و برنامه‌های بیشتری جهت توسعه قسمت‌های مختلف پیش رو داره، زمانی که جهت هماهنگی و ایجاد قواعد این پروژه صرف میشه تنها مختص مراحل اولیه است و با تخصیص این وقت اولیه، در ادامه سهولت بیشتری رو ایجاد میکنه.
کیت YektaUI اولین ابزاری هست که دولوپرها برای راحتی کار خودشان در یکتانت توسعه دادن و همین مورد development experience را برای دولوپرهای فرانت‌اند بالاتر برده و بعد از اون می‌تونند با دغدغه کمتری بر روی محصول یا مساله‌ی خاص خودشون وقت بذارند.
با توجه به اهمیتی که در توسعه این پروژه ایجاد شد، قرار بر این شد تا افراد حاضر در یکتانت با عنوان front-end بتوانند ۲۰ درصد از زمان کاری خود را جهت توسعه این کار اختصاص بدن.
در حال حاضر YektaUI در چه وضعیتی قرار دارد؟
تا این لحظه که این مطلب در حال نوشته شدن است (اواسط مرداد ۹۹) YektaUI در حال توسعه داخلی در شرکت یکتانت است و تقریبا در تمامی پنل‌ها استفاده میشه.
رهی به سوی مقصد عالی - آینده YektaUI
مسیری که در جهت توسعه این کیت شروع شده احتمالا مسیر طولانی و جذابی خواهد بود. هدف نهایی ما توسعه ابزارهایی با سطح کیفیت عالی برای جامعه‌ی Vue فارسی است. اما برنامه‌ای که در برنامه‌ریزی کوتاه مدت برای توسعه این قسمت خواهیم داشت شامل موارد زیر ه:
- اضافه کردن استوری بوک(Storybook) و مستندسازی کامپوننت‌ها توسط آن
- اضافه کردن تست توسط فریم ورک Jest
- اپن‌سورس کردن قسمت‌هایی که به تنهایی اختصاص به یکتانت نداشته باشند
یکتانت - پیش به سوی بینهایت و فراتر از آن
احتمالا باتوجه به مقاله با مقداری از چالش‌های سمت فرانت آشنا شده باشید اما تمرکز اصلی ما در تمامی پوزیشن‌ها، تعریف مسئله‌هایی است که در هنگام انجام تسک‌ها باهاشون برخورد میکنیم و سعی‌میکنیم به طور عمومی اون‌ها رو حل کنیم. انجام موارد با پیش‌فرض گفته شده، منجر به پیشرفت فرد و سازمان باهمدیگه میشه و به نظر خودم جذابیت رو برای هر دو طرف خواهد داشت. اگر علاقه‌مند بودی که در این حل مسئله‌ها با ما هم مسیر بشید میتونید از طریق موقعیت‌های شغلی یکتانت بیشتر از وضعیت‌های شغلی‌مون آگاه بشید.
مطلبی دیگر از این انتشارات
تحلیل ترافیک در میدان یکتانت
مطلبی دیگر از این انتشارات
کیفیت سرویس‌دهی؛ چگونه نجوا را بهبود دادیم؟
مطلبی دیگر از این انتشارات
آیینه‌ی اسکندر | مفاهیم پیشرفته درباره‌ی اِستکِ اِلَستیک