شرط‌ها و حلقه‌ها — تقلید از منطق ذهن انسان

ما انسان‌ها تصمیم می‌گیریم:

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

همین منطق، همون چیزیه که در کدها شد:

if و else برای تصمیم‌گیری
for و while برای تکرار

یعنی برنامه‌نویسی از تقلید رفتار مغز انسان در تصمیم‌سازی شروع شد.

حلقه‌ها و شرط‌ها کمک می‌کنن یه ماشین، بدون اینکه فکر داشته باشه،
مثل ما رفتار کنه — تکرار کنه، تصمیم بگیره، مسیر عوض کنه.

بخش دوم

متدها (Functions) — ایدهٔ کارخانهٔ کوچک

تصور کن یه نجار برای هر میخ باید از نو چکش بسازه 😅
این دقیقاً مثل برنامه‌ای بود که قبل از وجود متدها نوشته می‌شد:
کدهای تکراری همه‌جا تکرار می‌شدن.

بعد اومدن گفتن:

بیایم یه کارخانه بسازیم که هر بار بخوام میخ بزنم، فقط صداش بزنم.

اون شد متدها — یه بستهٔ کوچک از منطق که یه کار خاص رو انجام می‌ده.
و شد پایهٔ مفهوم بازاستفاده (reusability) توی برنامه‌نویسی.

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

بخش سوم

کلاس و شیء (Class & Object) — ایدهٔ دنیای واقعی در برنامه

تا قبل از دههٔ ۷۰ میلادی، برنامه‌ها فقط تابع و داده بودن
یه روز مهندسی به نام آلن کی (Alan Kay) یه ایدهٔ عجیب داد:

اگه برنامه‌هامون هم مثل دنیا از چیزها ساخته بشن چی؟
هر چیز خودش داده و رفتار خودش رو داشته باشه... مثل آدم، ماشین، یا دانشجو.

اون شد شروع فلسفه‌ی Object-Oriented Programming (OOP).
کلاس شد تعریف نوع چیز
و شیء شد نمونهٔ واقعی اون چیز در دنیا.

این انقلاب باعث شد برنامه‌نویسی از حالت ماشینی بره به انسانی.
از اون به بعد ما شروع کردیم به مدل‌سازی دنیای واقعی با کد.

بخش چهارم

کدام مهارت ها در طوفان هوش مصنوعی باقی می مانند؟

🔗 YouTube

#ویدئو_کدنویس

راز های متد Main 🔎
متد Main نقطه ورود هر برنامه C# است، اما آیا میدونید چرا نمیتونیم به هر شکلی پیاده سازیش کنیم؟

بیاید یکم عمیق تر بررسی کنیم :

چیزهایی که میتونید تغییر بدید:
📌 نوع بازگشتی: void، int، Task یا Task<int>
📌 پارامتر: بدون پارامتر یا با string[] args
📌 نام کلاس: هر اسمی که بخواید (Program لازم نیست!)
📌 سطح دسترسی access modifier کلاس و متد: public، private، internal

❌ محدودیت هایی که باید بدونید:
۱. چرا باید static باشه؟
وقتی برنامه شروع میشه، هنوز هیچ شیئی ساخته نشده! Runtime باید بتونه مستقیماً Main رو صدا بزنه بدون اینکه اول یک instance بسازه. پس static اجباریه.

۲. چرا نمیتونه Generic باشه؟
فکرش رو بکنید: Runtime میخواد Main رو صدا بزنه، اما چطور تایپ پارامتر T رو مشخص کنه؟ هیچ راهی نداره! کامپایلر نمیتونه حدس بزنه شما int میخواید یا string.

۳. چرا فقط string[] قبوله؟
Runtime فقط آرگومانهای خط فرمان رو به صورت رشته پاس میده. اگر شما int یا bool میخواید، باید خودتون parse کنید. این طراحی زبان هست.

۴. چرا نمیتونه تو struct باشه؟
این یه محدودیت طراحی C# هست. Microsoft تصمیم گرفته فقط کلاس‌ها بتونن نقطه ورود باشن. فلسفه اش اینه که struct برای داده است، نه برای logic اصلی برنامه.

