یادآوری کوتاه به شرکت‌هایی که بر اساس سبز بودن نمودار مشارکت GitHub استخدام می‌کنند:

- همه‌ی توسعه‌دهندگان در پروژه‌های متن‌باز مشارکت نمی‌کنند.
- همه‌ی توسعه‌دهندگان آخر هفته‌هایشان را صرف پوش کردن کد در GitHub نمی‌کنند.
- همه‌ی توسعه‌دهندگان بعد از کار، ساعت‌ها وقت برای ساخت پروژه‌های جانبی ندارند.
- همه‌ی توسعه‌دهندگان نمی‌توانند یا نمی‌خواهند بیرون از شغلشان کدنویسی کنند.
- همه‌ی توسعه‌دهندگان باور ندارند که «خانه‌های سبز بیشتر» به معنای استعداد بیشتر است.

و واقعاً هم اشکالی ندارد.

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

چون کدنویسی در محیط کار خودش درس‌های زیادی دارد:

1. نتایجی که ارائه می‌دهی، مسیر رشد، نفوذ و اعتمادی را شکل می‌دهد که نزد تیم، ذی‌نفعان و مشتریان می‌سازی.
2. بازخورد سریع می‌گیری. همکارانت در موفقیت تو سرمایه‌گذاری کرده‌اند و مسائلی که حل می‌کنی اهمیت واقعی دارند—روی مشتریان اثر می‌گذارند، نه فقط روی تئوری.

پروژه‌های جانبی می‌توانند فوق‌العاده باشند برای کشف فناوری‌های جدید یا ارضای خلاقیت.
اما نگذار کسی قانعت کند که آن‌ها برای اثبات ارزش تو به‌عنوان توسعه‌دهنده ضروری‌اند.

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

مسیر شغلی تو با رنگ نمودار GitHub تعریف نمی‌شود.
بلکه با اثری تعریف می‌شود که در جایی که واقعاً اهمیت دارد خلق می‌کنی.

🔗 LinkedIn Post

چرا مفاهیم پایه مهم‌اند

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

بسیاری از ما یک‌بار این اشتباه را کرده‌ایم؛ مستقیم سراغ Clean Architecture و DDD رفتیم، بدون آن‌که ابتدا پایه‌ها را درست بلد باشیم. در یک پروژه‌ی ASP .NET Core، تنها به خاطر ندانستن درست async/await یا Dependency Injection، ساعت‌ها زمان از دست رفته است. در ظاهر مشکل از معماری به نظر می‌رسد، اما ریشه‌ی اصلی در ضعف مفاهیم پایه بوده است.

چرا این اتفاق رخ می‌دهد؟
وقتی زبان C# را خوب بلد نباشیم، هر خطا می‌تواند ما را متوقف کند.
وقتی اصول شی‌گرایی یا SOLID را درک نکرده باشیم، پروژه‌ای که کمی بزرگ می‌شود به‌سرعت به کدهای به‌هم‌ریخته تبدیل می‌شود.
وقتی ساختار اصلی .NET را نشناسیم، معماری‌های پیشرفته بیشتر شبیه معما به نظر می‌رسند تا راه‌حل.

راه‌حل
راه‌حل ساده ولی حیاتی این است که یک قدم به عقب برگردیم و روی پایه‌ها تمرکز کنیم. حوزه‌هایی مانند:
- ویژگی‌های C# مثل generics، delegates، LINQ، async/await
- اصول شی‌گرایی و SOLID
- مبانی .NET Core مثل middleware و DI
- ساختمان داده‌ها و الگوریتم‌ها
- مدیریت خطا و دیباگ

نتیجه
وقتی مفاهیم پایه تقویت شوند، معماری‌های مدرن هم معنای واقعی خود را پیدا می‌کنند. جداسازی لایه‌ها در Clean Architecture دیگر یک شعار نیست، بلکه نیاز طبیعی کد است. مدل دامنه در DDD دیگر پیچیده به نظر نمی‌رسد، چون می‌دانیم بر چه اساسی ارزشمند است.

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

🔗 LinkedIn Post

تفاوت کسب‌وکار (𝐁𝐮𝐬𝐢𝐧𝐞𝐬𝐬) و محصول (𝐏𝐫𝐨𝐝𝐮𝐜𝐭)

«بارها در سازمان‌های مختلف دیده‌ام که کسب‌وکار (Business) و محصول (Product) با هم اشتباه گرفته می‌شن.
این اشتباه ساده می‌تونه منجر به شکست پروژه‌های بزرگ بشه.

🔹 کسب‌وکار (Business) یعنی:
- ما برای چه کسی کار می‌کنیم؟ (مشتری)
- چه مشکلی رو حل می‌کنیم؟ (ارزش پیشنهادی)
- چطور پول درمی‌آوریم؟ (مدل درآمدی)
- فرآیندها و عملیات کلان سازمان

🔹 محصول (Product) یعنی:
- ابزاری برای تحقق بخشی از ارزش پیشنهادی
- ویژگی‌ها و تجربه کاربری
- چرخه توسعه و بهبود مستمر
- بخشی از استراتژی کسب‌وکار، نه همه آن

