init in property
سادگی در ساخت داده‌های تغییرناپذیر

از نسخه‌ی ۹ به بعد، سی‌شارپ یه قابلیت خیلی تمیز معرفی کرد: init accessor
همون چیزی که باعث می‌شه بتونی شی‌ء‌هات رو فقط موقع ساخت مقداردهی کنی،
و بعدش دیگه کسی نتونه اشتباهی مقدارش رو تغییر بده 👇

قبل از init:

public class User
{
public string Name { get; set; }
}

var user = new User { Name = "Hamed" };
user.Name = "Ali"; // قابل تغییره ❌


ولی حالا با init:

public class User
{
public string Name { get; init; }
}

var user = new User { Name = "Hamed" };
// user.Name = "Ali"; // خطا می‌ده ✅


یعنی شی‌ءت immutable یا «تغییرناپذیر» می‌شه،
اما همچنان می‌تونی به‌راحتی با object initializer مقداردهی‌اش کنی — بدون نیاز به constructorهای طولانی.

📌 چرا مهمه؟
- خطاهای ناگهانی (به‌خاطر تغییر مقادیر) رو حذف می‌کنه.
- مخصوصاً برای Modelها و DTOها عالیه.
- وقتی با record استفاده بشه، یه ساختار تمیز و قابل‌اعتماد برای داده‌ها داری.

مثلاً:

public record Product
{
public string Name { get; init; }
public decimal Price { get; init; }
}

و بعد:

var product = new Product { Name = "Laptop", Price = 1000 };

تمیز، واضح و مطمئن.
همین ویژگی‌های کوچیک باعث می‌شن سی‌شارپ توی طراحی داده‌ها واقعاً لذّت‌بخش باشه ✨

Single Responsibility
ساده‌ترین اصل، سخت‌ترین در عمل

اصل اول از SOLID می‌گه:
یه کلاس فقط باید یه دلیل برای تغییر داشته باشه.
به ظاهر ساده‌ست، ولی توی عمل خیلیا همینو رعایت نمی‌کنن.
بذار با یه مثال نشون بدم 👇

❌ قبل از رعایت SRP:

public class ReportService
{
public string GenerateReport() { ... }
public void SaveToFile(string content) { ... }
public void SendEmail(string content) { ... }
}


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

✅ بعد از رعایت SRP:

public class ReportGenerator { public string Generate() { ... } }
public class FileSaver { public void Save(string content) { ... } }
public class EmailSender { public void Send(string content) { ... } }


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

📌 نکته:
اصل SRP یعنی هر کلاس فقط باید یه «مسئولیت» داشته باشه،
نه اینکه فقط یه «تابع» داشته باشه.

اصل Open/Closed
باز برای توسعه، بسته برای تغییر

یکی از زیباترین ایده‌ها در طراحی نرم‌افزار همینه:
«کد باید برای افزودن قابلیت جدید باز باشه، ولی برای تغییر در رفتار فعلی بسته.»

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

مثلاً فرض کن یه برنامه داری که پرداخت رو مدیریت می‌کنه 👇
❌ قبل از رعایت OCP:

public class PaymentService
{
public void Pay(string type)
{
if (type == "CreditCard") { ... }
else if (type == "Paypal") { ... }
}
}

هر بار روش جدید پرداخت اضافه بشه، باید همین کلاس رو تغییر بدی.

✅ بعد از رعایت OCP:

public interface IPaymentMethod
{
void Pay();
}

public class CreditCardPayment : IPaymentMethod
{
public void Pay() { ... }
}

public class PaypalPayment : IPaymentMethod
{
public void Pay() { ... }
}

public class PaymentService
{
public void Process(IPaymentMethod method)
{
method.Pay();
}
}

حالا برای اضافه کردن یه روش جدید، فقط کافیه یه کلاس جدید بسازی —
کدهای قدیمی اصلاً دست نمی‌خورن.

📌 نکته:
اصل Open/Closed باعث می‌شه پروژه‌ت با گذر زمان پایدار، قابل‌توسعه و تست‌پذیرتر بمونه.

⚙️ متد با کیلوکیلو اضافه‌وزن!