۵. چرا نوع بازگشتی محدوده؟
نوع بازگشتی Main باید با exit code سیستم عامل سازگار باشه. OS فقط اینها رو میفهمه:
• void: هیچ کد خروجی نمی فرسته (پیشفرض ۰)
• int: کد موفقیت/خطا (۰ = موفق، غیر۰ = خطا)
• Task/Task<int>: برای عملیات async

💡 نکته طلایی:
از C# 9 به بعد، میتونید با Top-Level Statements بدون کلاس و Main بنویسید! کامپایلر خودکار یه کلاس Program و متد Main میسازه.

💡درس اصلی:
این محدودیت ها تصادفی نیستن. همهشون به خاطر یه دلیل تکنیکی یا طراحی وجود دارن:
• سازگاری با Runtime
• امکان اجرا توسط سیستم‌عامل
• جلوگیری از ابهام در compile-time
وقتی دلیل این محدودیت ها رو میفهمید، درک بهتری از معماری NET. پیدا میکنید!

⚡ درضمن من تمام Signatureهای مختلف متد Main رو در این ریپوزیتوری پیاده سازی کردم . اگر مایل بودید میتونید بررسیش کنید :

🔗 GitHub

🔗 LinkedIn

وراثت (Inheritance) — الهام از DNA

تو از پدرت یه سری ویژگی داری (رنگ چشم، مدل رفتار) ولی خصوصیات خودت رو هم داری.
برنامه‌نویس‌ها اینو دیدن و گفتن:

پس کلاس‌ها هم می‌تونن از یه کلاس پدر چیزایی به ارث ببرن، ولی رفتار خودشون رو هم داشته باشن!

و اون شد وراثت — یک DNA کدنویسی
یعنی حذف تکرار (DRY Principle) و رابطهٔ منطقی بین کلاس‌ها.

بخش پنجم

اصول طراحی نرم‌افزار

1ـ KISS (Keep It Simple, Stupid)
«ساده نگهش دار»
- نرم‌افزار باید تا حد ممکن ساده باشد.
- از کدهای شفاف و کوتاه استفاده کن، پیچیدگی غیرضروری رو حذف کن و روی ویژگی‌های اصلی تمرکز داشته باش.


2ـ DRY (Don’t Repeat Yourself)
«خودت رو تکرار نکن»
- کد نباید تکراری باشه.
- از توابع و کلاس‌ها برای جمع کردن کدهای مشترک استفاده کن.
- مقادیر مشترک رو در متغیرها یا ثابت‌ها ذخیره کن.


3ـ YAGNI (You Ain’t Gonna Need It)
«چیزی که لازم نداری اضافه نکن»
- قابلیت‌هایی که واقعاً نیاز نیست رو به نرم‌افزار اضافه نکن.
- نرم‌افزار رو ساده و قابل نگهداری نگه دار.


4ـ SOLID — پنج اصل طلایی شی‌ءگرایی
- Single Responsibility Principle (SRP):
هر کلاس فقط یک مسئولیت داشته باشه.
- Open/Closed Principle (OCP):
کلاس‌ها برای توسعه باز باشن، اما برای تغییر بسته.
- Liskov Substitution Principle (LSP):
اشیای کلاس فرزند باید جایگزین اشیای کلاس والد بشن بدون مشکل.
- Interface Segregation Principle (ISP):
کاربر نباید مجبور باشه متدهایی رو پیاده‌سازی کنه که بهشون نیاز نداره.
- Dependency Inversion Principle(DIP):
وابستگی‌ها باید تزریق بشن، نه اینکه به‌صورت سخت‌کد شده داخل کلاس باشن.


5ـ اصل کمترین شگفتی
(Least Astonishment)
- نرم‌افزار باید مطابق انتظار کاربر رفتار کنه.
- از اصطلاحات و الگوهای آشنا استفاده کن و پیام‌های خطا رو واضح و کوتاه بنویس.


6ـ اصل ماژولار بودن (Modularity)
- نرم‌افزار رو به مجموعه‌ای از ماژول‌های مستقل تقسیم کن.
- این کار باعث میشه فهم، نگهداری و تست نرم‌افزار راحت‌تر بشه.

