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

@thisisnabi_dev

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

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

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

@thisisnabi_dev

به به ببین کی اینجاست رو امروز فهمیدم که چه مزه ای داره 🔥
بزرگوار Jorge رو من می رفتم کنفرانس هاش رو توی یوتیوب می دیدم

خلاصه که آینده امیدوار کننده ای داریم برا خودمون

جیسیس کرایست میگن، چی میگن 🤠😅

کمی خوشحالم از بابت نظرسنجی ها، شاید اون 27 نفری که شرکت نکردن توی نظرسنجی ناراضی بودن، به هر حال خیر ایشالا.

این برای تبلیغ نیست و فانل فروش میت ها رو تا سایتش بالا نیاد بستیم 🔥
اما بعدا می تونید ویدیو ها رو با قیمت منصفانه ای تهیه کنید و باهاش پیش برید.

لاگ و اکسپشن هایی که بر می گردونید باید Human Readable و Machine Readable باشن.

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

@thisisnabi_dev

در پوزیشنی که انتخاب می کنید یا براش می جنگید همیشه به فردای روز پیروزی هم فکر کنید!

@thisisnabi_dev

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

اگر شما دیدید، ممنون میشم برای من دایرکت کنید.

وقتی لینک verify می فرستید از GUID استفاده نکنید. چراش رو فردا توی یه ویدیو فردا توضیح می دم براتون.

این مثال خوبی از hexagonal architecture هستش.
در اینجا یک ساختار ماژولار رو روی monolithic می بینیم.



@thisisnabi_dev

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

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

۲ کتاب زیر خوبن و الکی وقتتون رو هدر نمی دن.

Microservices Patterns
Building Microservices

#چی_خوندیم_و_چی_شد

با مفاهیمی که در سی شارپ مطرح هستن آشنا بشید :)

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

#سین_مثل_سم

کد باید document-less باشه :)
زبان های سطح بالا به وجود اومدن تا ما بتونیم خیلی راحت کد رو بخونیم + با استفاده از Unit Test ها و انواع دیگه تست ها می تونیم به ماهیت نیازمندی پی ببریم.
نظر شخصیم اینه که روی کد هیچ گونه مستندی نداشته باشیم اما فرایند های سیستم دیاگرام بیس باشن.

اگر تونستید فرایند ها رو diagram as code بنویسید که شما از بنده های صالح هستید.
داکیومنت ها خوبن، ولی زمان تغییر کد بیس معمولا آپدیت نمیشن و بعد از یه مدت یه جزیره متفاوت هستن برای خودشون.

@thisisnabi_dev

حضرت می فرماید:

نمی دونم در رابطه به 4+1 View Model Of Software Architecture چیزی خوندید یا نه، اما این مقاله اصلیش خیلی خفنه.

https://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf

#چی_خوندیم_و_چی_شد

@thisisnabi_dev

An Introduction to Software Architecture - January 1994 🤯

https://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf

#چی_خوندیم_و_چی_شد

@thisisnabi_dev

میگن با پولی که مردم بلوکه کردن برای خرید خودرو میشه کارخونه بنز رو یکجا خرید 😂😂

خلاصه که گفتم بهونه ای بشه تا یادی کنیم از اله زیبایی 😍
ایناس که می مونه، سی چه شارپی آخه :))

این تعداد از رفیق رو کسی نداره 😅

یک عاشقانه کلاسیک 😷

@thisisnabi_dev

آیا Code Coverage 100% شما رو به کمال می رسونه؟
خیر :)

بیشتر توضیح میدی؟
خیر :))

مریضی؟
آره :)))

@thisisnabi_dev

تست واقعا جذاب اما میتونه پیچیده و گمراه کننده باشه.

اگر تغییرات reversible باشه کمتر اینا پیش میاد.
ولی معمولا دیپلوی های ما اینطوری نیست.

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

اینطوری هاست که توی آمازون میانگین هر 10 ثانیه یه دیپلوی دارن :)