https://virgool.io/feed/@parhamzare1 fa 2026-06-07 09:19:52 https://files.virgool.io/upload/users/12014/avatar/Mi39f2.png?height=120&width=120 https://virgool.io/@parhamzare1 https://virgool.io/coderlife/%D8%A8%D9%87%D8%AA%D8%B1%DB%8C%D9%86-%DA%A9%D8%AF-%DA%A9%D8%AF%DB%8C-%D9%87%D8%B3%D8%AA-%DA%A9%D9%87-%D9%86%D9%88%D8%B4%D8%AA%D9%87-%D9%86%D8%B4%D9%88%D8%AF-r9a7kzajghgp در این مقاله من تجربه خودم رو راجب سیستم های Distributed و Real-time نوشته ام امیدوارم که براتون مفید باشه.حدود یک سال و نیم پیش من مسئله ای داشتم برای انتقال داده های بزرگ از یک دیتابیس RDBMS به چندین دیتابیس Schema less به صورت لحظه ای و با کمترین قطعی و دیتایی هم که داشت منتقل میشد باید روش یک سری عملیات انجام میشد (Aggregations) و به صورت هدفمند روی دیتابیس های مقصد نوشته میشد و اپلیکیشن های جدید هم این دیتا های Aggregated شده رو از این دیتابیس های جدید میخوندند و دیتا رو نشون میدادن . در ابتدا من شروع کردم به بررسی و اولین گزینه ای که برای پیاده سازی بود ست کردن Trigger ها روی دیتابیس مبدا بود و انجام عملیات بعد از call شدن اون Trigger ها .مشکلی که وجود داشت باید برای تک تک Operation ها روی هر Table کد مینوشتم در لایه دیتابیس و این پیچیدگی دیتابیس اصلی رو میبرد بالاو من به این باور رسیده بودم قبلا که بهترین کد کدی هست که نوشته نشودپس شروع کردم به جستجو و تحقیق و با شرکت Confluent اشنا شدم . در یک سال و نیم اخیر من حدود ۸ تا از ایونت های شرکت Confluent رو حضور داشتم آخرینش هم Kafka Summit Europe 2021 که چند هفته پیش برگزار شد. و من اطلاعاتی راجب سیستم های Distributed Mode ها و Event Driven Application ها کسب کردم و موازی با این کنفرانس ها شروع به یادگیری ، تحقیق و پیاده سازی این سیستم ها کردم و اون مسئله ای که من داشتم با کمترین پیچیدگی ، با کمترین قطعی (بالاترین uptime) و نوشتن کمترین کد به همراه ویرایش داده ها در بین مسیر به دیتابیس های مقصد مینوشتم.شکل زیر نمای کلی از کاری که من میخواستم انجام بدم رو نشان میدهد. پردازش داده و انتقال داده از دیتابیس مبدا به دیتابیس های مختلف خوشبختانه این تنها مزیت این سیستم نیست و این سیستم ها به ما کمک میکنه به پردازش لحظه ای داده (Real-time process) و اینکه داده هایی که داریم رو بهتر بشناسیم یا اینکه روی این داده ها پردازشی انجام بدیم و این داده ها رو به اشتراک بگذاریم بین تیمهای مختلف از جمله تیم های پردازش داده و یادگیری ماشین ، برنامه نویسی و تیم های دیگر و یا اینکه این داده ها رو Visualize کنیم.نمونه هایی اجرا شده از این سیستم در صنعت های مختلف هست مثل صنعت های مالی ، بازی ، فروشگاه ای اینترنتی گردشگری و نمونه هایی از این جنس که دیتا به صورت لحظه ای تغییر میکنه و جایی رو این داده ها تصمیمات بیزینسی گرفته میشه یا به کاربر چیزی اطلاع داده میشود.نمونه ای از پیاده سازی این سیستم در صنعت بازی در شکل زیر میبینیدپردازش داده کافکاممنون از وقتی که گذاشتین و مطالعه کردین ?منابع :وبسایت ها https://www.confluent.iohttps://kafka.apache.orghttps://debezium.ioکتاب ها Kafka The Definitive Guide REAL-TIME DATA AND STREAM PROCESSING AT SCALE Data Sharing for Dummies پرهام زارع پرهام زارع Sat, 26 Jun 2021 00:17:00 +0430 https://virgool.io/@parhamzare1/%D9%85%D9%87%D9%86%D8%AF%D8%B3-%D9%86%D8%B1%D9%85-%D8%A7%D9%81%D8%B2%D8%A7%D8%B1-%DA%A9%DB%8C%D8%B3%D8%AA-dj8khqf2rgye در این مقاله من خلاصه ای از موارد مهم رو از فصل اول کتاب مهندسی نرم افزار گوگل نوشته ام ، امیدوارم که براتون مفید باشه مهندس نرم افزار کیست؟ اين عنوان فصل اول كتاب مهندسی نرم افزار در گوگل هست و نویسندگان اشاره ميكنن به تفاوت های یک مهندس نرم افزار و یک برنامه نويس، كه شامل سه فرق اساسی در این دو نقش ميباشد:زمان و تغييراتمقياس پذيریسبك سنگين كردن هنگام گرفتن تصميمات در زمان توسعه و هزینه های آن نويسندگان كتاب تعریف یک مهندس نرم افزار رو اينچنین تعريف ميكنن، مهندس نرم افزار همان برنامه نويس هست منتهی تركيب شده با زمان و با مسئولیت های بیشتر و اشاره كرده كه برنامه نویسی يك بخش خیلی مهمی از توسعه نرم افزار هست و اشاره میکنه به نوع تسک های یک برنامه نويس و مهندس نرم افزار، که برنامه نويس فقط کارش نوشتن کد هست ولی مهندس نرم افزار وظیفه اش توسعه ، ويرايش و نگهداری اون کد هست .و در ادامه با يك سوال مهم به سراغ تشريح كردن اون سه فرق یک سوال رو میپرسه و اون سوال اين استانتظار شما از طول عمر كدي كه شما نوشتين چقدر است؟و در جواب اين سوال اشاره ميكنه به عامل های زیادی از جمله dependencies های مختلف كه باعث تغيير در نرم افزار ميشن و در نتيجه به كلمه ديگه اشاره ميكنه به اسم تشخيص كه تشخيص دادن چقدر مهم است و تمایز اصلی یک برنامه نویس و يك مهندس نرم افزار هست.این توانایی تشخیص دادن تفاوت اصلی هست كه به اسم پایداری (sustainability) شناخته ميشه و توضيح ميده كه برنامه شما زماني پايدار است  كه در طول عمری كه شما برای نرم افزارتان پيش بينی كردين قادر باشين كه به تغييرات مهمي كه مياد سمت نرم افزار شما ، واكنش نشون بدين چه تغييرات بیزینسی و چه تغييرات تكنيكال و تاكيد مي كنه ما فقط دنبال توانايی هستيم و ممكنه كه شما توانایی  پاسخ به تغییرات را داشته باشين ولی به دلايل ديگه مثل نداشتن اولويت يا نداشتن ارزش تغییرات جدید رو اعمال نكنين. ولی اگه اين امكان رو نداشته باشين كه واكنش نشون بدين به تغييرات شما در موقعیت خطرناکی هستين كه دست به دعا برمیدارین كه خدا كنه اين تغيير نياز جدی نشه. ولی به یک قانون اشاره میکنه شاید در کوتاه مدت نياز سراغتون نیاد ولی در بلند مدت حتما سراغتون میاد .و در ادامه به تاثير تغييرات يك برنامه نويس و يك مهندس نرم افزار اشاره ميكنه كه تسك هاي يك برنامه نويس معمولا شخصی  هست ولی تسك هاي يك مهندس نرم افزار روي يك تيم اثر ميزاره، و اشاره ميكنه به اين كه توسعه تيمي اين روزها يك مشكل جديد هست ولي ميتونه به شما توانايي توليد يك سيستم ارزشمند میده برخلاف برنامه هايی كه به صورت فردی نوشته شده اند.سازمان دادن يك تيم ، عملكرد يك نرم افزار و تركيب پروژه ها از پيچيدگي هاي يك مهندس نرم افزار ميباشد. و اين مشکلات ميتونن رو مقياس دادن (scale) نرم افزار تاثير بزارن . همچنين اشاره كرده به اين كه مقياس پذيري ميتونه مشکلات ديگري هم داشته باشه از جنس ارتباط ، ارتباط بين انسان ها و بحث بين اونها.در نهایت به این اشاره میکنه که مهمترین هدف یک مهندس نرم افزار هدفش پایداری و مدیریت هزینه های scale برای یک سازمان هست.زمان و تغییراتوقتي بحث تغييرات ميشه نويسنده به دو نوع نرم افزار اشاره ميكنه کدهایی با عمر كوتاه و کدهایی كه هيچ پاياني ندارند و هميشه نياز به تغييرات دارن و از دلايلی صحبت ميكنه كه باعث سخت تغيير دادن نرم افزار در اينده ميشن يا كاملا جلو تغيير رو ميگيره .دلايلي از جمله اشنا نبودن برنامه نويس با تسکی كه داره انجام ميده یا تخمين اشتباه در اندازه زمان تغييراتی كه نرم افزار نياز داره و اينها باعث ميشه كه جلوی تغییرات رو بگیره و شركت ها از يك جايی به بعد قيد توسعه محصول قديمی رو بزنن و تصمیم بگیرن که ديگه اپديتش نکنن و يك كد جديد رو بنویسن.و در ادامه نويسنده اشاره ميكنه به دو نوع كد ، کدی كه فقط كار ميكنه در مقابل کدی كه قابل توسعه هست كه به يك قانون شبيه ميكنه به نام Hyrumو اين قانون به اين اشاره ميكنه به بحث تغيير و حفظ نرم افزار در طول زمان و اشاره ميكنه كه اين هميشه کد های غیر قابل توسعه به وجود مياد و ما نميتونيم كه جلوش رو بگيريم که پیش نیاد بلكه فقط ميتونيم كه روندش رو کاهش بديم .مقياس پذيریابتدای این بخش نویسنده دوباره مبحث پایداری رو بررسی میکنه و همچنین توانایی انجام تغییرات رو و اشاره میکنه که Codebase سازمان شما زمانی پایدار هست که قادر به انجام تغییرات در آن باشین بدون هیچ خطر خاصی و اگر ما این مسله توانایی رو پنهان کنیم به صورت خطی و در طول زمان هزینه به سیستم اضافه میکنیم و امکان مقیاس پذیری را از نرم افزار رو میگیریم.و در ادامه به این مورد اشاره میکنن هزینه های توسعه فقط محدود به توسعه نیروهای انسانی نیست و خود توسعه خود جریان کاری(Workflow) شما هم مهمه، همانطور که خود نرم افزار نیاز به توسعه منابع داره مثل حافظه و پهنای باند نوع شکل توسعه نرم افزار و درگیری نیرو های انسانی با این شکل توسعه هم باید قابل توسعه باشن. مثلا اگه برای تست یکی از بخش های نرم افزار منابع بیشتری مصرف کنین و این به ازای هر نفر این منابع بیشتر مصرف میشه شما در حالت ناپایداری هستین و باید این روند رو بهبود بدین.و در نهایت بعد از توسعه انسانی و جریان کاری ، مهمترین دارایی یک سازمان که همون Codebase اصلی هست هم باید قابل توسعه باشد .و چیزهای مختلفی میتونه جلوی این توسعه رو بگیره مثل رشد در چیزهای مختلفی در طول زمان مانند افزایش زمان بیلد نرم افزار یا افزایش لاگ های مربوط به سیستم کنترل نسخه و ممکن هست که اینها باعث بشن که مسیر توسعه خیلی راحت نباشه و باید مراقب باشیم که دچار مشکل قورباغه اپ پز شده نشویم.و در ادامه نویسنده سیاست های مقایس پذیری رو به دو قسمت تقسیم کرده سیاست های که قابل توسعه نیستن و سیاست هایی که قابل توسعه هستن به خوبی. و این دو قسمت رو میشه در سازمان های خود پیدا کرد و دسته بندیشون کرد. سبك سنگين كردن هنگام گرفتن تصميمات در زمان توسعهگرفتن تصمیمات درست زمانی اتفاق میفته که ما به صورت کامل بدونیم چه چیزی رو میخواهیم توسعه بدهیم و یا کامل در جریان عمر نرم افزاری که روش کار میکنیم باشیم و میدونیم که چه جوری سیستم رو مقیاس بدیم و فیچر های جدید رو اضافه کنیم توسط مهندسان بیشتر این جمله ای هست که نویسنده درباره این تاپیک شروع کرده است.وقتی بحث تصمیمات میشه نویسنده یک مثال خوب میزنه که تو مهندس نرم افزار هم مثل زندگی ما تصمیمات درست اتفاقای خوبی هم برامون رقم میزنه ولی خب اشاره میکنه که شاید همیشه هم خوب نشه ولی دلیلی نمیشه که شما از جملاتی مثل اینکه "به خاطر اینکه من گفته بودم" استفاده کنین و در گوگل از این جمله خیلی خوششون نمیاد و اشاره میکنه که تو تیم های مختلف یک نفر هست که باید بتونه برای هر موضوعی و یا هر تاپیکی راه های متنوع و مشخصی را پیشنهاد بده و هدف اینست که همه با این نظرات موافق باشن و مهم تصمیم جمعی هست نه فردی و این رو هم باید در نظر گرفت که همیشه تصمیم اشتباه پیش میاد و یکی از معیارهای تصمیم گیری بین ایده ها هزینه ها هست که به دو قسمت تبدیل میشه هزینه های کلی و هزینه های مهندسی.و یک مثال خیلی جالب میزنن که منظور از هزینه چی هست ؟ منظور صرفا هزینه نرم افزاری نیست و هزینه تقسیم میشه به موارد مختلف مثل هزینه های مالی ُکه منظور پول هست ، یا هزینه منابع که منظورشون Cpu time هست ، هزینه های نیروی انسانی و میزان کارامد بودنشون و یا هزینه های تاثیر بر روی جامعه هم مهم هست این ها فقط نمونه هایی از هزینه ها هستن.و به یک مورد جالب اشاره میکنن که اینکه همیشه شما پول تو حسابتون باشه و بتونین همه هزینه ها رو پرداخت کنین الزاما ارزش آفرینی نمیکنه و یکی دیگه از هزینه ها و ارزش های یک سازمان نیروهای یک سازمان هستن و نیروها هم باید احساس این رو کنن که ماژول خوبی رو توسعه میدن و در سیستم استفاده میشه و میتونن که ارزش آفرین باشن درون یک سازمان و اگه این مورد نباشه مشکلاتی که تا الان راجبش حرف زدیم پیش میاد و اگه یک نیرویی خوشحال باشه به راحتی میشه بر مشکلات غلبه کرد. و در ادامه نویسنده اشاره میکنه به پارامتر های مختلف که جلوی هدر رفتن انرژی رو میگیرن از جمله فراهم کردن ساده ترین چیزها برای برگزاری جلسات مثل ماژیک که در همه کمدها ماژیک در انواع رنگ های مختلف وجود دارن که لحظه ای کمبود به وجود نیاد و از فکر خارج نشن. نتیجه گیری وقتی که صحبت از تفاوت برنامه نویس و یک مهندس نرم افزار میشه با دونستن موارد بالا که بهشون اشاره کردیم نتیجه این نیست که مهندسی نرم افزار از یک برنامه نویس برتر هست یا نه بحث نوع پروژه و اهمیت پروژه هست شاید ما تصمیم بگیریم و یک پروژه رو صرف ۳ روز توسط برنامه نویس توسعه بدهیم و بعد هم نیازی به توسعه اش پیدا نکنیم و حتی نیازی به بررسی موارد مختلف نباشه و بیشتر این تمایز به خاطر مدیریت و بهبود نرم افزار در طول زمان هست و اینکه نرم افزار قابل توسعه و قابل نگهداری بین یک تیم باشد و مهندس نرم افزار چنین وظیفه ای را دارد. پرهام زارع پرهام زارع Sun, 02 May 2021 18:49:54 +0430 https://virgool.io/@parhamzare1/%D8%BA%D9%88%D9%84-%D8%A8%D8%B2%D8%B1%DA%AF%DB%8C-%DA%A9%D9%87-%D8%AC%D9%84%D9%88%DB%8C-%D8%B1%D8%B4%D8%AF-%DA%A9%DB%8C%D9%81%DB%8C%D8%AA-%D9%85%D9%88%D8%A8%D8%A7%DB%8C%D9%84-%D8%A7%D9%BE-%D9%87%D8%A7-%D9%88-%D9%88%D8%A8-%D8%A7%D9%BE%D9%84%DB%8C%DA%A9%DB%8C%D8%B4%D9%86-%D9%87%D8%A7-%D9%88-%D8%A7%D8%AC%D8%B1%D8%A7%DB%8C-%D9%88%D8%A8-%D8%B3%D8%A7%DB%8C%D8%AA-%D9%87%D8%A7-%D8%AF%D8%B1-%D9%85%D9%88%D8%A8%D8%A7%DB%8C%D9%84-%D8%B1%D8%A7-%D9%85%DB%8C%DA%AF%DB%8C%D8%B1%D8%AF-zvfzhd2tanrl توسعه موبایل اپ ها یا وب سایت ها برای موبایل ها یکی از چالش های قشنگ و پر از یادگیری است .من قبلا به عنوان یک توسعه دهنده بکند همیشه برام عجیب بود که چرا موبایل ها به نرمی دسکتاپ ها نیستن و شروع کردم به عنوان یک توسعه دهنده موبایل کار کردن در 3 سال گذشته و این مقاله رو نوشتم و توضیح دادم از مشکلات موبایل اپ ها و اینکه چه چیزی باعث میشه موبایل اپ ها یا وب سایت های ما در موبایل ها به نرمی اجرا نشوند .وقتی که قصد توسعه یک موبایل اپ را داریم همیشه بر این اساس جلو می رویم که یک تیم Api یک سرویس به موبایل اپ میدهند و میگویند این هم داکیومنت Api که الحق و انصاف کامل و جامع است. این تصمیم در نگاه اول درست به نظر میرسد ولی وقتی کاربر با اپ کار میکند و زمان بیشتری را با اپ صرف میکند، اپ شروع میکند به کند شدن و تپق زدن و بعضا هم در همان اجرای اول اپ به سختی اجرا میشود و چیزی شبیه Bottleneck اتفاق می افتد.این مشکل به دو دلیل رخ میدهد دلیل اول:دریافت داده از شبکه و تبدیل آن به محتوای قابل فهم برای موبایل اپ ها هست که هر چقدر حجم این داده ها بیشتر باشد زمان بیشتری صرف می شود تا برنامه آماده تعامل با کاربر شود . (Time to Interact)دلیل دوم :توسعه ندادن Api بر اساس نیاز موبایل اپ ها ، چیزی که در اکثر مواقع اتفاق می افتد و کیفیت رو فدا می کنیم استفاده از همان Api وب سایت هامون برای موبایل اپ ها هست و خب به دلیل اینکه موبایل اپ ها از منابع خیلی کمتری برخوردارند توانایی پردازش به خوبی Desktop ها را ندارند. راه حل این موضوع تغییر تفکر و بازنگری در ترتیب مراحل توسعه موبایل اپ ها است یعنی اینکه اول UI را توسعه میدهیم و سپس بر اساس اون Api را توسعه میدهیم. و در نهایت هم استفاده از ابزار های مختلف برای اندازه گیری Performance ها بعد از اجرای هر کدوم از فیچر ها میباشد . برای موبایل اپ ها از ابزار هایی مثل Firebase, Newrelic و برای وب سایت هایی که در موبایل اجرا میشوند تب Performance مرورگر که نشان میدهند که وب سایت شما در موبایل ها چگونه آماده میشوند تا کاربر از وبسایت شما استفاده کند .غول بزرگی که جلوی رشد کیفیت موبایل اپ ها و وب اپلیکیشن ها و اجرای وب سایت ها در موبایل را میگیرد. پرهام زارع پرهام زارع Thu, 17 Dec 2020 12:56:53 +0330 https://virgool.io/@parhamzare1/%D8%AD%D9%81%D8%B8-%D8%AA%D8%B9%D8%A7%D8%AF%D9%84-%D8%AF%D8%B1-react-native-n48iescgirw1 سلام به همه دوستان اين مقاله يا بهتر بگم اين نوشته درباره حفظ تعادل در React Native هست و اينكه چرا اين قضيه مهم هست و ميتونه تاثير بزاره در نحوه كار كردن كاربر با اپليكيشن شما. اول از همه بگم وقتي من شروع به نوشتن اپ با اين فريم ورك كرده بودم من يك بكند دولوپر بودم و برام جالب بود كه ميشه با جاوااسكريپت كدي نوشت كه توسط كد هاي Java يا Objective-C رندر بشن. پس شروع كردم به مطالعه درباره اين فريم ورك و بعد از مدتي كلا تغيير فيلد دادم و مشغول توسعه موبايل اپ و بعد از مدتی توسعه اپ های Cross Platform و حل كردن چلنج هاي جذاب و به قول معروف سخت شدم.اول از همه بهتره يكم راجب خود React Native بنويسم كه دقيقا چي هست، ريكت نيتيو يك فريم ورك و يك واسط اصطلاحا يك پل بين كدهاي جاواسكريپت و كد هاي نيتيو مثل Java يا Objective-c هست، كه وقتي شما در JS نياز به اپديت UI و يا دريافت اطلاعات مربوط به دستگاه را ميخواين به Bridge اعلام ميكنين و اون به نيتيو اعلام ميكنه و بعد نيتيو درخواست شما رو پردازش ميكنه و به Bridge اعلام ميكنه و اون هم نتيجه جواب رو به JS اعلام ميكنه.در نگاه اول تصور كنين كه اپديت هاي ما و درخواست هاي ما در JS سنگين باشه يا زياد باشه و Bridge مجبور باشه هر لحظه درخواست هاي شما رو منتقل كنه و منتظر جواب بمونه و همين رفت و امد ها باعث ميشه كه اپليكيشن شما منابع بسياري رو از CPU ، Ram و بقيه سخت افزار هاي دستگاه رو مصرف كنه و همينطور باعث كندي اپ شما بشه و در نهایت باتری بیشتری مصرف کنه. ساده ترين مثالي كه ميشه گفت براي اين نمونه استفاده از كامپوننت TextInput هست.وقتي كاربر شروع به تايپ كردن در يك TextInput ميكنه اتفاقي مثل شكل زير رخ ميده و ميبينين كه در قدم اول از سمت نيتيو اعلام ميشه كه كاربر يك حرف رو وارد كرده و نيتيو فانكشن Text رو صدا ميزنه و بعد از اون در Js فانكشن SetValue صدا زده ميشه تا React تغييرات رو بفهمه و پردازش كنه و به Native هم تغييرات اعلام بشه و كامپوننت رندر بشه مجدد و همين عمل ساده براي هر كاراكتري كه كاربر وارد ميكنه اتفاق ميفته و براي همين عمل ساده براي تايپ كلمه Test حدود ٨ بار ارتباط بين Native و JS برقرار شده تا اينجاي كار همه چي خيلي خوب كار ميكنه مشكل وقتي شروع ميشه كه ديوايس كاربر ضعيف باشه يا كاربر خيلي سريع تايپ ميكنه و وقتي كاربر تايپ ميكنه برنامه شروع ميكنه به اهسته كار كردن و اصطلاحا اتفاق UI block رخ ميده و اگر به ازای هر مقدار از این تغییرات بخواهیم فانکشن های دیگری رو صدا بزنیم مانند جستجو سربار بسیار بیشتری رو ایجاد کرده ایم و كاربر ما شروع ميكنه به عصباني شدن و ميگه چقدر گيره اين اپ. يكي از راه حل هاي ساده براي حل اين مشكل اين هست كه به جاي اينكه از پراپ Value استفاده كنيم از defaultValue استفاده كنيم و اينبار نيتيو وضعيت رو اعلام ميكنه و ريكت setValue رو كه انجام ميده و چون Native نيازي به اپديت نداره به نيتيو چيزي اعلام نميشه چون مقدار جديدي رو دريافت نميكنه و كامپوننت شما نيازي به رندر تكراري و يكسان نخواهد داشت.مسئله ديگري كه با اين اتفاق رخ ميده نوع چينش و نوع قرار گيري كامپوننت ها كنار هم هستن و اگر در كد بالا نگاه كنين هربار useState صدا زده ميشه براي اپديت TextInput بقيه كامپوننت ها درون كامپوننت PizzaTranslator هم رندر ميشوند و در طراحي ها و چينش ها بايد به اين مسئله دقت شود و هرچه به اتميك ديزاين نزديكتر بشيم اين مسئله كمتر اتفاق مي افتد.شبكه:يكي از بزرگترين چالش هاي كه در توسعه اپ با React Native شبكه هست . همه ما ميدونيم كه يك سري ديتا بايد از Api بخونيم و به كاربر به صورت مرتب شده نشون بديم تا اينجاي كار هم باز همه چيز خوبه ولي اينجا مشكل ميخوريم كه ديتايي كه ميخوايم از Api بخونيم با استفاده از JS بگيريم و هرچه قدر اين ديتا سنگين تر باشه و بيشتر طول بكشه اتفاق UI Block ميفته چرا ؟ افرين چون Javascript Single thread هست و هر در يك زمان مشخص يك كار بيشتر انجام نميده و كارها در Event loop منتظر ميمونن تا تسك قبلي انجام بشه و به همين خاطر هست كه كاربر كه ديتا داره براش لود ميشه و اگه بخواد يك كار ديگه تو اپ انجام بده با كندي و يا قفل شدن اپ اتفاق ميفته و هر چقدر رم كاربر محدود باشه اين اتفاق بيشتر رخ ميده.راه حل رفع مشكل تقسيم درست وظايف هست يعني به جايي اينكه JS رو خودش بفرستيم بگيم برامون اطلاعات از سرور بگيره به نيتيو كد ها ميگيم شما ديتا رو بگير و هر موقع اومد به JS اعلام كن و اين باعث ميشه كه JS سبك بال به بقيه درخواست هاي كاربر جواب بده.اگر در شكل بالا يك سمت JavaScript و در سمت ديگه كد هاي Native باشن هر كدوم از سمت ها سنگين تر شون يك سري معايب و يك سري مزايا اتفاق ميفته و براي مثال اگه تمامي كد ها JS بشن كاربر اون نرمي و روون و بودن اپ رو حس نميكنه و اگه كد ها هر چه بيشتر سمت نيتيو بره ايجاد يك كدبيس سختتر ميشه و توسعه اپ براي پلتفرم هاي مختلف با يك كدبيس سختتر ميشه .در نهایت توسعه اپ های کراس پلتفرم و بقیه اپ ها در وهله اول نیازمند به کشیدن دیاگرام های مختلف و وقت گذاشتن برای تحلیل درست و تقسیم درست وظایف هستن. و هرچقدر این قدم اول کامل تر باشد جلوگیری میکنه از سرو کله زدن با باگ های بیشمار و همچنین کانفلیکت های مختلف.ممنون که تا اینجا من رو همراهی کردین و امیدوارم که این نوشته به کمکتون بیاد و بتونیم محصول بهتری رو برای کاربرامون توسعه بدهیم و خوشحال میشم که نظر ها و انتقاداتون رو راجب این مقاله بگین بهم .منابع:React Native Website Design Pattern With React NativeThe Ultimate Guide To react native Optimization پرهام زارع پرهام زارع Wed, 17 Jun 2020 18:46:53 +0430 https://virgool.io/@parhamzare1/%D8%A7%D9%81%D8%B2%D8%A7%DB%8C%D8%B4-%DA%A9%DB%8C%D9%81%DB%8C%D8%AA-%D9%88-%D8%B3%D8%B1%D8%B9%D8%AA-%D8%AA%D9%88%D8%B3%D8%B9%D9%87-%D9%88%D8%A8-%D8%B3%D8%A7%DB%8C%D8%AA-%D9%88-%D8%A7%D9%BE%D9%84%DB%8C%DA%A9%DB%8C%D8%B4%D9%86-w0id39uootsh این روزها دنیای برنامه نویسی بسیار پیشرفت کرده و همونطور دنیای طراحان و طراحان تجربه کاربری، ابزار های متنوعی اومده کمک کنه تا یک نرم افزار یا یک وب سایت رو طراحی و توسعه بدیم ولی با این همه پیشرفت بازم شاهد مشکلات زیادی هستیم مثل کیفیت نرم افزار ، دوباره کاری های فراوان حتی با وجود متدولوژی های مختلف توسعه نرم افزار ، نزدیک نبودن تفکر وب سایت به اپلیکیشن یا بالعکس و همیشه سوال اصلی این هست که چکار باید کرد تا نرم افزار کیفییتش بهتر بشه یا طرح بهتر خودشو نشون بده ؟ یا چطور سیستم رو دولوپ کنیم که فیچر های بعدی با سرعت وکیفیت بیشتر به سیستم اضافه بشه شاید اولین چیزی که به ذهن برنامه نویس برسه درگیر شدن با سیستم های بهینه سازی برای بهتر شدن نرم افزار باشه یا طراح هم شروع به بهینه سازی برای طرح کنه ولی مشکل اصلی جایی دیگری هست، مشکل عدم همزمانی و هم زبانی برنامه نویس و طراح و طراح تجربه کاربریست در صورتی که این سه تیم باید یک تیم واحد باشن و از ابتدا با هم شروع به توسعه تفکر سیستم باشن .منظور از تفکر سیستم این هست که تفکر برنامه نویس ، طراح و طراح تجربه کاربری به یک تفکر واحد برسه و وقتی قراره برای بخشی از نرم افزار طرحی زده بشه هر سه تیم باهم جلسه میگذارن و صحبت میکنن و سیستم رو به واحد های کوچکتر تبدیل میکنن و یا اصطلاحا سیستم رو تبدیل به کامپوننت های کوچکتر تبدیل میکنن و کامپوننت ها رو بر اساس نیاز ها و استفاده های مجدد اولویت بندی میکنن و برچسب گذاری میکنن و به صورت موازی شروع میکنن روی کامپوننت ها کار کردن نه به صورت سریالی هر چی موازی کار کردن ها بیشتر باشه تعاملات بیشتر میشود و از هزینه های بازگشت دوباره و تغییرات مجدد جلوگیری میکنه و برنامه نویس به تغییرات طراح یا تجربه کاربر واکنش زیادی نشون نمیده که بگن چقدر طرح عوض میشه یا چقدر دوباره باید کد نویسی کنیم و بالعکس تجربه کاربری برای تغییرات خیلی منتظر نمیمونه و سیستم با تمرکز و سرعت بیشتری رو به جلو حرکت میکنه وقتی تفکر سیستم یک واحد باشه به صورت اتوماتیک هم کد نویسی، هم طراحی و هم طراحی تجربه کاربری شفاف تر میشه و تصمیمات درست تری در لایه های مختلف میشه گرفت و این به صورت اتوماتیک کمک میکنه به افزایش پایداری یک نرم افزار و پایداری طرح ها و پایداری یک بیزینس ...ممنون از وقتی که بابت مطالعه این مقاله گذاشتین در مقاله بعدی ابزارهایی رو معرفی میکنم که کمک میکنه به نزدیک شدن این سه تیم و رفع مشکلات این سه تیم . پرهام زارع پرهام زارع Fri, 31 May 2019 15:44:34 +0430