7ـ اصل انتزاع (Abstraction)
- جزئیات پیاده‌سازی رو از کاربر پنهان کن.
- این کار باعث میشه نرم‌افزار ساده‌تر و قابل استفاده‌تر باشه.

8ـ اصل کپسوله‌سازی (Encapsulation)
- وضعیت داخلی یک شیء نباید از بیرون قابل دسترسی مستقیم باشه.
- این کار نرم‌افزار رو مقاوم‌تر و قابل نگهداری‌تر می‌کنه.

9ـ اصل کمترین دانش (Least Knowledge)
- هر ماژول باید کمترین آگاهی ممکن از ماژول‌های دیگه داشته باشه.
- این باعث انعطاف‌پذیری و ماژولار بودن بیشتر سیستم میشه.

10ـ اصل کاهش کوپلینگ و افزایش انسجام (Low Coupling & High Cohesion)
- Coupling
(کوپلینگ): میزان وابستگی اجزای یک ماژول به هم. هرچه کمتر، بهتر.
- Cohesion
(انسجام): میزان ارتباط اجزای یک ماژول با هدف اصلی اون. هرچه بیشتر، بهتر.

🔗 LinkedIn

Polymorphism
(چندریختی) — فلسفه‌ی یک رفتار، چند معنا

کلمه‌ش یونانیه و یعنی چندشکلی.
مثلاً:
تو می‌تونی بگی:

«برو»
و برای انسان یعنی راه رفتن، برای ماشین یعنی حرکت کردن، برای برنامه یعنی اجرای دستور.

در برنامه‌نویسی هم همینه:
یک متد با یه اسم، ولی در هر کلاس رفتار خودش رو داره.

این یعنی درک عمیق از واقعیت:
یک مفهوم می‌تونه در موقعیت‌های مختلف، رفتار متفاوتی داشته باشه.

بخش ششم

Interface —توافق بین آدم‌ها

Interface یعنی:

من فقط قول می‌دم که فلان کارها رو انجام بدم. اما چطور؟ به خودم مربوطه.

مثلاً تو وقتی میری توی یه رستوران با پیشخدمت حرف می‌زنی، نه با آشپز، نه با مدیر.
پیشخدمت فقط یه interface بین تو و سیستم پشت صحنه‌ست.

در برنامه‌نویسی، Interface باعث می‌شه اجزای سیستم بدون آگاهی از جزئیات هم‌دیگه، با هم همکاری کنن.
این همون چیزیه که باعث می‌شه سیستم‌ها مستقل، مقیاس‌پذیر و قابل‌جایگزینی بشن.

بخش هفتم

بهترین ابزارهای هوش مصنوعی برای سال ۲۰۲۵

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

انتخابی عالی برای دانشجویان، خالقان محتوا، برنامه‌نویسان و کارآفرینانی که می‌خواهند در سال ۲۰۲۵ یک قدم جلوتر باشند.

🔗 LinkedIn

استثناء (Exception) — پذیرش خطا

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

آخه چرا باید یه اشتباه کوچک کل سیستم رو از کار بندازه؟ ما که خودمون اشتباه می‌کنیم ولی ادامه می‌دیم.

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

بخش هشتم

ادامه دارد...

8 کتابخانه جاوااسکریپت که باید در سال 2025 بدانید

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

🔗 LinkedIn

ریفکتور فقط تغییر کد نیست.

یعنی اینکه هر روز حواسمون به سیستمی که ازش پول در میاریم، آینده و اعتبار حرفه‌ای خودمون باشه. بهبود مستمر code base یعنی مراقبت از برند شخصیمون، نه وقتی اوضاع خراب میشه دست به تغییر بزنیم.