یه وقتایی توی بعضی پروژه‌ها، چند تا متد هستن که حتی دلت نمی‌خواد بازشون کنی.

چرا؟ چون چاقن!
هرچی اسکرول می‌کنی تموم نمی‌شن…
۲۰۰، ۳۰۰ خط فقط یه متد! 😵💫

🔴 مشکلش چیه؟

- خوندنش برای بقیه دولوپرها کابوسه
- حتی خود نویسنده‌ش بعد یه مدت نمی‌فهمه چی نوشته
- دیباگ کردنش زمان‌بر و اعصاب‌خوردکنه
- تغییر توش دادن یعنی دعوت به دردسر

👌 روش درست چیه؟
هر بخش از منطق رو بذار توی یه متد جدا، مخصوص خودش.

این‌طوری:
✅ کد تکراری نداری
✅ متدات کوتاه و تمیز می‌شن
✅ از اسم متدها (اگه نام‌گذاری خوب باشه) راحت می‌فهمی هرکدوم چی کار می‌کنن

به‌نظرم هر متد اگه بیشتر از ۱۰ تا ۱۵ خط بشه، وقتشه یه دستی بهش بکشی ✂️
(حتی اگه نظر شما یه کم فرق داره، ولی ۳۰۰ خط؟ اون دیگه فاجعه‌ست 😄)

فرقی نداره چی داری:
.NET یا Java یا Python
SOLID یا spaghetti code
MVC یا Clean Architecture

چه زبانی، چه معماری، چه دیزاین پترنی، چه…
در هر حال، متد چاق اذیتت می‌کنه!
پس از چاقی فاصله بگیرید 😁

شما چی فکر می‌کنید؟
متد چاق اذیت‌تون نمی‌کنه؟

🔗 LinkedIn Post

درود دوستان
این مدت اخیر احتمالا ریپو های منو دیدین و می‌دونین که چندتا کتاب برنامه نویسی رو به زبان شیرین فارسی ترجمه کردم.
مطمئناً گیت هاب جای مطالعه کتاب نیست و خسته کننده س برای این کار، پس به سرم زد که کار رو راحت کنم! ایده!
با گیت هاب پیج ترجمه ها رو آنلاین کنم که مطالعه راحت تر باشه.
و بووووومممم!
اینم سایت گیتاب ، Gitab

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

https://hheydarian.github.io/Gitab/

کتابخانه Carter در ASP .NET Core

📦 کتابخانه‌ی Carter یک رویکرد مینیمال و تمیز برای پیاده‌سازی میکروسرویس‌ها با Endpointهای Minimal API ارائه می‌دهد.

⚡️ به‌طور کلی، Carter رویکردی مینیمال برای طراحی APIهای مدرن در .NET دارد. در معماری‌های نوین نرم‌افزاری، به‌ویژه در ساختارهای میکروسرویسی، سادگی، ماژولار بودن و کاهش وابستگی بین اجزا از اصول کلیدی محسوب می‌شوند.

☯️ درنهایت، Carter با حذف نیاز به Controllerها و Attributeهای سنتی، از الگوی Minimal API الهام می‌گیرد و به توسعه‌دهنده اجازه می‌دهد تا Endpointها را در قالب ماژول‌های مجزا تعریف کند. این رویکرد، ضمن حفظ قابلیت تزریق وابستگی (DI) و سازگاری کامل با Middlewareها، باعث افزایش انسجام کد و سهولت نگهداری در مقیاس‌های بزرگ می‌شود.

😉 پ.ن: علاقه‌ی شخصی من به مینیمالیسم و پروژه‌های سبک با پرفورمنس بالا، باعث جذابیت برخی معماری‌ها و کتابخانه‌هایی مثل Carter شده است. همچنین نظریه‌های مرتبط با معماری میکروسرویس، که با مضمون «کوچک‌ترین سرویس کارآمد» شناخته می‌شوند، دلیل خوبی برای جایگزین کردن Minimal APIها به‌جای Controllerها هستند.

🖼 اسلاید تصاویر شامل تعریف سرویس Carter، یک مثال ساده و نمونه‌ای از پروژه‌ی شخصی من در زمینه‌ی ایجاد سفارش است.

