🔗 سایت👇
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

متاسفانه یکی از شروط استخدام بعضی از شرکت ها تسلط به معماری (کلین) این مدلی هست🤦‍♂

بعضن ترکیبی 😅(با بلاک و ...)

یکی‌از سوالاتی که برای خیلی از برنامه نویس ها پیش میاد اینه که مواردی مثل MVC و MVVM و ... معماری هستن یا نه؟

اگه معماری هستن، چرا؟

اگه نیستن، پس‌‌ چی هستن و ارتباطشون با معماری چیه؟

اصلن هدفشون چیه؟

خب،‌ نظر و دانسته های خودت رو زیر این پست به اشتراک بگذار🙏

هر چی توضیح بیشتر، بهتر.

پ.ن: از chat gpt اگه میپرسید، اینجا کپی نکنید😁😁 بفهمید چی گفته و بعد اینجا بگید

@purecoder_ir

کسایی که عادت به نت برداری حساب شده دارن توی این امر موفق ترن.

من خودم متاسفانه عادت به این کار ندارم.

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

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

چیز هایی که روی کاغذ هستن بیشتر اژ چیزهایی که توی سرمون هستن قابل اعتمادن.

@purecoder_ir

🔥چالش

🟢یه مسابقه ی فوتبال که توی مرحله ی حذفی یه cup مثل چمپیونزلیگ برگزار میشه رو در نظر بگیر.

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

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

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

❓این مسابقه رو با کد مدل کن...
❓یکی از behavior هایی که لازم داریم اینه که تیم برنده مشخص بشه
❓و behavior دیگه ای که لازم داریم گرفتن امتیاز تیم برنده هست.(تعداد گل هایی که زده)

🟢سوال یا ابهامی داشتی توی کامنت...
🟢فقط چنتا کلاس قراره بنویسی و احتمالن یونیت تست...
❌ استیت منجمنت و کدهای فلاتری و ... ننویس.
❌ یو ای لازم نیست
🟢هر زبان برنامه نویسی باشه اوکیه.

🔥دوستانی که بدنبال پروژه نمونه تست و معماری و ...بودن اینو انجام بدن و از اینجا شروع کنن.

@purecoder_ir

سعی کنید وقتی که توی مسیر شغلیتون به جایی میرسید، همون مدلی با آدم ها برخورد کنید که وقتی هیچی نبودید برخورد می‌کردید...

شق القمری اتفاق نیوفتاده، اون آدم ها هم دیر یا زود میرسن بهت و ویییییییژژژ از کنارت رد میشن...

@purecoder_ir

وقتی راننده اسنپی و خودت خبر نداری 😳😳

اول دبستان که بودیم به ما املا میگفتن...

بعضی بچه ها وقتی یه صفحه رو پر میکردن، میگفتن خانم اجازه، خانم اجازه، ما صفحمون تموم شد، چکار کنیم ؟

بعد که خانم معلم بهشون میگفت برو صفحه ی بعدی، اونا هم میرفتن ادامشو توی صفحه بعدی مینوشتن‌.

اگه برای نوشتن تیکه تیکه کدتون، تست بنویسم یا نه؟ کدمو فلان جا ریفکتور کنم یا نه؟ و... میرید از مدیرتون اجازه میگیرید، شما هم شبیه همون بچه کوچولوعه هستید🤦‍♂

@purecoder_ir

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

روس ها راه حل ساده تری داشتند، آنها از مداد استفاده کردند.

نتیجه: برای حل مشكلاتتان روی خود مشكل تمركز كنید (مشكل نوشتن در فضا) نه روی روش های حل مشكل (نوشتن با خودكار در فضا)

پ.ن: مهم نیست که داستان حقیقت داره یا نه.

@purecoder_ir

.
.
@purecoder_ir

وقتی که از جاوا میومدیم سمت فلاتر، یکی از خوبی های غیر قابل بحث فلاتر این بود که نیاز نبود کد xml بزنیم و یه زبان declarative بهمون میداد که کار رو خیلی قشنگ می‌کرد.

واقعن اندروید کد زدن با جاوا وحشتناک بود و فلاتر در مقابلش بدون چون و چرا مثل یه فرشته بود.

ولی الان با jetpack compose میتونیم همون زبان declarative رو داشته باشیم و مجبور نباشیم مثل قبل xml بزنیم و احتمالن خیلی کارهای وحشتناکی که اون موقع مجبور بودیم انجام بدیم...

اون طرف هم swiftUi قابلیت های مشابهی رو میده..

من اگه همین الان میخواستم انتخاب کنم, حتمن انتخاب صد در صدی و بدون بازگشتم فلاتر نبود و گزینه های دیگه رو هم به شدت بررسی میکردم .

امکانات نیتیو رو هم باید در نظر گرفت.
به هر حال فلاتر بدون رفت و آمد به نیتیو نیست!!!!

@purecoder_ir

بعضی مواقع نباید پشت سر هم کار کرد و گفت keep working, keep working, keep working...

ینی توی بدترین شرایط هم میگن ادامه بده..

شاید داریم مسیر اشتباهی رو میریم، باید یکم فرصت بدیم تا ذهن آروم بگیره و بتونه تصمیم بهتر بگیره.

اگه مسیر اشتباه بود، ادامه بدیم که چی بشه..

بعضی مواقع هیچ کاری نکردن، بهترین کاره, وگرنه بیشتر فرو میری

@purecoder_ir

تخفیف 40 درصدی دوره ی فلاتر به مدت یک هفته..

https://purecoder.ir/course/flutterys-journey/

برای شرکت در دوره به ایدی زیر پیام بدید:
@purecoder_support