بنظرم ریفکتور درواقع بیشتر یه فرهنگه تا یه کار فنی.
در عین حال، هر جا کد کیفیت خوبی نداره، قرار نیست سریع بگیم فرهنگ تیم مشکل داره. خیلی وقتها فشار بیزنس، ددلاین و نبود فرآیند درست باعث میشه تیم فقط به رسوندن تسک و تحویل دادنش توجه کنه، نه انجام دادن کار درست.
ولی وقتی «کدی بزنیم که فقط تسک امون رو Done کنیم» میشه سبک زندگی تیم و هیچکس حواسش به کیفیت، ساختار یا آینده سیستم نیست، اون دیگه بدهی فنی ساده نیست؛ زنگ خطره.

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

پس در نهایت، ریفکتور فقط تمیزکاری کد نیست. ریفکتور یعنی تیمی که رشد کنه و فرهنگی که از تغییر نترسه و همیشه با پرسیدن «چرا » های درست شروع کنه نه «پیاده سازی».

🔗 LinkedIn

کتاب Apprenticeship Patterns
راهنماییه برای برنامه‌نویس‌هایی که می‌خوان از یه تازه‌کار، تبدیل به یه حرفه‌ای واقعی بشن.
این ترجمه فارسی، نسخه‌ای روان و کاربردیه از کتاب اصلیه و بهت کمک می‌کنه مسیر رشد شخصی و فنی‌ت رو آگاهانه طی کنی.

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

github.com/hheydarian/apprenticeship-patterns-persian

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

از شاگردی تا استادی

#استخدام

☑️ توسعه دهنده دات نت
✅ داتکس (داده پردازان تدبیر سرمایه) (تهران)

💬 شرایط:
- آشنایی خوب با C Sharp و NET Core
- تجربه کار با Web API
- آشنایی با SQL Server و T SQL
- درک ساختارهای نرم افزاری + کار تیمی
- امتیاز: Git، معماری چندلایه، RESTful
- مسئولیت پذیر، منظم، دقیق + علاقه مند به یادگیری و چالش

🏅چرا اینجا؟
- حقوق توافقی + کار روی پروژه های جدی بازار سرمایه
- فرصت یادگیری، تعامل و پیشرفت در تیم حرفهای
- ارائه وعده صبحانه و ناهار
- پرداخت های مناسبتی
- اتاق بازی

📧 info@datxsoft.com
🏣 Datxsoft
🔗 LinkedIn

نگاهی به ذهن یک طراح

🔗 YouTube

#ویدئو_کدنویس

نقل‌قول آغازین کتاب الگو های کارآموزی

کسی که نمی‌داند و نمی‌داند که نمی‌داند، احمق است — از او دوری کن...

این نقل‌قول پایهٔ فلسفهٔ کتاب را می‌گذارد:
خودآگاهی نسبت به دانسته‌ها و نادانسته‌ها، تفاوت بین شاگرد واقعی و مدعیِ دانایی است.
شاگرد باید بداند که نمی‌داند — این نقطهٔ شروع رشد است.

مقدمه - الگوهای کارآموزی

شاگردی تأثیرگذار است، زیرا در انسان اشتیاقی مادام‌العمر برای تسلط بر هنر می‌کارد. این اشتیاق به یادگیری پیوسته، شاگرد را در مسیر تبدیل‌شدن به یک توسعه‌دهنده‌ی بزرگ قرار می‌دهد. — پیت مک‌بریـن

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

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

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

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

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

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

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

فکر می‌کنم شاگرد بودن یعنی این نگرش که همیشه راهی بهتر، هوشمندانه‌تر و سریع‌تر برای انجام کاری که کردی وجود دارد. — مارتن گوستافسون

همین نگرش قلب مسیر است. شاگردی یعنی ماندن در وضعیت رشد، یعنی همیشه در جست‌وجوی بهتر شدن بودن، حتی اگر هیچ‌کس تو را راهنمایی نکند.

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

در نهایت، شاگردی فقط درباره‌ی syntax و ابزار نیست؛ درباره‌ی یاد گرفتن حرفه‌ای بودن است، درباره‌ی شبیه شدن به کسانی که کدنویسی را مثل یک هنر زندگی می‌کنند.

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

وقتی به آن نقطه برسی، یعنی دیگر فقط شاگرد نیستی، تو خودت بخشی از مسیر شده‌ای.

فصل اول - الگوهای کارآموزی