در بخش اول زیرساخت‌ها و کامپوننت‌های ساخته شده در بیت را به همراه مثال‌هایی بررسی کردیم. در ادامه قصد داریم به جزییات ساخت میکرو فرانت-اند بپردازیم. پس تا انتهای مقاله با ما همراه باشید.
روند کلی
قانون Conways می‌گوید که بین معماری نرم‌افزار و ساختار سازمانی همبستگی قوی وجود دارد. این امر در هنگام ساختن کامپوننت‌ها بسیار صادق است، زیرا هدف اصلی این است که روند توسعه را کارآمدتر کنیم. جدا کردن پایگاه‌های کد و امکان ادغام یا تقسیم خط لوله انتشار، همه اینها راه‌هایی برای ایجاد نرم‌افزار بهتر و همچنین تیم‌های مستقل حرفه‌ای‌تر هستند.
تیم‌های خودمختار
یک تیم کوچک که قدرت تصمیم‌گیری دارد و بی وقفه به سمت اهداف خود حرکت می‌کند، نتایج را بسیار سریعتر از یک گروه بزرگ بدون هماهنگی ارائه می‌دهد. به هر حال چه کسی کاربران و مشکلات محصول را بهتر از تیم توسعه آن می‌شناسد؟
به لطف انعطاف پذیری معماری کامپوننت محور، آنها توانستند مالکیت تیم و روش بسیار پویاتر و مرتبط با کارشان را تعیین کنند. به جای داشتن یک تیم فرانت-اند برای Bit.dev و یک تیم بازاریابی وب سایت که روی یک برنامه یکپارچه کار کنند، آنها تیم‌ها را از هر نظر کاملا جدا کردند.
برای شروع، تعدادی از توسعه‌دهندگان "تیم زیرساخت اصلی" محسوب می‌شوند که مجموعه اصلی کامپوننت‌های پلتفرم Bit.dev را حفظ می‌کنند. در این تیم یک طراح، یک مدیر محصول و چند عضو دیگر حضور دارند. آنها ویژگی‌های خود را مستقل از سایر تیم‌هایی که از آنها استفاده کرده، ایجاد، منتشر و به روز می‌کنند.
تیم "جستجوی کامپوننت" مسئول ویژگی‌های جستجوی پیچیده در Bit.dev است که از چند توسعه‌دهنده (فرانت-اند و بک-اند)، یک محقق NLP و یک مدیر محصول تشکیل شده است. آنها کامپوننت‌ها را در معرض دید سایر تیم‌ها قرار می‌دهند تا در محصولات خود ادغام کنند.
تیم "ساخت کامپوننت" شامل چند توسعه‌دهنده، طراح و مدیر محصول است تا مجموعه‌ای از کامپوننت‌های مورد استفاده برای مستندسازی و تعامل با کامپوننت‌های به اشتراک گذاشته شده در بستر Bit.dev را ایجاد کند. در حقیقت به لطف Bit، کامپوننت‌های مستندسازی یکسان هم در فضای کاری توسعه محلی و هم در پلتفرم ابری استفاده می‌شود که همه توسط این تیم ساخته شده است.
چند توسعه‌دهنده دیگر به تیم بازاریابی اختصاص داده شدند تا مجموعه کامپوننت‌های بازاریابی را به همراه چند بازاریاب و یک طراح بسازند که از اینها برای ایجاد وب سایت بازاریابی و همچنین چند برنامه دیگر استفاده می‌شود.
تیم دیگری به همراه توسعه‌دهندگان خاص خود، مجموعه‌ای از کامپوننت‌ها که تعاملات مختلف کاربر در پلتفرم Bit.dev و حتی در وب سایت‌ها و برنامه‌های کاربردی دیگر را شامل می‌شود، پیاده‌سازی و نگهداری می‌کند.
و این لیست همچنان ادامه دارد، تا اینکه هر ویژگی به تیمی مستقل برای ساخت و انتشار سپرده می‌شود تا با سایر تیم‌ها نیز ادغام شده و از آن استفاده کنند.
پایگاه‌های کد ساده و جدا شده
جدا کردن پایگاه‌های کد توسعه منجر به ساده‌تر شدن تست، نگهداری، جایگزینی و ارتقا ویژگی‌ها می‌شود. با این کار آنها می‌خواهند به طور مداوم قادر به افزودن فناوری‌ها و ویژگی‌های جدید باشند.
هر یک از تیم‌ها در یک پایگاه کد کاملا متفاوت و جدا کار می‌کند. کد منبع برای هر ویژگی یا محصول به طور طبیعی بسیار کوچکتر و ساده‌تر از کل برنامه است که باعث می‌شود هر پایگاه داده بسیار ساده‌تر توسعه داده، تست و نگهداری شود، بدون محدودیت و دردسرهای اضافی.
اگر به "base-ui" و "evangelist" در صفحه اصلی Bit.dev نگاهی بیاندازید، متوجه خواهید شد که هر مجموعه‌ای از کامپوننت‌ها در یک پایگاه کد متفاوت توسعه یافته است. هر دو مجموعه از یکدیگر جدا شده و برای ایجاد صفحات، ویژگی‌ها و برنامه‌های مختلف با هم ادغام شده‌اند.
از آنجایی که همه پایگاه‌های کد از یکدیگر جدا شده‌اند، بازسازی قطعات برنامه‌های کاربردی نیز بسیار آسان تر می‌شود، به طوری که آنها می‌توانند به سرعت و با خیال راحت فناوری‌ها را اضافه یا جایگزین کنند.
با گذشت زمان نیاز به وضوح و شفافیت کد در هر پایگاه کد، راهی عالی برای درک بهتر معماری است.
خط لوله انتشار مستقل
آنها می‌توانند خط لوله انتشار تیم‌های مختلف را از یکدیگر جدا کنند، به طوری که هر تیم بتواند به طور مستقل تغییراتی را در چندین برنامه ایجاد و منتشر کند، بدون اینکه منتظر بمانند تا نسخه‌ها اعمال شوند یا روی انشعاب‌های اصلی قرار گیرند.
همانطور که در بالا ذکر شد، از طریق Bit می‌توان یک خط لوله ساخت سفارشی و در عین حال استاندارد برای مجموعه کامپوننت‌های هر تیم اختصاص داد. بنابراین با وجود اینکه جداگانه ساخته شده‌اند، همه کامپوننت‌ها می‌توانند وظایف و ابزارهای یکسانی را پشت سر بگذارند.
سپس فرآیند CI کامپوننت محور در Bit.dev، تغییرات نمودار وابستگی همه کامپوننت‌ها در هر صفحه و هر برنامه را نگاشت و بررسی می‌کند.
به زبان ساده هر تیمی می‌تواند تغییری در هر کامپوننتی ایجاد کند، به طور مستقل این تغییرات را اعمال کرده و بداند که چگونه کامپوننت‌ها و تیم‌های دیگر را در همه برنامه‌های کاربردی مرتبط مشارکت دهد.
اگر همه چیز خوب پیش رود، تغییرات به طور خودکار به درخواست Pull تبدیل شده و سپس به همه پروژه‌های مربوطه ارسال می‌گردد تا صاحبان آنها بتوانند کامپوننت‌های خود را به روز کنند. آنها حتی نوتیفیکیشن‌ها و یادآوری‌ها را از طریق Slack دریافت می‌کنند.
بنابراین به جای درگیر کردن برنامه‌های دست و پا گیر و یافتن راه حل‌های جایگزین، آنها بر ادغام زمان ساخت تکیه کرده و فرآیندهای انتشار را با هم ترکیب نمی‌کنند. در حال حاضر این ویژگی به طرز شگفت انگیزی خوب کار می‌کند و CI کامپوننت محور هم ظرف چند هفته از نسخه بتا خارج می‌شود، بدین ترتیب هنگام بیرون آمدن از حالت آزمایشی می‌توانید آن را رایگان امتحان کنید. در آینده هم برنامه‌ای دارند که بتوانند استقرار کامپوننت محور را در برنامه‌ها فعال کنند.
ارتقاء بیشتر
اکنون که پایگاه‌های کد از هم جدا شده و با کامپوننت‌های ماژولار به صورت مستقل نسخه بندی می‌شوند، آنها توانایی بسیار زیادی برای افزودن، جایگزینی، رفع اشکال یا حتی بازگرداندن یک کامپوننت یا ویژگی واحد را به دست آورده‌اند.
بر این اساس تیم‌ها می‌توانند تصمیمات بهتری را اتخاذ کنند و به سرعت آنها را تغییر داده و ارتقاء ویژگی‌ها را ارائه دهند. همچنین با ریفکتورینگ به عنوان یک فرایند مداوم تدریجی که می‌تواند به صورت تک تک انجام شود، رفتار کنند. به علاوه کل نرم‌افزار آنها انعطاف پذیرتر می‌شود، چرا که تقریبا غیرممکن است توسعه‌دهندگان چیزهایی را خارج از محدوده کامپوننت‌های خود خراب کنند.
یکی از مواردی که می‌توان از آن لذت برد، توانایی پاسخ سریع به درخواست‌های کاربر است. به عنوان مثال وقتی توسعه‌دهنده درخواست یک محیط ساخت کامپوننت جدید را می‌دهد که از نسخه Stencil خاصی پشتیبانی می‌کند، می‌توان آن را به جای چند هفته در چند ساعت ایجاد و اضافه کرد. از آنجا که بخش اعظم Bit اُپِن سورس است، بنابراین می‌توان به راحتی افراد را قادر ساخت که هر قسمت از مجموعه ابزار خود را به تنهایی گسترش دهد یا جایگزین کند. این در نهایت باعث کارآمدتر شدن کل تیم می‌شود.
استفاده مجدد از کامپوننت‌ها
آنها همه کامپوننت‌های خود را در Bit.dev منتشر می‌کنند. در آنجا همه تیم‌ها به طور موثرتری کامپوننت‌ها را با یکدیگر به اشتراک گذاشته، پیدا کرده، و از آنها مجددا استفاده می‌کنند.
ویژگی‌های اضافه شده مانند مستندات کامپوننت‌ها، جستجوی هوشمند و حتی شبیه سازی‌های زنده همه به یافتن کامپوننت‌ها کمک زیادی کرده تا دیگر مجبور نباشیم از وب سایت‌ها، رجیسترها یا ابزارهای مستندسازی مختلف استفاده کنیم.
این سیستم اشتراک گذاری کد، پیشنهاد بازخورد و اطمینان از سازگاری را برای توسعه‌دهندگان آسان می‌کند. به ویژه آنها از این ویژگی بهره می‌برند، چون به توسعه‌دهندگان جدیدی که به تیم ملحق می‌شوند کمک کرده تا منحنی یادگیری خود را کاهش دهند؛ زیرا می‌توانند کامپوننت‌های موجود را پیدا کرده و شروع به استفاده از آنها کنند تا بتوانند به سرعت پیش رفته و شروع به ساخت نمایند.
همچنین این یک راه مفید برای آنها به منظور بهبود همکاری بین توسعه‌دهندگان و سایر ذینفعان مانند طراحان و محصول است که اکنون می‌توانند همه کامپوننت‌ها را ببینند.
جمع‌بندی
برخی می‌گویند میکرو فرانت-اند مدل خوبی برای کامپوننت‌ها نیست. اما در Bit این یک مدل مناسب است به همان اندازه که یک راه حل بهتر برای ایجاد تیم‌های منسجم، بهبود شیوه کار، ساختن نرم‌افزارهای ماژولار و ارائه سریعتر تلقی می‌شود.
در سازمان‌های بزرگتر، ایجاد تیم مستقل یک تغییر واقعی در توانایی آنها به منظور ساخت و ارسال برنامه‌های کاربردی وب است. همچنین توانایی استانداردسازی توسعه کامپوننت‌ها و به اشتراک گذاشتن و همکاری با یکدیگر نیز در تیم‌ها وجود دارد.
در تیم‌های کوچکتر نیز اتخاذ معماری انعطاف پذیر و مقیاس پذیر، توانایی آنها را برای رشد، افزودن سریع ویژگی‌های جدید، حضور افراد جدید و تمرکز بر فناوری اصلی و نوآوری به جای موارد کم اهمیت را افزایش می‌دهد.
دیدگاه و پرسش
در حال دریافت نظرات از سرور، لطفا منتظر بمانید
در حال دریافت نظرات از سرور، لطفا منتظر بمانید