ایران، ریموت
https://www.linkedin.com/posts/farideh-shahi_flutter-backend-remote-activity-7355861138015768577-EGUd?utm_source=share&utm_medium=member_android&rcm=ACoAADfwWIYBK4__5rZYtbMj7G52fXP2iT1WplU

یکی از دوستان در جواب من گفت آگهی استخدام فلاتر نمیبینه!
امرور من ۲ بار، هر بار فقط ۵ دقیقه لینکدین اسکرول کردم چندتا تا اگهی فلاتر دیدم , بعضیاشو براتون گذاشتم :)

چه خارجی چه ایرانی، مصاحبه برید و نترسید هرچی بشه یه چیزی از توش در میاد که یاد بگیرید 🌷
فردا مطلب فنی جدید میذارم براتون

از این به بعد یک سری سوالات تکنیکال میپرسم، که وادار بشید به مطالعه و بعدش در موردش صحبت میکنیم در کامنت ها

سوال اول:

فرض کن یه اپلیکیشن Flutter با Navigation پیچیده و چندین صفحه داری که بین‌شون state باید share بشه. چه راهکارهایی برای مدیریت این shared state پیشنهاد می‌کنی؟

تکمیلی :)
بسته به اینکه از چه ابزار state management و چه معماری استفاده کنیم، نحوه‌ی مدیریت shared state می‌تونه متفاوت باشه.

ولی یه الگوی کلی بین همه‌ی این ابزارها مشترکه: این‌که هر صفحه یک controller (Bloc، ViewModel، GetxController، یا ...) مخصوص خودش داشته باشه، و در کنار اون، یک یا چند controller مرکزی برای مدیریت state مشترک مثل تنظیمات، اطلاعات کاربر یا وضعیت سراسری اپلیکیشن تعریف بشه.

در واقع، این تفکیک بین local state و shared state، اساس چیزیه که بهش می‌گیم state management حالا با هر ابزاری که باشه

سلام،
چنل رو share کنید لطفا 😊🙏
اینطور منم بیشر انرژی میگیرم ازتون 🌷

سوال دوم:

فرض کنید در حال توسعه‌ی یه اپلیکیشن Flutter هستید که باید به صورت آفلاین هم کار کنه؛ یعنی کاربر بتونه بدون اینترنت داده وارد کنه و بعد که دوباره آنلاین شد، اطلاعات با سرور sync بشن.
چه راهکاری برای مدیریت این حالت آفلاین/آنلاین و همگام‌سازی داده‌ها پیشنهاد می‌کنید؟

و چه نقش‌هایی باید بین لایه‌های مختلف اپ (UI، domain، data) تقسیم بشن تا این قابلیت به‌درستی کار کنه؟

#همگام_سازی در فلاتر


اول از همه من یک معماری ساختاری انتخاب میکنم که برای چنین اپی قطعا Clean بهترین هست و البته آرکیتکچر پترنِ CQRS که اینم جدا توضیح میدم.

توی لایه UI فقط نمایش و تعامل داریم.
لایه‌ی Application کار مدیریت وضعیت و فراخوانی use caseها رو انجام می‌ده.

لایه‌ی Domain شامل منطق اصلی اپه، مثل عملیات ثبت، و همین‌طور موتور همگام‌سازی.

و در نهایت لایه Data که با دیتابیس لوکال و سرور در ارتباطه.

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

نکته‌ی مهم اینه که وقتی کاربر داده‌ای رو وارد می‌کنه، باید اون عملیات (مثل افزودن، ویرایش، یا حذف) به شکل یه "عملیات همگام‌سازی" ثبت بشه. یه چیزی شبیه به صف عملیات، که مثلا بگه: این یادداشت قراره ساخته بشه، این یکی ویرایش بشه، اون یکی حذف بشه... و همین‌طور(یه جواریی یه سری فلگ داریم)

هر کدوم از این عملیات یه state دارن: در حال انتظار، انجام شده، یا ناموفق. بعد یه چیزی به اسم Sync Engine
(اینو پیامای بعدی توضیح میدم) داریم که وقتی اینترنت وصل شد، میاد یکی‌یکی این عملیات‌ها رو اجرا می‌کنه و اونا رو با سرور هماهنگ می‌کنه.
اینجا باید حواسمون به چند تا چیز باشه:

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

لایه UI فقط داده رو نمایش می‌ده و وضعیت sync رو نشون می‌ده.
لایه Application عملیات رو مدیریت می‌کنه و موتور sync رو راه می‌اندازه.
لایه Domain منطق اصلی رو داره، مثل تعریف موجودیت‌ها، عملیات‌ها، و اینکه sync چجوری انجام بشه
لایه Data چ مسئول ارتباط با دیتابیس لوکال و API سروره.

علاوه بر اینا، باید سیستم رو طوری طراحی کنیم که تغییرات شبکه رو تشخیص بده؛ مثلاً وقتی دوباره آنلاین شدیم، عملیات sync خودکار شروع بشه. برای اینکار از پکیج‌هایی مثل connectivity_plus استفاده می‌کنیم.
اگه بخوام خلاصه کنم:
همیشه اول داده رو لوکال ذخیره کن، حتی وقتی آنلاینیم.
تغییرات رو توی یه صف نگه دار.
با یه موتور sync این صف رو مدیریت کن.

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