🔗 Carter GitHub


🔗 LinkedIn Post

کدام زبان برنامه‌نویسی بیشترین پیچیدگی را تولید می‌کند؟ 💻

🔍 یک بررسی گسترده روی بیش از ۸ هزار پروژهٔ واقعی و ۱.۵ میلیارد خط کد نشان می‌دهد کدام زبان‌ها به‌طور متوسط کدهای پیچیده‌تری می‌سازند.

📏 معیار سنجش: پیچیدگی حلقوی (Cyclomatic Complexity) یعنی تعداد مسیرهای اجرایی مستقلی که یک تابع می‌تواند طی کند.

هرچه این عدد بالاتر باشد، فهم، نگهداری و تست‌پذیری کد با دشواری بیشتری همراه است.

🧩 نتایج کلیدی

💥 متلب (MATLAB)
بالاترین پیچیدگی را دارد؛ چون معمولاً توسط افرادی استفاده می‌شود که اصلاً برنامه‌نویس نیستند و کدها ساخت‌یافته نیستند.

⚙️ سی (C)
به‌دلیل مدیریت خطای دستی و شرط‌های متعدد، میانگین پیچیدگی بالاست.

🤯 جاوااسکریپت (JavaScript)
چرخه‌های تکرار سریع، تغییر دائم نیازمندی‌ها و آشفتگی در ساختار آن، پیچیدگی را بالا می‌برد. — در کل: به هیچ دردی نمی‌خورد! 😅

🐍 پایتون (Python)
خودشیرینی زیادی در سینتکس، به یک کد بی‌ساختار و غیرقابل‌پیش‌بینی تبدیل شده است! — به درد Code Boyها می‌خورد.

🐳 گو (Go)
مدیریت خطای مناسبی ندارد و چک‌های دستی زیادش باعث افزایش مسیرهای تصمیم‌گیری می‌شود — یک سرطان مهندسی! 😬

🧱 تایپ‌اسکریپت (TypeScript)
به‌واسطهٔ Type Safety بهتر، وضعیتش از جاوااسکریپت قابل‌تحمل‌تر است.

☕ جاوا (Java)
از لحاظ کاهش پیچیدگی بدک نیست، ولی قدیمی و خشک است؛ نسل دایناسورهای نرم‌افزار! 🦕