❌ وقتی سازمان‌ها این دو مفهوم رو قاطی می‌کنن:
- تیم‌ها محصول رو صرفاً به‌عنوان «کسب‌وکار» می‌بینن → در نتیجه نوآوری متوقف می‌شه.
- مدیریت، محصول رو فقط یک فیچر تکنولوژیک می‌دونه → ارزش واقعی به مشتری منتقل نمی‌شه.

✅ تجربه من نشون داده که موفق‌ترین سازمان‌ها این دو مفهوم رو درست می‌فهمن:
- Business رو مثل نقشه راه می‌بینن.
- Product رو مثل وسیله‌ای برای رسیدن به مقصد.

📌 پس:
- کسب‌وکار = «چرا و چگونه ارزش ایجاد می‌کنیم»
- محصول = «چه ابزاری می‌سازیم تا اون ارزش منتقل بشه»

🔗 LinkedIn Post

دوره چطور درست و مؤثر صحبت کنیم؟
دانشگاه MIT | زیرنویس فارسی

🔗 یوتیوب

🔗 آپارات( نیم بها )

یکی از دلایلی که ASP .NET Core محبوب شده، سرعت و بهینه بودنش است.
ولی اگر درست ازش استفاده نکنیم، حتی قوی‌ترین فریم‌ورک‌ها هم می‌تونن کند بشن.

اینجا چند نکته مهم برای بهبود Performance در پروژه‌های ASP .NET Core رو می‌نویسم:

🔹 1. Caching
داده‌هایی که زیاد تغییر نمی‌کنن (مثل لیست محصولات یا تنظیمات) رو cache کنید.
می‌تونید از MemoryCache یا DistributedCache (مثل Redis) استفاده کنید.

🔹 2. Asynchronous Programming
از async/await استفاده کنید تا منابع بلاک نشن، مخصوصاً برای I/O operations مثل کار با دیتابیس یا API.

🔹 3. Logging سبک
لاگ‌گیری خیلی مهمه، ولی اگر درست مدیریت نشه می‌تونه پروژه رو کند کنه.
ابزارهایی مثل Serilog یا Seq کمک می‌کنن لاگ‌ها بهینه و قابل جست‌وجو باشن.

🔹 4. Dependency Injection درست
در ASP .NET Core همه‌چیز با DI کار می‌کنه. مراقب باشیم سرویس‌هایی که باید Scoped یا Transient باشن رو اشتباهاً Singleton تعریف نکنیم.

🔹 5. Minimize Database Calls
به‌جای چندین کوئری کوچک، از Eager Loading یا Stored Procedure استفاده کنید.
Lazy Loading بیش از حد می‌تونه پرفورمنس رو خراب کنه.

🔹 6. Response Compression
فعال کردن Gzip یا Brotli برای کاهش حجم responseها در API.

❓شما چه ترفندهایی برای افزایش Performance در پروژه‌های ASP .NET Core استفاده کردید؟

🔗 LinkedIn Post

معماری وب‌اپلیکیشن‌های مدرن با ASP .NET Core و Azure

مایکروسافت یک منبع ارزشمند و رایگان منتشر کرده که برای هر توسعه‌دهنده و معمار نرم‌افزار می‌تواند نقش یک راهنمای عملی را ایفا کند:

🔗 Architecting Modern Web Applications with ASP .NET Core and Azure

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

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

به‌عنوان کسی که سال‌ها با ASP .NET Core کار کرده‌ام، می‌توانم بگویم این کتاب نه‌تنها برای تازه‌کارها بلکه برای افراد باتجربه هم پر از نکات کاربردی و الهام‌بخش است. پیشنهاد می‌کنم حتماً نگاهی به آن بیندازید، چون خواندنش مثل یک جلسه مشاوره رایگان با تیم معماری نرم‌افزار مایکروسافت است. 🚀

🔗 LinkedIn Post

پنج مهارت کلیدی و تعیین کننده در آینده کاری هر فرد - مخصوصا در کارهای تیمی

🔗 لینک

۵ مهارت نرم که به برنامه‌نویس‌ها کمک می‌کنه توی تیم بدرخشن…

کد همیشه مهمه،
ولی واقعیت اینه که وقتی توی یه تیم کار می‌کنیم، این ویژگی‌ها هستن که حسابی به کارمون میاد و فرق ایجاد می‌کنه:

1️⃣ ذهن باز و یادگیری مداوم
هر تغییری لزوماً ترسناک نیست، می‌تونه یه فرصت برای رشد باشه.

2️⃣ بازخورد دادن و گرفتن
نه فقط نقد کردن بقیه، بلکه خودمونم نقد بپذیریم و پیشنهاد بدیم تا تیم جلو بره.

3️⃣ حل مسئلهٔ خلاقانه
فقط اینکه کار می‌کنه کافی نیست، بیایم ببینیم چطوری بهتر کار می‌کنه!

4️⃣ انعطاف‌پذیری
پروژه‌ها عوض می‌شن، برنامه‌ها تغییر می‌کنه… کسی که منعطف باشه قهرمان تیمه :)

5️⃣ رهبری بدون عنوان
مسئولیت‌پذیری حتی وقتی مدیر نیستی، اعتماد می‌سازه و تیمو جلو می‌بره.

واقعاً این مهارت‌ها مثل روغن برای چرخ‌دنده‌های یه تیمه.

🔗 LinkedIn Post

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 باعث می‌شه پروژه‌ت با گذر زمان پایدار، قابل‌توسعه و تست‌پذیرتر بمونه.