@sasansafari_dev1400

خب Sync Engine رِ بگیم

سینک انجین وظیفه داره تغییرات کاربر رو وقتی آفلاین بوده ذخیره کنیم و وقتی اینترنت وصل شد، این تغییرات رو به سرور بفرستیم. برای ذخیره لوکال معمولا از hive یا drift استفاده می‌کنیم. برای فهمیدن وضعیت اتصال اینترنت از connectivity_plus کمک می‌گیریم و برای ارسال داده به سرور هم http یا dio.
الگوریتم کار اینطوره که تغییرات تو یه صف ذخیره می‌کنیم و وقتی اینترنت وصل شد، یکی‌یکی به سرور ارسال می‌کنیم. اگه موفق بود، وضعیتشون رو آپدیت می‌کنیم و اگه نه، دوباره تلاش می‌کنیم. تو این روند برای کنترل اینکه هر عملیات کامل شده یا نه، معمولا از completer استفاده می‌کنیم که یه ابزار توی دارته برای مدیریت عملیات‌های async، یعنی باهاش می‌تونیم بفهمیم چه زمانی هر فرایند sync تموم شده یا خطا داده.
برای اجرای این فرایند حتی تو پس‌زمینه هم می‌تونیم از workmanager استفاده کنیم تا داده‌ها همیشه هماهنگ بمونن و چیزی از دست نره :)

@sasansafari_dev1400

و نهایتا الگوی معماری مهم CQRS که یعنی Command Query Responsibility Segregation

یعنی اینکه مسئولیت نوشتن یا تغییر داده‌ها (Command) رو از مسئولیت خوندن داده‌ها (Query) جدا کنیم. یعنی یه مدل و مسیر جدا برای نوشتن داریم و یه مدل و مسیر جدا برای خوندن. اینجوری کد مرتب‌تر، راحت‌تر قابل نگهداری و بهتر مقیاس‌پذیر می‌شه.
تو معماری کلین معمولا بخش Command رو تو لایه دامنه (Domain) می‌ذاریم که منطق تغییر داده‌ها و قوانین کسب‌وکار رو اجرا می‌کنه، ولی بخش Query رو می‌تونیم تو لایه دیتا یا حتی لایه UI مدیریت کنیم تا خواندن داده‌ها بهینه‌تر باشه. این تقسیم‌بندی کمک می‌کنه خواندن و نوشتن داده‌ها مستقل باشن و هر کدوم به بهترین شکل کنترل بشن

ببینید با یه سوال و طرح مسئله سر رشته چندتا کانسپت باز شد


کامپلتر در دارت و سینک انجین
معماری کلین
الگوی معماری CQRS
همگام سازی و.... 😁


اگر خوب انرژی بدین و این زحمات رو share کنید با دوستا و هم رشته هاتون قول میدم یه روز پشت میکروفن و کیبوردم بشینم و یک سلسله آموزش ویدیویی از این کانستپا بسازم، تکنیکال و پروژه محور 😊

با من مطالعه کنید😊

من هرشب یه مقاله میخونم
موافقید با Ai تجرمه‌ش کنم بذارم باهم بخونیم؟

در انتها اگه نظری بود هم گپ میزنیم تو کامنتا،
چند نفر خوره برنامه نویسی داریم اینجا ☺️

اگه موافقید 👍 بزنید

منبع: کلیک کنید

«تصویری‌سازی معماری نرم‌افزار: چرا اهمیت دارد و چگونه این کار را انجام می‌دهم» نوشته آلاستیر آلن را برایتان ارائه می‌دهم:

تصویری‌سازی معماری نرم‌افزار: چرا اهمیت دارد و چگونه این کار را انجام می‌دهم
نویسنده: آلاستیر آلن
تاریخ انتشار: ۲۳ مارس ۲۰۲۴

مقدمه
اولین آشنایی من با برنامه‌نویسی در دهه ۱۹۸۰ با زبان AmigaBASIC بود؛ زبان پیش‌فرضی که همراه با کامپیوتر Commodore Amiga ارائه می‌شد. در طول مدرسه و دانشگاه، زبان‌های دیگری مانند Modula-2 را یاد گرفتم و سپس در اولین شغلم با COBOL شروع کردم و به‌زودی با ColdFusion آشنا شدم. خوشبختانه، به‌زودی به فناوری‌های رایج‌تری مانند Java و .NET روی آوردم و در میانه دهه ۲۰۰۰ به‌عنوان «معمار» منصوب شدم.
در تمام تغییرات شغلی‌ام در طول سال‌ها، متوجه شدم که پیشرفت از مهندس نرم‌افزار به معمار یکی از سخت‌ترین مراحل است. در آن زمان فکر می‌کردم که صرفاً وارد نسخه‌ای ارشدتر از نقش قبلی‌ام می‌شوم، اما در واقع این اولین بار بود که به‌طور جدی با جنبه‌های تجاری فناوری اطلاعات آشنا می‌شدم؛ چه از طریق مدیرانی که در کنارشان کار می‌کردم و چه با مشتریانی که به آن‌ها خدمت می‌دادم.
چیزی که در این دوره بیشتر از همه یاد گرفتم این بود که ارتباط مؤثر برای هر معمار موفقی حیاتی است..

