اصل 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

مهندس شدن با تصمیم شروع میشه، نه با کدنویسی!

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

اگه یادگیری هدفی باشه از مسیر مهندسی، یادگیری واقعی کجا اتفاق میوفته!؟

وسط میدون قرار گرفتی و یه Story Point مشخص شده برات تعیین میکنن، تو هم سعی میکنی با چیزایی که یاد داری به نحو ممکنه تسک رو به مرحله انجام برسونی؛ تصمیم های جالبی سر راه آدم میاد!

📌 اصولی کد رو بنویسم با تعمق بیشتری کنم، یا سعی کنم خیلی دقت نکنم و سریع کار رو تحویل بدم؛
ضمن اینکه تصمیم فردی تو وابستگی داره به تصمیم جمعی! ینی چی!؟
ینی اینطوری نیست برای انجام تسک به تنهایی تصمیم بگیری، لازمه شرایط شرکت فهمیده شه، دست خط کدی که نوشته شده تا اینجای پروژه شناسایی بشه..
بشینی ببینی نفر قبلی چیکار کرده که اول بفهمی از کجا اومدیم و در کجا هستیم که تازه بعدش و بر اساس جایگاه میزان تاثیر گذاری فردی که داری قدم برداری به جایی که میخوای تسک و ببری
📌 یا وقتی یه فیچر رو باید بسازی که مشتری واقعاً منتظرشه ممکنه مدل تصمیم گیریت برای انجامش متفاوت بشه
📌 وقتی محدودیت زمان و منابع داری و مجبوری انتخاب کنی، نه فقط یاد بگیری.

از قبیل این رشته تصمیمات زیاد هستند و اگه این مدلی بهش نگاه نکرده باشی، دلیلی به نبودنشون نیست!
از قبیل همین تصمیمات نِگرش یک فرد به مسیر مهندسی خودش رو میسازه و در عمل آجر به آجر روی هم چینده میشه تا بتونه در نهایت به یک حد قابل قبولی از مهندسی رو بدست بیاره (چیزی که تا الان اقلا فهمیدم)

نتیجه ما تا اینجای کار این شد که:
📌 مهندسی تصمیم‌گیری در شرایط ناپایدار
📌 فهم ارتباط گیری با محیط
📌 توانایی تفکیک مدل تصمیم گیری در تیم با حالتی که به صورت فردی کار میکنیم
📌 دقت عمل در کاری که میکنیم از منظر فنی

همیشه افراد یا شرکت‌ها با ساز و کار هم دیگه متناسب نیستند و ممکنه ناترازی ای بین طرفین وجود داشته باشه، یا حتی بعضیا ترجیح میدن با پروژه های شخصی یا پروژه هایی که به صورت freelancer انجام میدن، اون “میدون واقعی” رو برای خودشون بسازن و جلو برن.. یه جور مسیر موازی که با حقوق و ساختار کاری کسی محدود نمیشه.

میدونیم هر دوش در نوع خودش تجربه هایی برای هر فرد و شرکت می تونه به ارمغان بیاره.

به‌نظر شما تجربه واقعی تر که منجر به این بشه که سریعتر در این مسیر مهندسی به نتیجه قابل قبولی رسید کجاست؟
(قابل قبول: مهندسی که بتونه از پسِ مسائل یک پروژه بر بیاد و در زمان ممکن به انجام برسونه در عین حال زمان برای زندگی کردن خودش داره و اون رو هم مدیریت میکنه)

◽ وقتی وسط فشار پروژه و تیم تصمیم میگیری؟
◽ یا وقتی تنها، با علاقه ت میسازی و یاد میگیری؟
◽ !؟
(هرکسی یه مدل رشد داره، ولی تجربه شنیدنش همیشه کمک میکنه دید بازتری داشته باشیم.)

🔗 LinkedIn

هالووین در گیت هاب 🎃