Forwarded from My Flutter Experience💙 (Abolfazl)
⭕️از فلاتر تا مارکت😳
قدم به قدم مراحلی که باید برای دپلویی کردن اپلیکیشن ها روی مارکت ها بگذرونید 😁
از ساختن پروژه فلاتری تا امضا و رفع خطا های همیشگی و دپلویی کردن و.....
https://youtu.be/3P8R_f78FZE
قدم به قدم مراحلی که باید برای دپلویی کردن اپلیکیشن ها روی مارکت ها بگذرونید 😁
از ساختن پروژه فلاتری تا امضا و رفع خطا های همیشگی و دپلویی کردن و.....
https://youtu.be/3P8R_f78FZE
YouTube
آموزش فلاتر:قدم به قدم بارگزاری اپلیکیشن های فلاتری روی مارکت ها
سلام رفقا امیدوارم حال دلتون عالی باشه ، توی این ویدو در مورد بارگذاری اپلیکیشن های فلاتری روی مارکت های مختلف صحبت میکنیم ،بارگذاری اپلیکیشن های فلاتری یکی از مهم ترین و کلیدی ترین و در عین حال چالش بر انگیز ترین کار هایی که هر flutter developer باید بلد…
🔥انواع دیتابیس ها
دیتابیس ها رو میشه به دو دسته ی کلی SQL و No SQL تقسیم کرد که خود No SQL ها انواع مختلف دارن که از جمله ی اون های نوع key-value و document هستن....
ℹ️Relational Databases (SQL)
👉MySQL, SQL Server, Oracle, Postgre SQL, SQLite, ...
2️⃣Non-Relational databases (No SQL)
✅Key-value Store or Key-value cache
👉Redis, ...
✅Document Database
👉MongoDb, ...
✅Object Storage
✅Table Storage
✅Graph Database
✅...
@purecoder_ir
دیتابیس ها رو میشه به دو دسته ی کلی SQL و No SQL تقسیم کرد که خود No SQL ها انواع مختلف دارن که از جمله ی اون های نوع key-value و document هستن....
ℹ️Relational Databases (SQL)
👉MySQL, SQL Server, Oracle, Postgre SQL, SQLite, ...
2️⃣Non-Relational databases (No SQL)
✅Key-value Store or Key-value cache
👉Redis, ...
✅Document Database
👉MongoDb, ...
✅Object Storage
✅Table Storage
✅Graph Database
✅...
@purecoder_ir
🤦♂شاید خیلی از برنامه نویس های موبایل عادت به تست نوشتن نداشته باشن ...
🤔یکی از دلایلش میتونه این باشه که پروژشون لاجیک خیلی خاصی نداره و در کل داره یه سری دیتا از سرور میگیره و نمایش میده و پردازشی روی دیتا ها انجام نمیده ...و در نتیجه خیلی سادس و بخاطر همین حوصله ی وقت گذاشتن و unit test نوشتن رو ندارن ..
❓سوال
در چنین مواقعی تست بنویسیم یا نه ؟
✅فقط برای قسمت هایی که لاجیک و پیچیدگی دارن unit test بنویسید و در نتیجه در چنین شرایطی تعداد unit test ها کم میشه و حتا ممکنه صفر بشه .
✅ولی حتمن توی چنین پروژه ها integration test بنویسید.
پ.ن: در شرایط عادی میگن که تعداد unit test های پروژه به تعداد integration test ها میچربه ولی وقتی پروزه complexity خاصی نداره ارزش هزینه کردن و unit test زدن نداره، ولی integration test در هر شرایطی باید نوشته بشه.
پس توی چنین پروژه هایی نسبت برعکس میشه و تعداد integration test ها به unit test ها غلبه میکنه.
@purecoder_ir
🤔یکی از دلایلش میتونه این باشه که پروژشون لاجیک خیلی خاصی نداره و در کل داره یه سری دیتا از سرور میگیره و نمایش میده و پردازشی روی دیتا ها انجام نمیده ...و در نتیجه خیلی سادس و بخاطر همین حوصله ی وقت گذاشتن و unit test نوشتن رو ندارن ..
❓سوال
در چنین مواقعی تست بنویسیم یا نه ؟
✅فقط برای قسمت هایی که لاجیک و پیچیدگی دارن unit test بنویسید و در نتیجه در چنین شرایطی تعداد unit test ها کم میشه و حتا ممکنه صفر بشه .
✅ولی حتمن توی چنین پروژه ها integration test بنویسید.
پ.ن: در شرایط عادی میگن که تعداد unit test های پروژه به تعداد integration test ها میچربه ولی وقتی پروزه complexity خاصی نداره ارزش هزینه کردن و unit test زدن نداره، ولی integration test در هر شرایطی باید نوشته بشه.
پس توی چنین پروژه هایی نسبت برعکس میشه و تعداد integration test ها به unit test ها غلبه میکنه.
@purecoder_ir
🔥Value Object
⭕️هر ابجکتی یه سری فیلد داره و یک سری متد داره که یه بلاهایی سر اون فیلد ها میارن
⭕️این متد ها میتونن مقدار فیلد ها رو تغییر بدن و بنابراین باعث تغییر state ابجکت مورد نظر بشن.
⭕️بنابراین در چنین شرایطی متدهای ابجکت مورد نظر side effect دارن.... چون باعث تغییر مقدار فیلد های ابجکت شدن..
⭕️بعضی مواقع دوست نداریم متدهای یه ابجکت side effect داشته باشن و مقدار فیلد ها رو تغییر بدن .
⭕️در چنین شرایطی:
🟢 کلیه فیلد های اون ابجکت باید غیر قابل تغییر بشن.. (final)
🟢متدهایی از ابجکت که قبلن void بودن و مقدار فیلد های ابجکت رو تغییر میدادن، از این به بعد باید یه instance جدید از اون ابجکت رو return کنن.
🟢ابجکت باید متد equality داشته باشه که براساس structural equality عمل میکنه و نه Reference Equality...
⭕️با اعمال سه شرط بالا ابجکت مورد نظر به یک ValueObject تبدیل میشه.
✅در نتیجه Value Object ها رو هیج موقع نمی‌تونیم آپدیت کنیم و اگه بخوایم یه Value Object با ویژگی های جدید داشته باشیم، به جای آپدیت کردن قبلی باید یه دونه از اول بسازیم .
✅این Value Object ها توی unit test نوشتن به خصوص خیلی بهمون کمک میکنن و میتونیم لاجیک های مهم برنامه رو داخلشون قرار بدیم و به دلیل اینکه side effect ندارن و state اشون تغییر نمیکنه، کاربرد های مفیدی رو بهمون میدن .
@purecoder_ir
⭕️هر ابجکتی یه سری فیلد داره و یک سری متد داره که یه بلاهایی سر اون فیلد ها میارن
⭕️این متد ها میتونن مقدار فیلد ها رو تغییر بدن و بنابراین باعث تغییر state ابجکت مورد نظر بشن.
⭕️بنابراین در چنین شرایطی متدهای ابجکت مورد نظر side effect دارن.... چون باعث تغییر مقدار فیلد های ابجکت شدن..
⭕️بعضی مواقع دوست نداریم متدهای یه ابجکت side effect داشته باشن و مقدار فیلد ها رو تغییر بدن .
⭕️در چنین شرایطی:
🟢 کلیه فیلد های اون ابجکت باید غیر قابل تغییر بشن.. (final)
🟢متدهایی از ابجکت که قبلن void بودن و مقدار فیلد های ابجکت رو تغییر میدادن، از این به بعد باید یه instance جدید از اون ابجکت رو return کنن.
🟢ابجکت باید متد equality داشته باشه که براساس structural equality عمل میکنه و نه Reference Equality...
⭕️با اعمال سه شرط بالا ابجکت مورد نظر به یک ValueObject تبدیل میشه.
✅در نتیجه Value Object ها رو هیج موقع نمی‌تونیم آپدیت کنیم و اگه بخوایم یه Value Object با ویژگی های جدید داشته باشیم، به جای آپدیت کردن قبلی باید یه دونه از اول بسازیم .
✅این Value Object ها توی unit test نوشتن به خصوص خیلی بهمون کمک میکنن و میتونیم لاجیک های مهم برنامه رو داخلشون قرار بدیم و به دلیل اینکه side effect ندارن و state اشون تغییر نمیکنه، کاربرد های مفیدی رو بهمون میدن .
@purecoder_ir
🔥YAGNI + KISS Principle
➡️ You ain't gonna need it.
➡️keep it super simple.
( keep it simple, stupid)
😢یکی از اصول فراموش شده ی برنامه نویسی و البته خیلی خیلی مهم اصل YAGNi هست که از همه اصول دیکه میتونه مهمتر باشه .
خیلی وقت ها ما سعی میکنیم چیزایی که الان نیازمون نیست رو توی پروژه پیاده کنیم و در نتیجه complexity زیادی رو به پروژه تحمیل کنیم و توجهیمون هم اینه که در آینده بهش نیاز داریم.
درستش اینه که هر موقع آینده اومد به فکرش باشیم.
ما الان اطلاعات کاملی از نیاز های آینده نداریم و احتمالن چیزی که پیاده میکنیم نه تنها بدرد آینده نمیخوره بلکه الان هم دست و پامون رو میبنده و maintain کردن پروژه رو سخت میکنه .
این قضیه معماری ها و ساختار های توهمی که از ابتدا به پروژه تحمیل میکنیم و توجیهمون اینه که میخوایم توسعه رو آسون کنیم و بدتر سختش میکنیم رو هم شامل میشه 🤦♂🤦♂🤦♂
از اصولی که الان نیازی بهشون نداریم، حتا اصول خوشکل موشکل سالید، و فقط برای قشنگی اعمالشون میکنیم گرفته تا اینترفیس های بی موردی که می‌سازیم و هیچ توجیهی واسشون نداریم و دیزاین پترن هایی که بی جهت به کد تحمیل میکنیم و ....
اصل YAGNI و اصل kISS خوب کنار هم جفت و جور میشن و باید سعی کنیم تا جایی که میشه اولن پروژه رو از Needless Complexity نجات بدیم و چیزایی که الان لازم نداریم رو الکی implement نکنیم و دومن functionality های باقی مونده رو هم تا حد امکان simple پیاده کنیم .
@purecoder_ir
➡️ You ain't gonna need it.
➡️keep it super simple.
( keep it simple, stupid)
😢یکی از اصول فراموش شده ی برنامه نویسی و البته خیلی خیلی مهم اصل YAGNi هست که از همه اصول دیکه میتونه مهمتر باشه .
خیلی وقت ها ما سعی میکنیم چیزایی که الان نیازمون نیست رو توی پروژه پیاده کنیم و در نتیجه complexity زیادی رو به پروژه تحمیل کنیم و توجهیمون هم اینه که در آینده بهش نیاز داریم.
درستش اینه که هر موقع آینده اومد به فکرش باشیم.
ما الان اطلاعات کاملی از نیاز های آینده نداریم و احتمالن چیزی که پیاده میکنیم نه تنها بدرد آینده نمیخوره بلکه الان هم دست و پامون رو میبنده و maintain کردن پروژه رو سخت میکنه .
این قضیه معماری ها و ساختار های توهمی که از ابتدا به پروژه تحمیل میکنیم و توجیهمون اینه که میخوایم توسعه رو آسون کنیم و بدتر سختش میکنیم رو هم شامل میشه 🤦♂🤦♂🤦♂
از اصولی که الان نیازی بهشون نداریم، حتا اصول خوشکل موشکل سالید، و فقط برای قشنگی اعمالشون میکنیم گرفته تا اینترفیس های بی موردی که می‌سازیم و هیچ توجیهی واسشون نداریم و دیزاین پترن هایی که بی جهت به کد تحمیل میکنیم و ....
اصل YAGNI و اصل kISS خوب کنار هم جفت و جور میشن و باید سعی کنیم تا جایی که میشه اولن پروژه رو از Needless Complexity نجات بدیم و چیزایی که الان لازم نداریم رو الکی implement نکنیم و دومن functionality های باقی مونده رو هم تا حد امکان simple پیاده کنیم .
@purecoder_ir
توی فلاتر به جای ویجت Container میتونید از ویجت های زیر و ترکیبشون استفاده کنید :
✅ConstraintedBox
✅SizedBox
✅ColoredBox
✅DecoratedBox
✅Transform
✅Align
✅Padding
✅....
چرا میگم از اینا استفاده کنید ؟
ویجت Container یه wrapper حول همه ی این ویجت هاست و با توجه به پراپرتی هایی که بهش میدی تشخیص میده که از کدوم یک از این ویجت ها یا ترکیب شون استفاده کنه ....
حالا وقتی هدفت مشخصه و میدونی چی میخوای، بهتره از همون اول از همین ویجت ها استفاده کنی (یا ترکیبشون )
اینجوری همه چی هدفمند و مشخصه
به نظر من Container برای کسایی هست که تازه تازه فلاتر رو شروع کردن و بعدش باید ازش دست بکشی (صرفن نظر شخصی)
@purecoder_ir
✅ConstraintedBox
✅SizedBox
✅ColoredBox
✅DecoratedBox
✅Transform
✅Align
✅Padding
✅....
چرا میگم از اینا استفاده کنید ؟
ویجت Container یه wrapper حول همه ی این ویجت هاست و با توجه به پراپرتی هایی که بهش میدی تشخیص میده که از کدوم یک از این ویجت ها یا ترکیب شون استفاده کنه ....
حالا وقتی هدفت مشخصه و میدونی چی میخوای، بهتره از همون اول از همین ویجت ها استفاده کنی (یا ترکیبشون )
اینجوری همه چی هدفمند و مشخصه
به نظر من Container برای کسایی هست که تازه تازه فلاتر رو شروع کردن و بعدش باید ازش دست بکشی (صرفن نظر شخصی)
@purecoder_ir
Forwarded from Jadi Var Log
Media is too big
VIEW IN TELEGRAM
اپوکالیپس؛ مشکلی که همه زمان سنج‌های یونیکسی در سال ۲۰۳۸ خواهند داشت.
مساله اینه که وقتی خدایگان یونیکس تصمیم گرفتن روشی برای زمان‌سنجی اختراع کنن، با خودشون گفتن «ما تعداد ثانیه‌های گذشته از ۱ ژانویه ۱۹۷۰ رو می‌شمریم» و برای اینکار از یه عدد ۳۲ بیتی علامت‌دار استفاده کردن و این متغیر در ۲۰۳۸ پر خواهد شد و زمان ریست میشه (: راه حل احتمالی؟ مهاجرت همه لینوکس‌ها، بی اس دی‌ها، یونیکس‌ها، دیتابیس‌ها و همه دوستاشون به زمان سنج‌های ۶۴ بیتی.
https://youtube.com/shorts/ZY4e79NIdVk?feature=share
مساله اینه که وقتی خدایگان یونیکس تصمیم گرفتن روشی برای زمان‌سنجی اختراع کنن، با خودشون گفتن «ما تعداد ثانیه‌های گذشته از ۱ ژانویه ۱۹۷۰ رو می‌شمریم» و برای اینکار از یه عدد ۳۲ بیتی علامت‌دار استفاده کردن و این متغیر در ۲۰۳۸ پر خواهد شد و زمان ریست میشه (: راه حل احتمالی؟ مهاجرت همه لینوکس‌ها، بی اس دی‌ها، یونیکس‌ها، دیتابیس‌ها و همه دوستاشون به زمان سنج‌های ۶۴ بیتی.
https://youtube.com/shorts/ZY4e79NIdVk?feature=share
🔥Data Structures
🔥توی کد هامون همیشه یه سری Data model یا Data Transfer Object یا ... داریم که فقط شامل یه سری فیلد هستن و هیچگونه متدی ندارن ...
🔥این گلاس ها یا یه سری فیلد پابلیک دارن و یا یک سری گتر و ستر و نهایتن ممکنه یه کانستراکتور هم داشته باشن .
🔥نکته مهم این هست که اگه گتر و ستر داشته باشن،گتر ها و ستر ها خیلی ساده هستن و لاجیک خاصی ندارن
🔥به این کلاس های فاقد متد میتونیم بگیم دیتا استراکچر.
❓آیا برای این کلاس ها باید تست بنویسیم ؟ ( هرچند میدونم که کلن تست نمی‌نویسید 😁😝 ولی خب)
✅خیر نیازی به تست ندارن چون که لاجیک خاصی ندارن .
❓اگه گتر و ستر و کانستراکتور داشتن چی؟
✅بازم جواب نه هست چون که لاجیک خاصی ندارن و فضایی برای اشتباه کردن وجود نداره و نیازی به تست نیست .
🔥همچنین این کلاس ها میتونن یه سری متد تحت عنوان mapper داشته باشن که اون ها رو به ابجکت های دیگه کانورت میکنه مثل ToJson یا fromJson و ...
❓آیا نیازه برای این ها تست نوشت ؟
✅بله.
✅ولی بهتره این لاجیک رو از این کلاس ها خارج کنید و کلاس های دیگه با نام Mapper توی پروژتون داشته باشید که کارشون تبدیل کردن دو تا تایپ به هم دیگه هست و اون ها رو تست کنید و دیتا استراکچر هاتون رو کلن بدون تست رها کنید .
❓اگه از پکیج ها برای مپ کردن (مثل toJson یا ...) استفاده کردیم نیازی به یونیت تست هست ؟
✅نه نیاز نیست .
نیازی به یونیت تست در این مورد نیست و یه integration test که چندین کلاس به علاوه این کلاس ها رو پوشش میده کافیه .
@purecoder_ir
🔥توی کد هامون همیشه یه سری Data model یا Data Transfer Object یا ... داریم که فقط شامل یه سری فیلد هستن و هیچگونه متدی ندارن ...
🔥این گلاس ها یا یه سری فیلد پابلیک دارن و یا یک سری گتر و ستر و نهایتن ممکنه یه کانستراکتور هم داشته باشن .
🔥نکته مهم این هست که اگه گتر و ستر داشته باشن،گتر ها و ستر ها خیلی ساده هستن و لاجیک خاصی ندارن
🔥به این کلاس های فاقد متد میتونیم بگیم دیتا استراکچر.
❓آیا برای این کلاس ها باید تست بنویسیم ؟ ( هرچند میدونم که کلن تست نمی‌نویسید 😁😝 ولی خب)
✅خیر نیازی به تست ندارن چون که لاجیک خاصی ندارن .
❓اگه گتر و ستر و کانستراکتور داشتن چی؟
✅بازم جواب نه هست چون که لاجیک خاصی ندارن و فضایی برای اشتباه کردن وجود نداره و نیازی به تست نیست .
🔥همچنین این کلاس ها میتونن یه سری متد تحت عنوان mapper داشته باشن که اون ها رو به ابجکت های دیگه کانورت میکنه مثل ToJson یا fromJson و ...
❓آیا نیازه برای این ها تست نوشت ؟
✅بله.
✅ولی بهتره این لاجیک رو از این کلاس ها خارج کنید و کلاس های دیگه با نام Mapper توی پروژتون داشته باشید که کارشون تبدیل کردن دو تا تایپ به هم دیگه هست و اون ها رو تست کنید و دیتا استراکچر هاتون رو کلن بدون تست رها کنید .
❓اگه از پکیج ها برای مپ کردن (مثل toJson یا ...) استفاده کردیم نیازی به یونیت تست هست ؟
✅نه نیاز نیست .
نیازی به یونیت تست در این مورد نیست و یه integration test که چندین کلاس به علاوه این کلاس ها رو پوشش میده کافیه .
@purecoder_ir
هر ویدئو یا مقاله ای که زبانش انگلیسی باشه نشون دهنده این نیست که هر چیزی که‌گوینده میگه درسته ...
زبان اصلی بودن اعتبار نمیاره 🤦♂
خارجی ها از کره ی مریخ نیومدن، اون ها هم آدمن، ممکنه اشتباه کنن، ممکنه چرت و پرت بگن ...
حواستون باشه به کجا رفرنس می‌زنید
@purecoder_ir
زبان اصلی بودن اعتبار نمیاره 🤦♂
خارجی ها از کره ی مریخ نیومدن، اون ها هم آدمن، ممکنه اشتباه کنن، ممکنه چرت و پرت بگن ...
حواستون باشه به کجا رفرنس می‌زنید
@purecoder_ir
🔥Entity - Model
❌اینکه توی پروژه هاتون هم Entity و هم Model درست میکنید خیلی وقت ها کار اضافیه و خیلی وقت ها همون Entity کفایت میکنه...
✅میخواین از دیتابیس استفاده کنید؟ همون Entity کافیه و میتونید از ORM برای تبدیل اسکیمای دیتابیس به Entity استفاده کنید.
✅میخواین Json رو به Entity تبدیل کنید و برعکس؟ یه mapper بنویسید که کارش تبدیل جیسون به Entity و برعکس هست .
چه لز‌ومی داره که یه مدل می‌نویسید و این همه کد اضافی به پروژتون اضافه میکنید
❌مشکل اینجاست که خیلی وقت ها اصن Entity هاتون رو بدون لاجیک می‌نویسید و صرفن یه دیتااستراکچره و مدلتون هم کپی Entity تون هست !!!!
حتا خیلی از مواقعی که یه rich domain model داریم و Entity مون پر از لاجیک هست هم نیازی به مدل نیست، چه برسه به...
بعضی مواقع واقعن لازمه ولی خیلی وقت ها واقعن اضافه کاریه !!!
🔥کد اضافی نزنید
توی پروژه های موبایل که خیلی خیلی خیلی اضافیه ...
@purecoder_ir
❌اینکه توی پروژه هاتون هم Entity و هم Model درست میکنید خیلی وقت ها کار اضافیه و خیلی وقت ها همون Entity کفایت میکنه...
✅میخواین از دیتابیس استفاده کنید؟ همون Entity کافیه و میتونید از ORM برای تبدیل اسکیمای دیتابیس به Entity استفاده کنید.
✅میخواین Json رو به Entity تبدیل کنید و برعکس؟ یه mapper بنویسید که کارش تبدیل جیسون به Entity و برعکس هست .
چه لز‌ومی داره که یه مدل می‌نویسید و این همه کد اضافی به پروژتون اضافه میکنید
❌مشکل اینجاست که خیلی وقت ها اصن Entity هاتون رو بدون لاجیک می‌نویسید و صرفن یه دیتااستراکچره و مدلتون هم کپی Entity تون هست !!!!
حتا خیلی از مواقعی که یه rich domain model داریم و Entity مون پر از لاجیک هست هم نیازی به مدل نیست، چه برسه به...
بعضی مواقع واقعن لازمه ولی خیلی وقت ها واقعن اضافه کاریه !!!
🔥کد اضافی نزنید
توی پروژه های موبایل که خیلی خیلی خیلی اضافیه ...
@purecoder_ir
Forwarded from آموزش فلاتر و دارت
ما چیزی داریم به نام مدل OSI
بچه های شبکه توی دانشگاه یا کلاس های شبکه درموردش خوندن حتماً
از 7 لایه تشکیل شده
وقتی دارید با API کار میکنید دیتای که ارسال میکنید از این 7 لایه میگذره و به مقصد میرسه
وقتی دیتای ارسال میکنید مبدا از لایه هفتم این فرایند ارسال شروع میشه
ولی توی مقصد دریافت و پردازش داده از لایه اول شروع میشه تا برسه به لایه هفتم
لایه هفتم همون اپلیکیشن شما هستش
بچه های شبکه توی دانشگاه یا کلاس های شبکه درموردش خوندن حتماً
از 7 لایه تشکیل شده
وقتی دارید با API کار میکنید دیتای که ارسال میکنید از این 7 لایه میگذره و به مقصد میرسه
وقتی دیتای ارسال میکنید مبدا از لایه هفتم این فرایند ارسال شروع میشه
ولی توی مقصد دریافت و پردازش داده از لایه اول شروع میشه تا برسه به لایه هفتم
لایه هفتم همون اپلیکیشن شما هستش
Pure Coder
ما چیزی داریم به نام مدل OSI بچه های شبکه توی دانشگاه یا کلاس های شبکه درموردش خوندن حتماً از 7 لایه تشکیل شده وقتی دارید با API کار میکنید دیتای که ارسال میکنید از این 7 لایه میگذره و به مقصد میرسه وقتی دیتای ارسال میکنید مبدا از لایه هفتم این فرایند…
هر برنامه نویسی در حد مقدماتی باید اینارو بلد باشه ...
یاد بگیرید حتمن
در حدی که بدونید چیه
یاد بگیرید حتمن
در حدی که بدونید چیه
کدوم مورد از تست های زیر نسبت به بقیه قسمت بزرگتری از نرم افزار رو پوشش میده؟
Anonymous Quiz
35%
Unit test
41%
Integration test
24%
e2e test
کدوم مورد از تست های زیر نسبت به بقیه سرعت بالاتری دارن و سریعتر run میشن؟
Anonymous Quiz
80%
Unit test
8%
Integration test
12%
End to end test
کدوم مورد از تست های زیر نسبت به بقیه maintenance cost یا هزینه maintain کمتری دارن ؟
Anonymous Quiz
65%
Unit test
18%
Integration test
17%
End to end test
❓پترن
✅هر پترن یه problem ای رو بیان میکنه که بارها و بارها اتفاق افتاده و یه سولوشن براش ارائه میده .
❓آنتی پترن
✅هر آنتی پترن یه problem ای رو بیان میکنه که بارها و بارها اتفاق افتاده و یه سولوشن رو براش ارائه میده .
این سولوشن در ابتدا مناسب به نظر میرسه ولی خودش باعث problem های بیشتری میشه .
@purecoder_ir
✅هر پترن یه problem ای رو بیان میکنه که بارها و بارها اتفاق افتاده و یه سولوشن براش ارائه میده .
❓آنتی پترن
✅هر آنتی پترن یه problem ای رو بیان میکنه که بارها و بارها اتفاق افتاده و یه سولوشن رو براش ارائه میده .
این سولوشن در ابتدا مناسب به نظر میرسه ولی خودش باعث problem های بیشتری میشه .
@purecoder_ir
❓چالش
چرا توی معماری هایی مثل کلین میگیم که ورودی خروجی های Application Serivce ها یا usecase ها باید Data Transfer Object (دیتا استراکچر ) باشن و نباید Entity ها رو توی ورودی و خروجی سرویس ها استفاده کنیم. ولی در عین حال میتونیم Entity ها رو از طرف سرویس ها یا یوزکیس ها به Repository ها پاس بدیم و همچنین Repository ها هم میتونن Entity ریترن کنن؟
چرا ورودی و خروجی اونطرفشون باید دیتااستراکچر باشه و نباید Entity باشه ولی توی ارتباط با Repository ها مشکلی نداره Entity رد و بدل بشه؟
@purecoder_ir
چرا توی معماری هایی مثل کلین میگیم که ورودی خروجی های Application Serivce ها یا usecase ها باید Data Transfer Object (دیتا استراکچر ) باشن و نباید Entity ها رو توی ورودی و خروجی سرویس ها استفاده کنیم. ولی در عین حال میتونیم Entity ها رو از طرف سرویس ها یا یوزکیس ها به Repository ها پاس بدیم و همچنین Repository ها هم میتونن Entity ریترن کنن؟
چرا ورودی و خروجی اونطرفشون باید دیتااستراکچر باشه و نباید Entity باشه ولی توی ارتباط با Repository ها مشکلی نداره Entity رد و بدل بشه؟
@purecoder_ir