چرا تصویری‌سازی معماری نرم‌افزار مهم است؟

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

۲. اطمینان از انسجام
استانداردسازی نحوه تصویری‌سازی معماری‌های نرم‌افزاری اطمینان می‌دهد که همه نمودارها را به یک روش تفسیر می‌کنند و از سوءتفاهم جلوگیری می‌کند. متأسفانه، اغلب می‌بینم که معماری‌های نرم‌افزاری با استفاده از مجموعه‌ای گیج‌کننده از جعبه‌ها و خطوط، با نمادگذاری‌های ناسازگار (رنگ‌بندی، اشکال، سبک‌های خط)، نام‌گذاری مبهم، روابط بدون برچسب و انتزاع‌های ترکیبی تصویری‌سازی می‌شوند. استانداردسازی نحوه برخورد با این مفاهیم اطمینان می‌دهد که نمودارها به‌طور مداوم در سطح مناسب جزئیات رسم می‌شوند و به درک بهتر و کاهش ابهام کمک می‌کند.

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

۴. تسهیل تصمیم‌گیری
یک تصویری‌سازی واضح در اتخاذ تصمیمات آگاهانه درباره تغییرات، افزودنی‌ها یا اصلاحات سیستم کمک می‌کند. بسیاری از تیم‌ها از سوابق تصمیم معماری (ADR) یا پیشنهادات طراحی باز (ODP) برای ضبط و ارتباط تصمیمات مهم استفاده می‌کنند. نه‌تنها نمودارها می‌توانند از این فرآیند پشتیبانی کنند، بلکه اگر به‌درستی نسخه‌بندی شوند، می‌توانند به ADR/ODP مرتبط شوند تا زمینه و تاریخچه را ارائه دهند.

۵. شتاب‌دهی به ورود اعضای جدید تیم
یک نمایش بصری می‌تواند به‌عنوان مرجع مهمی برای اعضای جدید تیم عمل کند و فرآیند ورود آن‌ها را تسریع کرده و کمک کند تا سریع‌تر به سرعت برسند.

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

۱. ابزارهای رسم:
ابزار Draw.io: ابزاری مبتنی بر وب و دسکتاپ که به‌خاطر سادگی و تطبیق‌پذیری در رسم نمودارها شناخته شده است.
ابزار Lucidchart: مجموعه‌ای پیشرفته‌تر از ویژگی‌ها نسبت به Draw.io، شامل داده‌ها، اتوماسیون و همکاری تیمی.
ابزار OmniGraffle: یک برنامه قدرتمند رسم نمودار برای مک، که به‌خاطر دقت و دامنه وسیع سبک‌ها شناخته شده است.

۲. چارچوب‌های رسم:
ابزارUML (زبان مدل‌سازی یکپارچه): یک زبان مدل‌سازی استاندارد که روشی عمومی برای تصویری‌سازی طراحی یک سیستم ارائه می‌دهد.
ابزار C4 Model: یک رویکرد مدرن برای مدل‌سازی معماری نرم‌افزار که چهار سطح مختلف از جزئیات را ارائه می‌دهد: Context، Container، Component و Code.

۳. استانداردهای نمادگذاری:
ابزار C4 Model: همان‌طور که در بالا ذکر شد، این مدل چهار سطح مختلف از جزئیات را ارائه می‌دهد و استانداردی برای نمادگذاری در معماری نرم‌افزار فراهم می‌کند.

ابزار Archimate: یک زبان مدل‌سازی معماری سازمانی که برای توصیف، تحلیل و طراحی ساختارهای معماری سازمانی استفاده می‌شود.
ابزار Sparx Systems Enterprise Architect: ابزاری برای طراحی و مدل‌سازی معماری سازمانی که از استانداردهای مختلفی مانند UML و Archimate پشتیبانی می‌کند.

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

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

و الان بریم سراغ سوال بعدی که دیپ بشیم 😊

❓سؤال سوم
چطوری ساختار مدیریت Data و state رو طراحی کنیم که
داده‌های هر صفحه کش بشن (برای جلوگیری از رفرش مجدد)
در پس‌زمینه به‌روزرسانی شن (مثلا polling یا websocket)
خطاها به شکل مناسبی هندل بشن و UI واکنش درست نشون بده و وقتی کاربر برگشت به صفحه، داده‌ها سریع نمایش داده بشن ولی اگر اطلاعات جدید بود، به‌روزرسانی صورت بگیره؟


#فلاتر

یه کوچولو وقت کم آورم و سمت دولوپ بودم، فردا پاسخش رو قرار میدم 🌷