یکی از دلایلی که 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
ولی اگر درست ازش استفاده نکنیم، حتی قویترین فریمورکها هم میتونن کند بشن.
اینجا چند نکته مهم برای بهبود 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
👍4🔥2
معماری وباپلیکیشنهای مدرن با ASP .NET Core و Azure
مایکروسافت یک منبع ارزشمند و رایگان منتشر کرده که برای هر توسعهدهنده و معمار نرمافزار میتواند نقش یک راهنمای عملی را ایفا کند:
🔗 Architecting Modern Web Applications with ASP .NET Core and Azure
این کتاب تنها یک مرور تئوریک نیست؛ بلکه شما را گامبهگام در مسیر طراحی و معماری سیستمهای مدرن همراهی میکند. از اصول طراحی دامنهمحور (DDD) گرفته تا الگوهای لایهای، امنیت، کار با پایگاه داده، و حتی چالشهای استقرار در فضای ابری Azure، همه با زبانی روشن و سازمانیافته توضیح داده شدهاند.
✅ ارزش اصلی این کتاب در این است که دیدی جامع از معماری و بهترین شیوههای ساخت اپلیکیشنهای سازمانی ارائه میدهد. این یعنی حتی اگر شما بیشتر در سطح تصمیمگیری و طراحی فعالیت میکنید (و کمتر درگیر جزئیات پیادهسازی هستید)، باز هم این کتاب میتواند برایتان یک نقشه راه مطمئن باشد.
بهعنوان کسی که سالها با ASP .NET Core کار کردهام، میتوانم بگویم این کتاب نهتنها برای تازهکارها بلکه برای افراد باتجربه هم پر از نکات کاربردی و الهامبخش است. پیشنهاد میکنم حتماً نگاهی به آن بیندازید، چون خواندنش مثل یک جلسه مشاوره رایگان با تیم معماری نرمافزار مایکروسافت است. 🚀
🔗 LinkedIn Post
مایکروسافت یک منبع ارزشمند و رایگان منتشر کرده که برای هر توسعهدهنده و معمار نرمافزار میتواند نقش یک راهنمای عملی را ایفا کند:
🔗 Architecting Modern Web Applications with ASP .NET Core and Azure
این کتاب تنها یک مرور تئوریک نیست؛ بلکه شما را گامبهگام در مسیر طراحی و معماری سیستمهای مدرن همراهی میکند. از اصول طراحی دامنهمحور (DDD) گرفته تا الگوهای لایهای، امنیت، کار با پایگاه داده، و حتی چالشهای استقرار در فضای ابری Azure، همه با زبانی روشن و سازمانیافته توضیح داده شدهاند.
✅ ارزش اصلی این کتاب در این است که دیدی جامع از معماری و بهترین شیوههای ساخت اپلیکیشنهای سازمانی ارائه میدهد. این یعنی حتی اگر شما بیشتر در سطح تصمیمگیری و طراحی فعالیت میکنید (و کمتر درگیر جزئیات پیادهسازی هستید)، باز هم این کتاب میتواند برایتان یک نقشه راه مطمئن باشد.
بهعنوان کسی که سالها با ASP .NET Core کار کردهام، میتوانم بگویم این کتاب نهتنها برای تازهکارها بلکه برای افراد باتجربه هم پر از نکات کاربردی و الهامبخش است. پیشنهاد میکنم حتماً نگاهی به آن بیندازید، چون خواندنش مثل یک جلسه مشاوره رایگان با تیم معماری نرمافزار مایکروسافت است. 🚀
🔗 LinkedIn Post
👍2❤1
۵ مهارت نرم که به برنامهنویسها کمک میکنه توی تیم بدرخشن…
کد همیشه مهمه،
ولی واقعیت اینه که وقتی توی یه تیم کار میکنیم، این ویژگیها هستن که حسابی به کارمون میاد و فرق ایجاد میکنه:
1️⃣ ذهن باز و یادگیری مداوم
هر تغییری لزوماً ترسناک نیست، میتونه یه فرصت برای رشد باشه.
2️⃣ بازخورد دادن و گرفتن
نه فقط نقد کردن بقیه، بلکه خودمونم نقد بپذیریم و پیشنهاد بدیم تا تیم جلو بره.
3️⃣ حل مسئلهٔ خلاقانه
فقط اینکه کار میکنه کافی نیست، بیایم ببینیم چطوری بهتر کار میکنه!
4️⃣ انعطافپذیری
پروژهها عوض میشن، برنامهها تغییر میکنه… کسی که منعطف باشه قهرمان تیمه :)
5️⃣ رهبری بدون عنوان
مسئولیتپذیری حتی وقتی مدیر نیستی، اعتماد میسازه و تیمو جلو میبره.
واقعاً این مهارتها مثل روغن برای چرخدندههای یه تیمه.
🔗 LinkedIn Post
کد همیشه مهمه،
ولی واقعیت اینه که وقتی توی یه تیم کار میکنیم، این ویژگیها هستن که حسابی به کارمون میاد و فرق ایجاد میکنه:
1️⃣ ذهن باز و یادگیری مداوم
هر تغییری لزوماً ترسناک نیست، میتونه یه فرصت برای رشد باشه.
2️⃣ بازخورد دادن و گرفتن
نه فقط نقد کردن بقیه، بلکه خودمونم نقد بپذیریم و پیشنهاد بدیم تا تیم جلو بره.
3️⃣ حل مسئلهٔ خلاقانه
فقط اینکه کار میکنه کافی نیست، بیایم ببینیم چطوری بهتر کار میکنه!
4️⃣ انعطافپذیری
پروژهها عوض میشن، برنامهها تغییر میکنه… کسی که منعطف باشه قهرمان تیمه :)
5️⃣ رهبری بدون عنوان
مسئولیتپذیری حتی وقتی مدیر نیستی، اعتماد میسازه و تیمو جلو میبره.
واقعاً این مهارتها مثل روغن برای چرخدندههای یه تیمه.
🔗 LinkedIn Post
👍3👾1
net-developer-resources (2).pdf
4.3 MB
بیش از ۶۵۰ منبع منتخب برای یادگیری حرفهای C#، .NET، ASP .NET Core، EF Core و میکروسرویسها جمعآوری شده.
این منابع به توسعه دهندهها کمک میکنه با دانش هدفمند، سطح خودشون رو ارتقا بدن.
این منابع به توسعه دهندهها کمک میکنه با دانش هدفمند، سطح خودشون رو ارتقا بدن.
6🔥4❤🔥1❤1🆒1
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 };
تمیز، واضح و مطمئن.
همین ویژگیهای کوچیک باعث میشن سیشارپ توی طراحی دادهها واقعاً لذّتبخش باشه ✨
سادگی در ساخت دادههای تغییرناپذیر
از نسخهی ۹ به بعد، سیشارپ یه قابلیت خیلی تمیز معرفی کرد: 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 };
تمیز، واضح و مطمئن.
همین ویژگیهای کوچیک باعث میشن سیشارپ توی طراحی دادهها واقعاً لذّتبخش باشه ✨
👍4❤3
چرا یه برنامهنویس خوب فقط با زبان برنامهنویسی تعریف نمیشه
خیلیا فکر میکنن «تسلط به یه زبان» یعنی حرفهای بودن.
ولی واقعیت اینه که زبان، فقط ابزار ماست.
چیزی که تفاوت ایجاد میکنه، طرز فکر پشت کده.
برنامهنویس خوب فقط کد تمیز نمینویسه؛
بلکه مسئله رو درست میفهمه، ارتباط میسازه، و توی تیم رشد میکنه.
چیزایی مثل:
فهم درست مسئله قبل از نوشتن کد
ارتباط مؤثر با تیم و فهمیدن دید بقیه
یادگیری مداوم و بهروز نگهداشتن ذهن
تفکر سیستمی و دیدن پروژه بهصورت کلنگر
کد خوب مهمه، اما پشت هر کد تمیز، یه ذهن منظم و بالغ وجود داره.
و اون چیزیه که یه developer واقعی رو میسازه.
@dndevelop
خیلیا فکر میکنن «تسلط به یه زبان» یعنی حرفهای بودن.
ولی واقعیت اینه که زبان، فقط ابزار ماست.
چیزی که تفاوت ایجاد میکنه، طرز فکر پشت کده.
برنامهنویس خوب فقط کد تمیز نمینویسه؛
بلکه مسئله رو درست میفهمه، ارتباط میسازه، و توی تیم رشد میکنه.
چیزایی مثل:
فهم درست مسئله قبل از نوشتن کد
ارتباط مؤثر با تیم و فهمیدن دید بقیه
یادگیری مداوم و بهروز نگهداشتن ذهن
تفکر سیستمی و دیدن پروژه بهصورت کلنگر
کد خوب مهمه، اما پشت هر کد تمیز، یه ذهن منظم و بالغ وجود داره.
و اون چیزیه که یه developer واقعی رو میسازه.
@dndevelop
❤3👍2
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 یعنی هر کلاس فقط باید یه «مسئولیت» داشته باشه،
نه اینکه فقط یه «تابع» داشته باشه.
سادهترین اصل، سختترین در عمل
اصل اول از 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 یعنی هر کلاس فقط باید یه «مسئولیت» داشته باشه،
نه اینکه فقط یه «تابع» داشته باشه.
👍4
اصل 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 باعث میشه پروژهت با گذر زمان پایدار، قابلتوسعه و تستپذیرتر بمونه.
باز برای توسعه، بسته برای تغییر
یکی از زیباترین ایدهها در طراحی نرمافزار همینه:
«کد باید برای افزودن قابلیت جدید باز باشه، ولی برای تغییر در رفتار فعلی بسته.»
به زبان ساده یعنی:
وقتی بخوای رفتار جدیدی به برنامه اضافه کنی، نباید بری سراغ ویرایش کلاسهای موجود —
باید بتونی با ارثبری یا پیادهسازی جدید اون رفتار رو گسترش بدی.
مثلاً فرض کن یه برنامه داری که پرداخت رو مدیریت میکنه 👇
❌ قبل از رعایت 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 باعث میشه پروژهت با گذر زمان پایدار، قابلتوسعه و تستپذیرتر بمونه.
❤5👍3
⚙️ متد با کیلوکیلو اضافهوزن!
یه وقتایی توی بعضی پروژهها، چند تا متد هستن که حتی دلت نمیخواد بازشون کنی.
چرا؟ چون چاقن!
هرچی اسکرول میکنی تموم نمیشن…
۲۰۰، ۳۰۰ خط فقط یه متد! 😵💫
🔴 مشکلش چیه؟
- خوندنش برای بقیه دولوپرها کابوسه
- حتی خود نویسندهش بعد یه مدت نمیفهمه چی نوشته
- دیباگ کردنش زمانبر و اعصابخوردکنه
- تغییر توش دادن یعنی دعوت به دردسر
👌 روش درست چیه؟
هر بخش از منطق رو بذار توی یه متد جدا، مخصوص خودش.
اینطوری:
✅ کد تکراری نداری
✅ متدات کوتاه و تمیز میشن
✅ از اسم متدها (اگه نامگذاری خوب باشه) راحت میفهمی هرکدوم چی کار میکنن
بهنظرم هر متد اگه بیشتر از ۱۰ تا ۱۵ خط بشه، وقتشه یه دستی بهش بکشی ✂️
(حتی اگه نظر شما یه کم فرق داره، ولی ۳۰۰ خط؟ اون دیگه فاجعهست 😄)
فرقی نداره چی داری:
.NET یا Java یا Python
SOLID یا spaghetti code
MVC یا Clean Architecture
چه زبانی، چه معماری، چه دیزاین پترنی، چه…
در هر حال، متد چاق اذیتت میکنه!
پس از چاقی فاصله بگیرید 😁
شما چی فکر میکنید؟
متد چاق اذیتتون نمیکنه؟
🔗 LinkedIn Post
یه وقتایی توی بعضی پروژهها، چند تا متد هستن که حتی دلت نمیخواد بازشون کنی.
چرا؟ چون چاقن!
هرچی اسکرول میکنی تموم نمیشن…
۲۰۰، ۳۰۰ خط فقط یه متد! 😵💫
🔴 مشکلش چیه؟
- خوندنش برای بقیه دولوپرها کابوسه
- حتی خود نویسندهش بعد یه مدت نمیفهمه چی نوشته
- دیباگ کردنش زمانبر و اعصابخوردکنه
- تغییر توش دادن یعنی دعوت به دردسر
👌 روش درست چیه؟
هر بخش از منطق رو بذار توی یه متد جدا، مخصوص خودش.
اینطوری:
✅ کد تکراری نداری
✅ متدات کوتاه و تمیز میشن
✅ از اسم متدها (اگه نامگذاری خوب باشه) راحت میفهمی هرکدوم چی کار میکنن
بهنظرم هر متد اگه بیشتر از ۱۰ تا ۱۵ خط بشه، وقتشه یه دستی بهش بکشی ✂️
(حتی اگه نظر شما یه کم فرق داره، ولی ۳۰۰ خط؟ اون دیگه فاجعهست 😄)
فرقی نداره چی داری:
.NET یا Java یا Python
SOLID یا spaghetti code
MVC یا Clean Architecture
چه زبانی، چه معماری، چه دیزاین پترنی، چه…
در هر حال، متد چاق اذیتت میکنه!
پس از چاقی فاصله بگیرید 😁
شما چی فکر میکنید؟
متد چاق اذیتتون نمیکنه؟
🔗 LinkedIn Post
❤2👍2
۱۰۰ سوال مصاحبه توسعهدهنده فولاستک داتنت (فرانتاند + بکاند + پایگاه داده + مفاهیم)
👍4🔥1
📘 Clean Code — ترجمه فارسی
یکی از بهترین کتابهای برنامهنویسی دنیا به فارسی 🌍
ترجمه و ویرایش این پروژه با همکاری من انجام شده و هدفش اینه که مفاهیم تمیزنویسی کد (Clean Code) برای برنامهنویسهای فارسیزبان در دسترستر باشه.
🔗 لینک پروژه در گیتهاب:
https://github.com/hheydarian/clean-code-persian
اگر به بهبود کیفیت کدهات و اصول حرفهای توسعه نرمافزار علاقه داری، حتما یه نگاهی بنداز
یکی از بهترین کتابهای برنامهنویسی دنیا به فارسی 🌍
ترجمه و ویرایش این پروژه با همکاری من انجام شده و هدفش اینه که مفاهیم تمیزنویسی کد (Clean Code) برای برنامهنویسهای فارسیزبان در دسترستر باشه.
🔗 لینک پروژه در گیتهاب:
https://github.com/hheydarian/clean-code-persian
اگر به بهبود کیفیت کدهات و اصول حرفهای توسعه نرمافزار علاقه داری، حتما یه نگاهی بنداز
1❤6👏4🔥1
درود دوستان
این مدت اخیر احتمالا ریپو های منو دیدین و میدونین که چندتا کتاب برنامه نویسی رو به زبان شیرین فارسی ترجمه کردم.
مطمئناً گیت هاب جای مطالعه کتاب نیست و خسته کننده س برای این کار، پس به سرم زد که کار رو راحت کنم! ایده!
با گیت هاب پیج ترجمه ها رو آنلاین کنم که مطالعه راحت تر باشه.
و بووووومممم!
اینم سایت گیتاب ، Gitab
به زودی pdf همه شون قرار میدم.
لطفاً با دستای خوشگل تون با استار دادن حمایت کنید و به اشتراک بذارید، این ترجمه ها واقعا میتونه به برنامه نویس های جونیور، مید لول ... کمک کنه. هدف؛ بهانه نداشتن برای مطالعه کردن، افزایش منابع فارسی
https://hheydarian.github.io/Gitab/
این مدت اخیر احتمالا ریپو های منو دیدین و میدونین که چندتا کتاب برنامه نویسی رو به زبان شیرین فارسی ترجمه کردم.
مطمئناً گیت هاب جای مطالعه کتاب نیست و خسته کننده س برای این کار، پس به سرم زد که کار رو راحت کنم! ایده!
با گیت هاب پیج ترجمه ها رو آنلاین کنم که مطالعه راحت تر باشه.
و بووووومممم!
اینم سایت گیتاب ، Gitab
به زودی pdf همه شون قرار میدم.
لطفاً با دستای خوشگل تون با استار دادن حمایت کنید و به اشتراک بذارید، این ترجمه ها واقعا میتونه به برنامه نویس های جونیور، مید لول ... کمک کنه. هدف؛ بهانه نداشتن برای مطالعه کردن، افزایش منابع فارسی
https://hheydarian.github.io/Gitab/
5🔥7❤🔥2🍾1🆒1
کتابخانه 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
📦 کتابخانهی Carter یک رویکرد مینیمال و تمیز برای پیادهسازی میکروسرویسها با Endpointهای Minimal API ارائه میدهد.
⚡️ بهطور کلی، Carter رویکردی مینیمال برای طراحی APIهای مدرن در .NET دارد. در معماریهای نوین نرمافزاری، بهویژه در ساختارهای میکروسرویسی، سادگی، ماژولار بودن و کاهش وابستگی بین اجزا از اصول کلیدی محسوب میشوند.
☯️ درنهایت، Carter با حذف نیاز به Controllerها و Attributeهای سنتی، از الگوی Minimal API الهام میگیرد و به توسعهدهنده اجازه میدهد تا Endpointها را در قالب ماژولهای مجزا تعریف کند. این رویکرد، ضمن حفظ قابلیت تزریق وابستگی (DI) و سازگاری کامل با Middlewareها، باعث افزایش انسجام کد و سهولت نگهداری در مقیاسهای بزرگ میشود.
😉 پ.ن: علاقهی شخصی من به مینیمالیسم و پروژههای سبک با پرفورمنس بالا، باعث جذابیت برخی معماریها و کتابخانههایی مثل Carter شده است. همچنین نظریههای مرتبط با معماری میکروسرویس، که با مضمون «کوچکترین سرویس کارآمد» شناخته میشوند، دلیل خوبی برای جایگزین کردن Minimal APIها بهجای Controllerها هستند.
🖼 اسلاید تصاویر شامل تعریف سرویس Carter، یک مثال ساده و نمونهای از پروژهی شخصی من در زمینهی ایجاد سفارش است.
🔗 Carter GitHub
🔗 LinkedIn Post
👍6
کدام زبان برنامهنویسی بیشترین پیچیدگی را تولید میکند؟ 💻
🔍 یک بررسی گسترده روی بیش از ۸ هزار پروژهٔ واقعی و ۱.۵ میلیارد خط کد نشان میدهد کدام زبانها بهطور متوسط کدهای پیچیدهتری میسازند.
📏 معیار سنجش: پیچیدگی حلقوی (Cyclomatic Complexity) یعنی تعداد مسیرهای اجرایی مستقلی که یک تابع میتواند طی کند.
هرچه این عدد بالاتر باشد، فهم، نگهداری و تستپذیری کد با دشواری بیشتری همراه است.
🧩 نتایج کلیدی
💥 متلب (MATLAB)
بالاترین پیچیدگی را دارد؛ چون معمولاً توسط افرادی استفاده میشود که اصلاً برنامهنویس نیستند و کدها ساختیافته نیستند.
⚙️ سی (C)
بهدلیل مدیریت خطای دستی و شرطهای متعدد، میانگین پیچیدگی بالاست.
🤯 جاوااسکریپت (JavaScript)
چرخههای تکرار سریع، تغییر دائم نیازمندیها و آشفتگی در ساختار آن، پیچیدگی را بالا میبرد. — در کل: به هیچ دردی نمیخورد! 😅
🐍 پایتون (Python)
خودشیرینی زیادی در سینتکس، به یک کد بیساختار و غیرقابلپیشبینی تبدیل شده است! — به درد Code Boyها میخورد.
🐳 گو (Go)
مدیریت خطای مناسبی ندارد و چکهای دستی زیادش باعث افزایش مسیرهای تصمیمگیری میشود — یک سرطان مهندسی! 😬
🧱 تایپاسکریپت (TypeScript)
بهواسطهٔ Type Safety بهتر، وضعیتش از جاوااسکریپت قابلتحملتر است.
☕ جاوا (Java)
از لحاظ کاهش پیچیدگی بدک نیست، ولی قدیمی و خشک است؛ نسل دایناسورهای نرمافزار! 🦕
💎 سیشارپ (#C) — گل سرسبد زبانها
✨ بهترین تعادل بین سادگی، قدرت و نظم
✨ کمترین پیچیدگی در تحلیلها
✨ طراحی مدرن، استثناهای ساختیافته، async/await خوانا، LINQ حرفهای
✨ ابزارهای کامل برای کنترل کیفیت کد
✨ خواناتر، تمیزتر و پایدارتر از هر زبان دیگری
سیشارپ یعنی:
کد کمتر، منطق واضحتر، تیم آرامتر و محصول قابلاعتمادتر. 💪
🦀 راست (Rust)
در عمل هنوز مصرف تجاری گسترده ندارد. هرچقدر هم تمیز باشد، وقتی در پروژههای واقعی استفاده نمیشود، تأثیر چندانی ندارد.
🧠 جمعبندی
اگر دنبال زبانی هستید که:
✅ پیچیدگی را کنترل کند،
✅ در مقیاس سازمانی پایدار بماند،
✅ و ابزارهای حرفهای برای کیفیت کد داشته باشد،
پاسخ روشن است:
💙 فقط سیشارپ (#C) — شاهکار واقعی مهندسی نرمافزار. 🚀
🔗 LinkedIn
🔍 یک بررسی گسترده روی بیش از ۸ هزار پروژهٔ واقعی و ۱.۵ میلیارد خط کد نشان میدهد کدام زبانها بهطور متوسط کدهای پیچیدهتری میسازند.
📏 معیار سنجش: پیچیدگی حلقوی (Cyclomatic Complexity) یعنی تعداد مسیرهای اجرایی مستقلی که یک تابع میتواند طی کند.
هرچه این عدد بالاتر باشد، فهم، نگهداری و تستپذیری کد با دشواری بیشتری همراه است.
🧩 نتایج کلیدی
💥 متلب (MATLAB)
بالاترین پیچیدگی را دارد؛ چون معمولاً توسط افرادی استفاده میشود که اصلاً برنامهنویس نیستند و کدها ساختیافته نیستند.
⚙️ سی (C)
بهدلیل مدیریت خطای دستی و شرطهای متعدد، میانگین پیچیدگی بالاست.
🤯 جاوااسکریپت (JavaScript)
چرخههای تکرار سریع، تغییر دائم نیازمندیها و آشفتگی در ساختار آن، پیچیدگی را بالا میبرد. — در کل: به هیچ دردی نمیخورد! 😅
🐍 پایتون (Python)
خودشیرینی زیادی در سینتکس، به یک کد بیساختار و غیرقابلپیشبینی تبدیل شده است! — به درد Code Boyها میخورد.
🐳 گو (Go)
مدیریت خطای مناسبی ندارد و چکهای دستی زیادش باعث افزایش مسیرهای تصمیمگیری میشود — یک سرطان مهندسی! 😬
🧱 تایپاسکریپت (TypeScript)
بهواسطهٔ Type Safety بهتر، وضعیتش از جاوااسکریپت قابلتحملتر است.
☕ جاوا (Java)
از لحاظ کاهش پیچیدگی بدک نیست، ولی قدیمی و خشک است؛ نسل دایناسورهای نرمافزار! 🦕
💎 سیشارپ (#C) — گل سرسبد زبانها
✨ بهترین تعادل بین سادگی، قدرت و نظم
✨ کمترین پیچیدگی در تحلیلها
✨ طراحی مدرن، استثناهای ساختیافته، async/await خوانا، LINQ حرفهای
✨ ابزارهای کامل برای کنترل کیفیت کد
✨ خواناتر، تمیزتر و پایدارتر از هر زبان دیگری
سیشارپ یعنی:
کد کمتر، منطق واضحتر، تیم آرامتر و محصول قابلاعتمادتر. 💪
🦀 راست (Rust)
در عمل هنوز مصرف تجاری گسترده ندارد. هرچقدر هم تمیز باشد، وقتی در پروژههای واقعی استفاده نمیشود، تأثیر چندانی ندارد.
🧠 جمعبندی
اگر دنبال زبانی هستید که:
✅ پیچیدگی را کنترل کند،
✅ در مقیاس سازمانی پایدار بماند،
✅ و ابزارهای حرفهای برای کیفیت کد داشته باشد،
پاسخ روشن است:
💙 فقط سیشارپ (#C) — شاهکار واقعی مهندسی نرمافزار. 🚀
❤🔥3❤2👍1👎1👏1
مدیرعامل آمازون: «جایگزین کردن جونیورها با AI، احمقانهترین حرفیه که شنیدم»
Matt Garman
مدیرعامل بخش AWS آمازون، توی یه مصاحبه گفت:
«من شنیدم کسانی میگویند با هوش مصنوعی میتونیم همهٔ کارکنان جونیور رو جایگزین کنیم.
من گفتم: این یکی از احمقانهترین حرفهاییست که تا به حال شنیدم.» ✅️
او ادامه داد:
🔹 کارکنان جونیور معمولاً کمهزینهترین نیروها هستند.
🔹 بیشترین تمایل رو به استفاده از ابزارهای AI دارند.
🔹 اگر امروز بهشون فرصت یادگیری ندیم، در ۱۰ سال آینده هیچ نیروی آموزشدیدهای نخواهیم داشت.
💡 به نظرم این حرف خیلی مهمه، مخصوصاً حالا که بعضی شرکتها با هیجان هوش مصنوعی دنبال حذف نقشهای ورودی هستن.
واقعیت اینه که AI جایگزین کامل نیست؛ ابزاریه برای تقویت و رشد نیروها.
🔗 LinkedIn
Matt Garman
مدیرعامل بخش AWS آمازون، توی یه مصاحبه گفت:
«من شنیدم کسانی میگویند با هوش مصنوعی میتونیم همهٔ کارکنان جونیور رو جایگزین کنیم.
من گفتم: این یکی از احمقانهترین حرفهاییست که تا به حال شنیدم.» ✅️
او ادامه داد:
🔹 کارکنان جونیور معمولاً کمهزینهترین نیروها هستند.
🔹 بیشترین تمایل رو به استفاده از ابزارهای AI دارند.
🔹 اگر امروز بهشون فرصت یادگیری ندیم، در ۱۰ سال آینده هیچ نیروی آموزشدیدهای نخواهیم داشت.
💡 به نظرم این حرف خیلی مهمه، مخصوصاً حالا که بعضی شرکتها با هیجان هوش مصنوعی دنبال حذف نقشهای ورودی هستن.
واقعیت اینه که AI جایگزین کامل نیست؛ ابزاریه برای تقویت و رشد نیروها.
👍3👨💻1
۱۲ سال تجربه بهعنوان توسعهدهندهی .NET – در ۶۰ ثانیه
در این مسیر درسهای زیادی آموختهام.
برخی از آنها دردناک بودند، اما بسیاریشان بیقیمت و ارزشمند.
اینجا ۴۰ نکتهی کلیدی را با شما به اشتراک میگذارم 👇
🔗 LinkedIn
در این مسیر درسهای زیادی آموختهام.
برخی از آنها دردناک بودند، اما بسیاریشان بیقیمت و ارزشمند.
اینجا ۴۰ نکتهی کلیدی را با شما به اشتراک میگذارم 👇
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. هرگز یادگیری و بهچالشکشیدن فرضیاتت را متوقف نکن.
❤6❤🔥1🔥1👏1