Pure Coder
786 subscribers
189 photos
30 videos
8 files
150 links
⭕️آدرس سایت:
https://purecoder.ir

⭕️گروه پرسش و پاسخ:
@purecoder_gp

⭕️پشتیبانی:
@PureCoder_support
@MohammadTaherri
Download Telegram
توی فلاتر به جای اینکه چندین استیت منجمنت رو یاد بگیرید, مفاهیمی مثل
☑️Reactive Programming (stream)
☑️Stateful & State lifecycle
☑️InheritedWidget(InhertiedModel , ...)
☑️BuildContext
☑️Element Lifecycle

رو یاد بگیرید که خودتون بتونید سولوشن های بهتر ازایه کنید.

وگرنه تا قیامت بشینید بگید که ریورپاد 1 میکروثانیه نسبت به بلاک سریعتره یا بلاک از گت ایکس سریعتره یا ... فایده ای نداره و دردی رو دوا نمیکنه😅😅😅

@purecoder_ir
نظر سنجی
فرض کنید یه پروژه فلاتری رو با یه استیت منجمنت خاص شروع کردید و تا حد زیادی پیش بردید، حالا وسط پروژه میخواید استیت منجمنت رو تغییر بدید...
آیا این کار زمان زیادی رو میبره؟ آیا اذیت کننده هست و به فوحش کاری میرسه؟ 😅😅
Anonymous Poll
78%
آره
22%
نه
نظر سنجی
آیا انتخاب استیت منجمنت، جزو تصمیمات حوزه ی معماری هست و به طرف معماری سوق داره یا نه؟
Anonymous Poll
60%
آره
40%
نه
بهترین حالت برای بیزینس لاجیک اینه که تیکه تیکه نشه و یا کاملن سمت سرور باشه و یا کاملن سمت فرانت.

بنابراین وقتی که بیزینس لاجیک رو سمت سرور میگذاریم, معماری های domain centric مثل clean یا onion یا hexagonal برای اپ موبایل اضافه کاریه.

اگه اپمون کلن بیزینس لاجیک خاصی نداشته باشه و در حد CRUD و data محور باشه, این معماری ها برای بکند هم اضافه کاریه.

@purecoder_ir
Pure Coder
نظر سنجی
فرض کنید یه پروژه فلاتری رو با یه استیت منجمنت خاص شروع کردید و تا حد زیادی پیش بردید، حالا وسط پروژه میخواید استیت منجمنت رو تغییر بدید...
آیا این کار زمان زیادی رو میبره؟ آیا اذیت کننده هست و به فوحش کاری میرسه؟ 😅😅
دوستانی که توی نظر سنجی اول (زمان بر بودن)، آره رو انتخاب کردن و توی نظر سنجی دوم (مرتبط بودن با معماری)، نه رو انتخاب کردن...دلیلشون رو زیر این پست کامنت کنن..
Pure Coder
نظر سنجی
فرض کنید یه پروژه فلاتری رو با یه استیت منجمنت خاص شروع کردید و تا حد زیادی پیش بردید، حالا وسط پروژه میخواید استیت منجمنت رو تغییر بدید...
آیا این کار زمان زیادی رو میبره؟ آیا اذیت کننده هست و به فوحش کاری میرسه؟ 😅😅
دوستانی که توی نظر سنجی اول (زمان بر بودن)، نه رو انتخاب کردن و توی نظر سنجی دوم (مرتبط بودن با معماری ) اره رو انتخاب کردن...دلیلشون رو زیر این پست کامنت کنن..
بخوایم استیت منجمنت رو تغییر بدیم پدرمون در میاد 😂 این اژ این😁

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

اصلن استفاده از معماری domain Centric توی آپ فلاتری، ۹۰ درصد مواقع ینی اینکه داری راهو اشتباه میری...(خیلی ارفاق کردم گفتم ۹۰😂)

