چرا بعضی از کدهارو در برنامه نویسی متوجه نمیشیم؟

مقدمه

خیلی وقتها میشه کدی میبینیم و اصلا متوجه نمیشیم، مخصوصا در زمان استخدام و وقتی میخوایم کدهای دیگران بررسی کنیم و اینجت باعث میشه استرس بگیریم و فشار روانی زیاد تحمل کنیم، مثلاً در ASP.NET Core یا Angular خیلی از الگوها (مثل Dependency Injection، Strategy، Observer) به‌صورت طبیعی وجود دارند و حتی برنامه‌نویس‌ها ازشون استفاده می‌کنند بدون اینکه بدونن اسمش چیه؟! و این حالت خوبی برای یک برنامه نویس نیست به دلیل اینکه امکان تغییرش توسط شما نیست و ممکنه باعث بشه جاهایه مختلف سیستم عملکردشون دچار مشکل بشه!

همه دارن از Design Pattern استفاده می‌کنن…!

چه توی فرانت‌اند کار کنی چه بک‌اند، واقعیت اینه که بخش زیادی از ابزارها، فریم‌ورک‌ها و کتابخانه‌هایی که هر روز باهاشون سروکار داری، روی دوش Design Patternها ساخته شدن.
یعنی تو عملاً از الگوها استفاده می‌کنی — حتی اگه ندونی اسمشون چیه!

مثلاً در فرانت‌اند:

• وقتی در React از Context API یا Redux استفاده می‌کنی، داری از الگوی Observer Pattern استفاده می‌کنی.

• وقتی یک Higher-Order Component یا Custom Hook می‌نویسی، در واقع داری رفتار Decorator Pattern رو پیاده می‌کنی.

• یا وقتی در Angular با Dependency Injection سروکار داری، عملاً در حال استفاده از Factory Pattern و Inversion of Control هستی.

در بک‌اند هم همین داستانه:

• در ASP.NET Core یا NestJS، وقتی یک Service یا Controller می‌سازی و اون رو به صورت Dependency Injection تزریق می‌کنی، داری از Factory + Singleton Pattern استفاده می‌کنی.

• زمانی که Repository Pattern یا Unit of Work رو در لایه‌ی Data می‌نویسی، داری به شکل رسمی از الگوهای طراحی استفاده می‌کنی.

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

تفاوت بین “کدنویس” و “مهندس نرم‌افزار”

بیشتر برنامه‌نویس‌ها فقط می‌دونن چطور یه Feature رو بسازن.
اما حرفه‌ای‌ها می‌دونن چطور طراحی کنن که بعداً هم خودشون و هم بقیه بتونن توسعه بدن.
Design Pattern دقیقاً نقطه‌ی تمایز این دو دسته‌ست.

وقتی تو بدونی که مثلاً چرا در این موقعیت باید از Factory استفاده کنی و نه از Singleton، یا در چه شرایطی Observer مناسب‌تر از Mediator هست،
تو نه‌تنها بهتر کد می‌زنی — بلکه در تیم، به عنوان فردی با درک معماری بالا شناخته می‌شی.

بلد نبودن Design Pattern = نشانه‌ی ضعف در تیم و مصاحبه

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

«چطور ساختار پروژه‌ت رو طراحی می‌کنی؟»
«اگر بخوای وابستگی بین کلاس‌ها رو کمتر کنی، چه روشی پیشنهاد می‌دی؟»
«چطور می‌تونی رفتار کلاس‌ها رو بدون تغییر در کد اصلی تغییر بدی؟»

و اگر جواب این سؤالات رو بلد نباشی — یعنی در واقع الگوهای طراحی رو نمی‌دونی — احتمال زیادی هست که در همون مرحله رد بشی.
نه چون ضعیفی، بلکه چون هنوز با اون “نگاه مهندسی” آشنا نیستی.

راه‌حل: یادگیری اصول و Design Patternها

خوشبختانه، یادگیری Design Patternها یه کار پیچیده یا خشک نیست؛
فقط لازمه اصول پایه‌ای مثل SOLID، DRY و ساختار شیءگرایی رو درست بفهمی و بعد الگوها رو در قالب مثال واقعی ببینی.

من توی دوره‌ی «اصول و الگوهای طراحی در برنامه‌نویسی» دقیقاً همین کار رو کردم:

• از مفاهیم پایه شروع می‌کنیم،

• بعد به سراغ هر الگو با مثال واقعی می‌ریم،

• و در نهایت یاد می‌گیری چطور این الگوها رو در پروژه‌های واقعی خودت پیاده کنی.

اگر می‌خوای از یه کدنویس معمولی به یه مهندس نرم‌افزار حرفه‌ای تبدیل بشی،
و اگر می‌خوای وقتی اسم Design Pattern میاد، با اعتماد به نفس لبخند بزنی 😎
این دوره دقیقاً برای توست.

جمع بندی

ااگر می‌خواهید از یک کدنویس معمولی به یک مهندس نرم‌افزار حرفه‌ای تبدیل شوید، لازم است فراتر از صرفاً نوشتن کد، اصول طراحی صحیح را بیاموزید.
در دوره‌ی «اصول و الگوهای طراحی در برنامه‌نویسی» به‌صورت گام‌به‌گام با شیوه‌ی تفکر و طراحی برنامه‌نویسان حرفه‌ای آشنا می‌شوید — همین حالا ثبت‌نام کنید و سطح مهارت خود را ارتقا دهید.

برای ثبت نام به آیدی اینستاگرام ما در زیر پیام بدین.