مقیاس پذیر ساختن توسعه موبایل | راهنمای کاربردی

مدت چندانی از زمانی که تعداد کاربران اپلیکیشن‌های موبایل از تعداد کاربران وب بیشتر شد، نگذشته است. اکنون بسیاری از شرکت‌های وب این واقعیت را درک کرده‌اند و شروع به پشتیبانی از اپلیکیشن‌ها نموده‌اند. اما سؤال مهم این است که بهترین تدبیر برای مقیاس پذیر ساختن توسعه موبایل چیست؟

بک‌اندهای خاص برای کلاینت موبایل

به طور سنتی بسیاری از شرکت‌ها کار خود را به عنوان شرکت‌های طراحی وب آغاز کرده‌اند. این شرکت‌ها کسب‌وکارشان را رشد داده‌اند و گروهی از توسعه‌دهندگان برای کارهای فرانت‌اند و بک‌اند استخدام کرده و آموزش داده‌اند.

فیلم آموزش زامارین و MAUI برای اندروید و iOS – مقدماتی در فرادرس

کلیک کنید

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

چنان که می‌دانیم حوزه موبایل از وب متفاوت است و از این رو به طراحی و منطق متفاوتی نسبت به وب نیاز دارد. برای ایجاد این تفاوت، کلاینت موبایل باید منطق زیادی را پیاده‌سازی کند تا payload را پیش از استفاده از سرویس بک‌اند وب تبدیل کند.

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

بک‌اند برای فرانت‌اند (BFF)

چنان که در بخش قبل توضیح دادیم، رفته‌رفته توسعه اپلیکیشن‌ها اهمیتی حیاتی یافته است و باید سرویس‌های خاص بک‌اند وب را صرفاً برای کلاینت‌های موبایل‌ بسازیم.

این مدل چند مزیت به شرح زیر دارد:

1. ما می‌توانیم از توسعه‌دهندگان ماهر کنونی در حوزه بک‌اند وب برای کار روی بک‌اند موبایل استفاده کنیم.
2. می‌توانیم مقداری از منطق و تصمیم‌های مورد نیاز در سمت کلاینت موبایل را به بک‌اند موبایل انتقال دهیم و کار لازم در سمت کلاینت موبایل را کاهش دهیم.
3. در صورتی که کلاینت موبایل به طرز دقیقی تقسیم‌بندی و ساخته شده باشد، می‌توانیم تغییرهای بخش کلاینت موبایل از طریق بک‌اند تأمین کنیم و دیگر نیازی به انتشار نسخه جدید وجود نخواهد داشت.

این مدل به نام «بک‌اند برای فرانت‌اند» (back end for front end) یا به اختصار BFF نامیده می‌شود.

قرار داد بین بک‌اند و کلاینت

روش دیگر برای تسریع توسعه این است که قرار داد مشترکی بین سرور و کلاینت داشته باشیم. در اغلب موارد در این زمینه از JSON استفاده می‌شود. با این حال JSON به عنوان یک رشته قابل سریال‌سازی باید در مدلی قرار گیرد که هم کلاینت و هم سرور آن را به صورت مستقل از هم پیاده‌سازی کنند.

برای کاهش سربار باید از یک مولد مدل مشترک مانند «آپاچی ثریفت» (Apache Thrift)، ‌«بافرهای پروتکل» (Protocol Buffers) و غیره استفاده کنیم. مولدهای مدل به ما امکان می‌دهند که کدهای مدل را برای پلتفرم‌های مختلف مانند جاوا اسکریپت سمت سرور، جاوای اندروید یا سوئیفت اپل تولید کرده و آن‌ها را بین این پلتفرم‌‌ها به اشترک گذاشته و منتقل کنیم.

بدین ترتیب کارکردهای زیر در اختیار ما قرار می‌گیرند:

1. کاهش نیاز به تولید کدهای مدل مجزا برای پلتفرم‌های مختلف
2. کاهش ریسک خطای ناشی از تفاوت‌ها در تفسیر مدل
3. در صورتی که مدل با دقت تهیه شده باشد، می‌توان مستقیماً آن را روی نمای کلاینت نگاشت کرد و بدین ترتیب دیگر نیازی به ترجمه مدل به نمای کلاینت نیز وجود ندارد.

همه این موارد موجب می‌شوند که توسعه اپلیکیشن موبایل در بلندمدت بسیار مقیاس‌پذیر باشد.

توسعه اپلیکیشن ماژولار