ینی خشت اول رو کج گذاشتی و دیگه گار به جایی نمیرسه که بخوایم بقیه چیزها رو بررسی کنیم .

دارید کار اضافی میکنید بدون هیچ سودی...

@purecoder_ir
تقویت زبان انگلیسی از هر چیز دیگه ای برای پیشرفت ضروری تره...

برای تقویت زبان لغت حفظ نکنید، پادکست گوش کنید، برنامه کودک ببینید و ....

محتواهایی که براتون آسونه و خیلی باهاش دردسر ندارید رو بارها پشت سر هم گوش کنید

مثلن یه پادکست رو توی ۲ هفته ۵۰ بار گوش کنید

بعدش یه پادکست یه کوچولو سختر انتخاب کنید و دوباره ۵۰ بار گوش کنید

توی هر پادکست ۱۰ تا ۲۰ تا لغت و اصطلاح جدید به این شکل و به صورت کاربردی یاد میگیرید

برنامه کودک ها و سریال های ساده و روون رو هم میتونید به همین شکل، یعنی با تکرار بالا ببینید.

تکرار بالا شرط اصلیه

مغز با تکرار یه چیزی رو حالیش میشه

نگید یاد گرفتم میرم سر بعدی

تکرار در حدی که دیوونه بشید و بخواید گوشی رو پرت کنید توی دیوار 😁😁😁

@purecoder_ir
تست می‌نویسید؟
Anonymous Poll
16%
آره
84%
نه
Pure Coder
تست می‌نویسید؟
چون اکثرن اینجا موبایلی هستن اختصاصن در مورد موبایل میگم ...

آپ موبایلی که همه چیزش سمت سروره، یونیت تست زیادی نمیخواد و یونیت تست نوشتن براش نه میصرفه و نه سودی میرسونه (به جز جاهای اندک)، ولی integration رو باید بزنید

نیازی به e2e هم نیست ولی integration حتمن بزنید و یه view model خوب درست کنید که تا جایی که میشه لاجیکی توی UI قرار نگیره و به جز UI هر یوزکیس رو از سر تا ته integration بزنید و وب سرویس ها رو هم mock کنید

@purecoder_ir
Pure Coder
چون اکثرن اینجا موبایلی هستن اختصاصن در مورد موبایل میگم ... آپ موبایلی که همه چیزش سمت سروره، یونیت تست زیادی نمیخواد و یونیت تست نوشتن براش نه میصرفه و نه سودی میرسونه (به جز جاهای اندک)، ولی integration رو باید بزنید نیازی به e2e هم نیست ولی integration…
البته این نکته هم مهمه که تست نزدن توی موبایل معمولن ضرری به بیزینس نمیرسونه (معمولن، معمولن، معمولن) و نزدنش خیلی ریسکی نیست، اونجوری که توی بکند ریسکی هست و ممکنه دیتاسورس رو به ... بده و بیزینس رو فلج کنه .

به هر حال تست ها باید بر اساس ریسک نوشته بشن و شاید از این نظر بخواید توجیه کنید که وقتی ریسکی برای بیزینس نداره پس نزدیم هم نزدیم.

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

به هر حال نرم افزار همش trade off عه

@purecoder_ir
دو تا اصطلاح یاد بگیریم ؟😍

🍀پروژه ای که از صفر صفر شروعش کردید و هیچی کد وجود نداره و از اول قراره همه چی توسعه پیدا کنه بهش میگن Greenfield.

💩پروژه ای که قبلن کلی کد زده شده و احتمالن خراب کاری هم شده و همچین دلچسب نیست و قراره ادامش بدید بهش میگن Brownfield.

@purecoder_ir
Forwarded from Pure Coder (Mohammad Taheri)
🔗 سایت👇
https://purecoder.ir

🆔کانال👇
@purecoder_ir

🆔گروه👇
@purecoder_gp

🆔پشتیبانی👇
@PureCoder_support
Service Locator

