کد باید 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 ثانیه یه دیپلوی دارن :)

عموما می تونیم بدون هیچ ساختاری به تمام functional requirement های داخل یک نرم افزار برسیم.

برای رسیدن به مواردی چون maintainability, changability , testability, agility, avialibility و غیره س که ما میایم و معماری و ساختار ها رو به نرم افزار تحمیل می کنیم.

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

@thisisnabi_dev

توپ نیست که هرچقدر تکه هاش بیشتر باشه خوب تره!
باندری سرویس ها رو پیدا کردن یکی از سخت ترین کارهای داخل سیستم های سرویس گراست.
مابقیش همه نمونه کد آماده داره :)

@thisisnabi_dev

امیدوارم که مفید بوده باشه

1️⃣ logging
https://lnkd.in/dhbZNitt

2️⃣ API Design Rules
https://lnkd.in/d4w-ziXe

3️⃣ Model Binding
https://lnkd.in/d-97nASh

4️⃣ Tactical side in DDD
https://lnkd.in/dnei-Vwn

5️⃣ Software Resilience
https://lnkd.in/dEkFt8_R

6️⃣ HTTP Protocol
https://lnkd.in/dVMhqZ-C

7️⃣ Action Filters
https://lnkd.in/dAVeY7Cg

8️⃣ Object Pooling
https://lnkd.in/duZaSHtw

9️⃣ MondoDb in .NET
https://lnkd.in/dHvUttYM

@thisisnabi_dev

اگر دوست داشتید این پست رو ببینید و بعد ادامه این متن رو بخونید.

https://www.linkedin.com/posts/aminrousta_aepaeuaepahyaesabraeqaepaecahyaet-activity-7234976012361437184-wjdO?utm_source=share&utm_medium=member_android

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

من روانی به این فکر میکنم که کاپلینگ با ۱۴ سرویس؟
چه خبره!
بعضی موقع ها نیاز نیست اینقدر سرویس ها شکسته بشن، هزینه Integration رو همیشه ما میس میکنیم.

45 ساعت حرف زدیم :/

البته هنوز 110 ساعتش مونده 😂

ASP.NET Core Roadmap [Persian]| Part 11:
APIs Client and Communications

✔️ Channels:
@thisisnabi_dev | @Moien_Tajik

〰️〰️〰️

[ Roadmap URL ]:
https://github.com/MoienTajik/AspNetCore-Developer-Roadmap

https://github.com/MoienTajik/AspNetCore-Developer-Roadmap-Slides

ASP.NET Core Roadmap [Persian]| Part 12:
Real-time Applications

✔️ Channels:
@thisisnabi_dev | @Moien_Tajik

〰️〰️〰️

[ Roadmap URL ]:
https://github.com/MoienTajik/AspNetCore-Developer-Roadmap

https://github.com/MoienTajik/AspNetCore-Developer-Roadmap-Slides

ASP.NET Core Roadmap [Persian]| Part 13:
Object Mapping

✔️ Channels:
@thisisnabi_dev | @Moien_Tajik

〰️〰️〰️

[ Roadmap URL ]:
https://github.com/MoienTajik/AspNetCore-Developer-Roadmap

https://github.com/MoienTajik/AspNetCore-Developer-Roadmap-Slides

یه بزرگی می فرماید Domain Model شما Date Model نیست و این جدا سازی سراغازی برای دنبال کردن persistence ignorance هست.

تستی که دارید می نویسید باید maximum value و minimum cost رو داشته باشه.
وگرنه نمی ارزه به این همه زحمت.

@thisisnabi_dev

نوع وابستگی هاست که در Unit Test مشخص می کنه ما از test double ها باید استفاده بکنیم یا خیر!
تعداد وابستگی ها هم می تونه تعین کننده باشه تا از Unit Test استفاده کنیم یا Integration Test رو بپذیریم، چون به هر حال هزینه ای که برای نوشتن تست در نظر میگیریم باید مشخص باشه.

در هر صورت، تست رو بهتره با این دید بنویسیم که یه گارد و محافظ به دور Production Code باشه :)

موضوع فلسفی شد، ولی خب واقعیت هایی هست که خوبه بهفمیمشون.