با این که داشتن یک سرویس خاص کلاینت موبایل کمک زیادی به ما می‌کند، اما از طرف دیگر باید زمان زیادی را نیز صرف توسعه در سمت کلاینت موبایل بکنیم، ‌زیرا فیچر‌های بیشتری عرضه می‌شوند، UI بیشتر تغییر می‌یابد و مواردی از این دست زیاد می‌شوند.

به طور سنتی اپلیکیشن‌های موبایل تنها یک ماژول واحد دارند و هر کس روی آن کار کرده و مشارکت می‌کند. اما با اضافه شدن توسعه‌دهندگان بیشتر به تیم این مدل مقیاس‌پذیر نخواهد بود.

چنین مدلی موجب بروز مشکلات زیر می‌شود:

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

ماژوله‌سازی و تقسیم مسئولیت

توسعه اپلیکیشن‌ها هم برای اندروید و هم iOS می‌تواند ماژوله‌سازی شود. در ادامه یک روش رایج برای افراز مسئولیت عرضه شده است که اپلیکیشن را به سه لایه تقسیم می‌کند.

نکته: مدل زیر از پروپوزال اصلی گوگل برای اپلیکیشن‌های آنی (+) اخذ شده است.

• ماژول هماهنگ‌کننده
• ماژول‌های فیچر‌
• ماژول مبنا

نکته: اگر کنجکاو هستید که وابستگی‌ها در اندروید چگونه متصل می‌شوند، می‌توانید به این منبع (+) مراجعه کنید.

ماژول هماهنگ‌کننده

این ماژول یک هماهنگ‌کننده در سطح اپلیکیشن است. در این سطح، کار شامل هماهنگ‌سازی گردش منطق در سطح اپلیکیشن در میان قابلیت‌های مختلف است. این ماژول می‌تواند اینترفیس یا نمای (View)‌ خاص خود یعنی اکتیویتی، فرگمان، ویوکنترلر و غیره را نیز داشته باشد.

این گروه می‌تواند مسئول کار یکپارچه‌سازی پیوسته (CI) نیز باشد. این احتمال وجود دارد که ابزار کلی را بهبود بخشید، همه ماژول‌های دیگر را به همدیگر به صورت زنجیره‌ای گروه‌بندی کرد تا یک اپلیکیشن کامل ساخته شود و همچنین کل فرایند انتشار نیز به هم زنجیروار متصل شود.

اگر یک باگ یا مشکل وجود داشته باشد، این گروه ممکن است نخستین جایی باشد که بررسی می‌شود و به افراد ذی‌ربط جهت بررسی ارجاع داده می‌شود. این گروه می‌تواند مسئول بررسی سلامت کلی اپلیکیشن از طریق نظارت بر نرخ کرش، عملکرد و غیره باشد.

ماژول مبنا

این ماژولی است که همه الگوهای معماری سازگار مورد نیاز را برای رعایت از سوی هر گروه تعریف می‌کند. این ماژول شامل موارد زیر است:

• اینترفیس/پروتکل مرتبط برای گروه‌های فیچر (Feature) ‌جهت پیاده‌سازی و پیروی کردن. این ماژول می‌تواند یک ارجاع مبنا به آیتم مرتبط با طراحی مانند رنگ مشترک، نماها، متن و غیره داشته باشد.
• API مورد نیاز برای دسترسی به سیستم‌های مختلف یا الزامات در سطح اپلیکیشن روی همه فیچر‌ها مانند کلاینت شبکه، ریپازیتوری، آنالیتیک، احراز هویت و غیره قابل اعمال است.
• ابزارهای مشترک که هر گروه قابلیت نیاز خواهند داشت و استفاده می‌کنند شامل تابع‌های اکستنشن مختلف، کلاس‌های تست و غیره.
• اشتراک کتابخانه‌های خارجی مشترک که از سوی همه فیچر‌ها مورد استفاده قرار می‌گیرند.
• این گروه مسئول ارتباط و آموزش همه گروه‌های فیچر در رابطه با مواردی است که باید از سوی گروه رعایت و اتخاذ شوند.

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

ماژول‌های فیچر

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

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

داشتن چنین تنظیماتی به گروه‌ها امکان می‌دهد که در زمان کار روی ماژول‌ها انعطاف داشته باشند و همچنین مجموعه قواعد الگوهایی از ماژول مبنا استنتاج شود که باید مورد پیروی قرار گیرد. یک چنین انعطاف‌پذیری درون کران‌های تعریف شده، امکان مقیاس‌پذیری بهتری برای کار فراهم می‌سازد.