امروزه service locator به عنوان یکی از آنتی پترن های dependency injection شناخته میشه و استفاده ازش به ویژه باعث وابستگی تست های مختلف به هم و سخت شدن فرایند تست میشه.

علاوه بر این مشکلات دیگه ای هم داره که در نهایت service locator رو به گزینه ی خوبی برای DI تبدیل نمیکنه.

@purecoder_ir
🔥silver bullet

یه اصطلاحی هست که به چیزی میگن در برابر هر مشکلی یه راه حلی جلوی پامون میگذاره و همه جا دستمون رو میگیره و هر جایی گیر کنیم میریم سراغش.

توی نرم افزار هیچ Silver Bullet ای نداریم و هر چیزی فقط توی یه اسکوپ خاصی کارایی داره و نه همه جا.

@purecoder_ir
کد کلین کدی هست که شبیه یه داستان خونده بشه.

همین.

کلمات قصار برای نام گذاری استفاده نکنید و شبیه به یه جمله ی روون انگلیسی خونده بشه، با رعایت دستور زبان.

فرقی نمیکنه اسم یه متد باشه یا یه condition که توی if قرار میگیره یا هر چیز دیگه ...

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

@purecoder_ir
نمونه بارز UX بد کارت خوان هایی هست که به نونوایی ها دادن.

یه باتن مثبت و منفی داره که باهاش تعداد نون رو مشخص میکنه و حالا اگه یه نفر بخواد ۳۰ تا نون بخرن باید ۳۰ بار مثبت رو بزنه .

یه آپشن مخفی شده اینه که اگه روی کانتر لانگ کلیک کنی یه کیبرد برات باز میشه و میتونی عدد دلخواهت رو بزنی.

چنین سیستم هایی usability پایینی دارن و کاربر باید کشفشون کنه و یوزکیس های مهم رو در دسترس و جلوی چشم کاربر قرار نمیدن.

@purecoder_ir
همیشه حضرت نوح در کار نیست😳😳

فیچرهایی که ولیو اضافه نمیکنن و پول نمیسازن و هم راستا با هدف بیزینس نیستن، دست و پای بیزینس رو میبندن.

@purecoder_ir
هر چقدر برنامه نویس بهتری بشی، سرعت کد زدنت کمتر میشه، حداقل در شروع کار، برنامه نویس های بد به انتها نمیرسن چون بخاطر سرعت زیاد به در و دیوار میخورن و شهید میشن.

@purecoder_ir
بعضی کدهارو که نگاه میکنی (توی کامیونیتی فلاتر ) ... یه تلاش نافرجام برای معماری میبینی:

+یه یوزکیس داره
+یه متد توی ریپوزیتوری داره دقیقن هم اسم یوزکیس
+یه کلاس به اسم دیتاسورس (یا ...) داره
+یه متد توی دیتاسورس داره اسمش شبیه همون قبلیا با اندکی تفاوت(یوزکیس و ریپو)
+برای هر کدوم اینا یه اینترفیس هم زده
+احتمالن یکی دو تا کلاس دیگه مثل api provider رو‌ این چیزا هم داره.

تهش یه خط کد توی اون دیتاسورسه زده و کل داستان با همون هندل شده و نهایتن یکی دو خط هم توی ریپو (مثلن ارور هندلینگی چیزی )

دلیل این همه پیچوندن لقمه دور سر چیه؟

برای یه تسک کوچولو باید این همه کلاس و ... نوشت 🤦‍♂

کدی که هیچ abstraction ای نداره و فکر میکنیم بخاطر اون اینترفیس ها abstraction اعمال کردیم 🤦‍♂

کدی که فهمش سخته چون برای یه کار خیلی کوچولو باید هی کلاس به کلاس و متد به متد توی کد بچرخی و بری پایین تا تهش به دو خط کد برسی که اون کار رو انجام دادن.

چه سودی داره؟
هیچ، همش ضرر.

@purecoder_ir