💎 سی‌شارپ (#C) — گل سرسبد زبان‌ها

✨ بهترین تعادل بین سادگی، قدرت و نظم
✨ کمترین پیچیدگی در تحلیل‌ها
✨ طراحی مدرن، استثناهای ساخت‌یافته، async/await خوانا، LINQ حرفه‌ای
✨ ابزارهای کامل برای کنترل کیفیت کد
✨ خواناتر، تمیزتر و پایدارتر از هر زبان دیگری

سی‌شارپ یعنی:
کد کمتر، منطق واضح‌تر، تیم آرام‌تر و محصول قابل‌اعتمادتر. 💪

🦀 راست (Rust)
در عمل هنوز مصرف تجاری گسترده ندارد. هرچقدر هم تمیز باشد، وقتی در پروژه‌های واقعی استفاده نمی‌شود، تأثیر چندانی ندارد.

🧠 جمع‌بندی
اگر دنبال زبانی هستید که:
✅ پیچیدگی را کنترل کند،
✅ در مقیاس سازمانی پایدار بماند،
✅ و ابزارهای حرفه‌ای برای کیفیت کد داشته باشد،

پاسخ روشن است:
💙 فقط سی‌شارپ (#C) — شاهکار واقعی مهندسی نرم‌افزار. 🚀

🔗 LinkedIn

مدیرعامل آمازون: «جایگزین کردن جونیورها با AI، احمقانه‌ترین حرفیه که شنیدم»

Matt Garman
مدیرعامل بخش AWS آمازون، توی یه مصاحبه گفت:

«من شنیدم کسانی می‌گویند با هوش مصنوعی می‌تونیم همهٔ کارکنان جونیور رو جایگزین کنیم.
من گفتم: این یکی از احمقانه‌ترین حرف‌هایی‌ست که تا به حال شنیدم.» ✅️

او ادامه داد:
🔹 کارکنان جونیور معمولاً کم‌هزینه‌ترین نیروها هستند.
🔹 بیشترین تمایل رو به استفاده از ابزارهای AI دارند.
🔹 اگر امروز بهشون فرصت یادگیری ندیم، در ۱۰ سال آینده هیچ نیروی آموزش‌دیده‌ای نخواهیم داشت.

💡 به نظرم این حرف خیلی مهمه، مخصوصاً حالا که بعضی شرکت‌ها با هیجان هوش مصنوعی دنبال حذف نقش‌های ورودی هستن.
واقعیت اینه که AI جایگزین کامل نیست؛ ابزاریه برای تقویت و رشد نیروها.

🔗 LinkedIn

۱۲ سال تجربه به‌عنوان توسعه‌دهنده‌ی .NET – در ۶۰ ثانیه

در این مسیر درس‌های زیادی آموخته‌ام.
برخی از آن‌ها دردناک بودند، اما بسیاری‌شان بی‌قیمت و ارزشمند.

اینجا ۴۰ نکته‌ی کلیدی را با شما به اشتراک می‌گذارم 👇

0. بهترین کدی که می‌نویسی، کدی است که اصلاً نوشته نمی‌شود.

1. برای نوشتن کد حقوق نمی‌گیری؛ برای حل مسئله حقوق می‌گیری.

2. همه‌چیز یک معامله است؛ هیچ ابزاری «بهترین» نیست.

3. کدی بنویس که توسعه‌دهندگان دیگر از کار کردن با آن لذت ببرند.

4. پیام‌های کامیت را معنادار و روشن بنویس.

5. اول کاری کن که درست کار کند، بعد زیبا.

6. زود منتشر کن، مداوم بهبود بده.

7. برآوردها هرگز دقیق نیستند.

8. بازآرایی (Refactor) را پیوسته و تدریجی انجام بده.

9. بازبینی کد فقط کیفیت را بالا نمی‌برد؛ تیم را هم رشد می‌دهد.

10. هرگز به ورودی کاربر اعتماد نکن.

11. دقیق لاگ بگیر، نه بیش از حد.

12. هر چیزی را که می‌شود، خودکارسازی کن.

13. پیچیدگی پروژه را می‌کُشد؛ بیش‌ازحد مهندسی نکن.

14. ریشه‌ی مشکل را حل کن، نه فقط نشانه‌ها را.

15. اول اندازه‌گیری کن، بعد بهینه‌سازی.

16. کوپلینگ را به حداقل برسان، انسجام را به حداکثر.

17. وابستگی‌های خارجی را کم و مدیریت‌شده نگه دار.

18. هیچ‌وقت اطلاعات حساس را به‌صورت سخت‌کد ذخیره نکن.

19. خطاها باید سریع و واضح شکست بخورند.

20. وضوح را به زرنگی ترجیح بده.

21. نام‌گذاری توصیفی را به توضیح در کامنت‌ها ترجیح بده.

22. ترکیب را به ارث‌بری ترجیح بده.

23. پیچیدگی مقیاس‌پذیر نیست؛ سادگی هست.

24. اصل «کمترین شگفتی» را رعایت کن.

25. کدهای بلااستفاده را بدون تردید حذف کن.

26. در واحدهای کوچک و قابل‌آزمایش فکر کن و کدنویسی کن.

27. در استانداردهای کدنویسی یکدست باش.

28. انتزاع باید پیچیدگی را پنهان کند، نه ایجاد.

29. صراحت را به ضمنی‌بودن ترجیح بده.

30. هر خط کد باید دلیل وجودی داشته باشد.

31. همیشه تلاش کن کسب‌وکار پشت کد را درک کنی.

32. Pull Requestها را کوچک و قابل‌مدیریت نگه دار.

33. از همان ابتدا روی CI/CD سرمایه‌گذاری کن.

34. APIهایی طراحی کن که استفاده‌ی درست از آن‌ها آسان و استفاده‌ی نادرست دشوار باشد.

35. «چرایی» را مستند کن، نه فقط «چیستی» را.

36. فراموش کن «روی سیستم من کار می‌کند».

37. از بدهی فنی آگاه باش؛ آن را تدریجی بازپرداخت کن.

38. بین اصل YAGNI («به آن نیاز پیدا نخواهی کرد») و طراحی هوشمندانه تعادل برقرار کن.

39. وقتی گیر کردی، کمک بخواه.

40. هرگز یادگیری و به‌چالش‌کشیدن فرضیاتت را متوقف نکن.

🔗 LinkedIn

اسم ها قبل از مهارت ها قضاوت میشوند

تا حالا فکر کردی
کد مدیریت‌نشده (Unmanaged Code) در NET. واقعاً یعنی چی؟

کد مدیریت‌شده (Managed Code) هر چیزی‌ست که تحت کنترل CLR اجرا می‌شود.

این کد از مدیریت خودکار حافظه توسط Garbage Collector، ایمنی نوع داده‌ها (Type Safety) و بررسی‌های امنیتی داخلی بهره‌مند است.

اما کد مدیریت‌نشده خارج از CLR اجرا می‌شود.

اینجا برنامه‌نویس باید حافظه را به‌صورت دستی مدیریت کند. این کار کنترل بیشتری می‌دهد و در بعضی موارد می‌تواند کارایی را بهبود دهد، اما در عین حال خطراتی مثل نشت حافظه، کرش کردن و آسیب‌پذیری‌های امنیتی را هم به همراه دارد.

زبان‌هایی مثل C و C++ کد مدیریت‌نشده تولید می‌کنند.

در .NET ممکن است با آن روبه‌رو شوی وقتی که با APIهای سیستمی کار می‌کنی که نیاز به دسترسی مستقیم به سخت‌افزار دارند، یا در برنامه‌های حساس به کارایی که مدیریت دستی حافظه اهمیت دارد، یا در کدهای قدیمی نوشته‌شده با C یا C++.

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

چون زمان را ذخیره می‌کند، مشکلات حافظه را کاهش می‌دهد و برنامه‌ها را ایمن‌تر می‌سازد.

با این حال، درک کد مدیریت‌نشده مهم است، مخصوصاً وقتی لازم باشد با سیستم‌های قدیمی یکپارچه شوی، نهایت کارایی را بگیری، یا مستقیماً با قابلیت‌های سطح پایین سیستم‌عامل کار کنی.

🔗 LinkedIn

سازنده‌ها مهم‌تر از چیزی هستند که فکر می‌کنید

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

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

🚀 انواع کلیدی سازنده‌ها:
✅ پیش‌فرض (Default)
✅ پارامتری (Parameterized)
✅ کپی (Copy)
✅ خصوصی (Private)
✅ ایستا (Static)
✅ اصلی (Primary)

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

پ.ن - در این سند مثال هایی از انواع سازنده ها رو می‌بینید.

🔗 LinkedIn

تا حالا به این فکر کردی چرا خیلی از تیم‌های نرم‌افزاری با اینکه می‌دونن یه روش بهتر وجود داره، باز هم سراغش نمی‌رن؟
جوابش تنبلی یا مدیریت ضعیف نیست.
اصل ماجرا یه سوگیری ذهنیه به اسم Hyperbolic Discounting؛ یعنی ترجیح دادن پاداش‌های کوتاه‌مدت به جای ارزش‌های بلندمدت.
وقتی فشار ددلاین یا مشتری هست، درد الان واقعی‌تره.
ولی درد بدهی فنی یه چیز مبهم و در آینده‌ست.
نتیجه؟ همه می‌گن «فعلاً برسونیم، بعداً درستش می‌کنیم» و اون «بعداً» هیچ‌وقت نمی‌رسه.
وقتی پاداش برای سرعت تعریف می‌کنی و نه کیفیت، نباید از نتیجه تعجب کنی.
شاید وقتشه یه بار برعکس فکر کنیم:
چطور می‌تونیم محیطی بسازیم که کار درست هم به اندازه‌ی کار سریع احساس درستی بده؟

🔗 LinkedIn