بدین ترتیب توسعه‌دهندگان می‌توانند روی ماژول‌های مختلف کار کنند. اما مالک ماژول باید تغییرهای صورت گرفته روی کد را مورد بازبینی قرار دهد. و اگر تغییرها روی ماژول مبنا صورت گرفته باشد، یک فرایند ارتباطی برای انتشار دانش در مورد چیزی که تغییر یافته و تأثیری که بر روی گروه‌های فیچر دیگر می‌گذارد مورد نیاز خواهد بود.

نکته: در زمان استفاده از ماژول‌های تقسیم شده ممکن است وسوسه شویم که آن‌ها را به کتابخانه‌هایی تبدیل کنیم که از ریپازیتوری‌های مختلف گیت‌هاب تولید می‌شوند. پیشنهاد ما این است که این کار انجام نشود، چون این کار موجب پیچیده شدن CI به دلیل کنترل نسخه‌بندی می‌شود. جمع کردن همه این موارد در یک ریپازیتوری گیت‌هاب که صرفاً بر مبنای ماژول افراز شده است به یکپارچگی بهتر و شناسایی سریع‌تر مشکلات و جهت‌گیری‌های نادرست کمک می‌کند.

ملاحظات دیگر

در این بخش برخی ملاحظات دیگر را که در زمان طراحی مقیاس‌پذیر اپلیکیشن‌های موبایلی باید رعایت شوند، مورد بررسی قرار می‌دهیم.

فیلم مجموعه آموزش توسعه اپلیکیشن موبایل – مقدماتی تا پیشرفته در فرادرس

کلیک کنید

از بهره‌برداری از مزیت‌های پلتفرم به خاطر حفظ انسجام بگذرید

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

با این حال، هر پلتفرم مزایا و چالش‌های خاص خود را دارد. اندروید دارای چالش مدیریت چرخه عمر و تزریق وابستگی است. ماژوله‌سازی iOS با توجه به وجود CocoaPods در قیاس با Gradle برای اندروید پیچیده‌تر است. زبان‌های برنامه‌نویسی این پلتفرم‌‌ها نیز متفاوت هستند. اندروید دارای کامپوننت معماری است، در حالی که iOS فاقد چنین چیزی است. iOS یک کتابخانه مهم به نام SwiftUI منتشر ساخته است، اما اندروید همچنان بر کدبیس مبتنی بر XML تکیه دارد.

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

محدودسازی توسعه چندپلتفرمی ژنریک

یادگیری برنامه‌نویسی چندپلتفرمی کار خوبی است. در واقع همواره خوب است که توسعه‌دهندگان اندروید در مورد ‌iOS و یا بر عکس مطالبی را بدانند.

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

در هر صورت باید تلاش کنیم افرادی داشته‌ باشیم که سطحی از دانش چندپلتفرمی را داشته باشند، از این رو برنامه‌ریزی معماری برای ملاحظات توسعه بهتر مدیریت می‌شود، چون این فرد می‌تواند به صورت یک پل در مباحث بین پلتفرم‌ها شرکت کند.

ساختار کد درون شرکتی

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

این وضعیت ممکن است مفید به نظر برسد، چون در این حالت می‌توانیم توسعه‌دهندگان وب را در زمینه توسعه موبایل به خدمت بگیریم. با این که از لحاظ نظری این ایده خوبی است، اما در عمل ناممکن است.

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

توسعه‌دهندگان فیچر ممکن است از کار لذت نبرند، چون مشغول یادگیری یک کد عمومی نیستند و از یک ابزار ساخته شده درون شرکتی استفاده می‌کنند. در بلندمدت این وضعت مناسبی نیست. بنابراین بهتر است کار را از مسیر دشوار آغاز کنیم و توسعه‌دهندگان وب را آموزش داده و منتقل کنیم تا فیچرها را به روش موبایلی بسازند و در بلندمدت می‌توانند مشارکت بیشتری در کار داشته باشند.

در حد امکان از کتابخانه‌ها و مجموعه ابزارهای متداول استفاده کنید

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

کتابخانه‌های بارگذاری تصاویر، کتابخانه‌های شبکه، فریمورک‌های DI، و فریمورک‌های برنامه‌نویسی واکنشی برخی نمونه‌هایی هستند که می‌توانیم ابزارهای متداول موجود را مورد استفاده قرار دهیم. این بدان معنی است که نباید از Dagger 2 در اندروید صرفاً به این خاطر که iOS این فریمورک را ندارد استفاده نکنیم، ‌مگر این که داگر 2 در بخش اندروید مزیتی برای ما نداشته باشد.

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

سخن پایانی

در این مقاله برخی ایده‌های سطح بالای ژنریک با برخی تجربیات کاربردی در مورد روش مقایس پذیر ساختن توسعه موبایل مطرح شد. امیدواریم این نکات مورد توجه شما قرار گرفته باشد.