هر ثانیه یک توسعهدهندهی جدید به گیتهاب میپیوندد. بیش از ۱۸۰ میلیون توسعهدهنده، سازنده و خالق در سراسر جهان در حال دنبالکردن یک ایده، یک رویا یا جرقهای از کنجکاوی هستند که میخواهند آن را به واقعیت تبدیل کنند.
به بسیاری از جهات، این همیشه داستان نرمافزار بوده است. گیت از دل نیاز به همکاری بهتر شکل گرفت. متنباز، کد را به جامعه تبدیل کرد. GitHub Copilot هوش مصنوعی را وارد جریان کاری توسعهدهندگان کرد. و حالا، نوبت به «عاملها» رسیده است.
در هر دوره، ما نه تنها شاهد فناوریهای تازه، بلکه شاهد شیوههای تازهی کار کردن بودهایم. فرصتهای بیشتری برای ساختن و واقعیکردن ایدهها، با اصطکاک کمتر و خلاقیت و همکاری بیشتر. و با Agent HQ، ما شاهد آغاز فصلی تازه هستیم؛ نه فقط برای گیتهاب، بلکه برای جامعهی ما، برای نرمافزار، و برای جهان.
به همهی توسعهدهندگان، چه باتجربه و چه تازهکار: از شما سپاسگزاریم که هیجانانگیزترین بخش سفر گیتهاب هستید. داستان نرمافزار بار دیگر پیش چشم ما در حال شکلگیری است، و ما بیصبرانه منتظریم آن را با شما بنویسیم. ❤️
🔗 LinkedIn
به بسیاری از جهات، این همیشه داستان نرمافزار بوده است. گیت از دل نیاز به همکاری بهتر شکل گرفت. متنباز، کد را به جامعه تبدیل کرد. GitHub Copilot هوش مصنوعی را وارد جریان کاری توسعهدهندگان کرد. و حالا، نوبت به «عاملها» رسیده است.
در هر دوره، ما نه تنها شاهد فناوریهای تازه، بلکه شاهد شیوههای تازهی کار کردن بودهایم. فرصتهای بیشتری برای ساختن و واقعیکردن ایدهها، با اصطکاک کمتر و خلاقیت و همکاری بیشتر. و با Agent HQ، ما شاهد آغاز فصلی تازه هستیم؛ نه فقط برای گیتهاب، بلکه برای جامعهی ما، برای نرمافزار، و برای جهان.
به همهی توسعهدهندگان، چه باتجربه و چه تازهکار: از شما سپاسگزاریم که هیجانانگیزترین بخش سفر گیتهاب هستید. داستان نرمافزار بار دیگر پیش چشم ما در حال شکلگیری است، و ما بیصبرانه منتظریم آن را با شما بنویسیم. ❤️
❤2
۱۰ کتابی که شما را به یک مهندس نرمافزار و معمار ۱۰ برابر بهتر تبدیل میکنند:
▶️ نکته حرفهای:
فقط این کتابها را نخوانید.
از هر کتاب یک ایده را در پروژه بعدیتان به کار ببرید — این همان جایی است که رشد واقعی اتفاق میافتد.
این کتابها برنامهنویسها را به متفکران،
و مهندسان را به معماران تبدیل میکنند.
🔗 LinkedIn
۱. برنامهنویس عملگرا (Andy Hunt & Dave Thomas)
- درسهای کاربردی برای تمام مراحل مسیر شغلی.
- آموزش سازگاری، کنجکاوی و یادگیری مداوم.
۲. کدنویس پاک (Robert C. Martin)
- یادگیری حرفهایگری، انضباط و مسئولیتپذیری.
- یک توسعهدهنده عالی بودن فقط به نوشتن کد نیست — نگرش هم مهم است.
۳. الگوهای طراحی به روش Head First (Eric Freeman & Elisabeth Robson)
- روشی سرگرمکننده و تصویری برای یادگیری الگوهای طراحی.
- بالاخره میفهمید این الگوها در پروژههای واقعی چطور کار میکنند.
۴. معماری نرمافزار به روش Head First (Raju Gandhi, Mark Richards, Neal Ford)
- راهنمایی دوستانه و عملی برای معمارانه فکر کردن.
- عالی برای توسعهدهندگانی که میخواهند وارد دنیای معماری شوند.
۵. ساخت معماریهای تکاملی (Neal Ford, Rebecca Parsons, Patrick Kua)
- یاد بگیرید سیستمهایی طراحی کنید که با زمان رشد و تغییر کنند.
- تغییر همیشگی است — این کتاب به شما میآموزد چطور با آن کنار بیایید.
۶. الگوهای معماری سازمانی (Martin Fowler)
- درک نحوه ساختاردهی و اتصال سیستمهای بزرگ.
- مناسب برای پروژههای سازمانی یا بلندمدت و در مقیاس وسیع.
۷. طراحی اپلیکیشنهای دادهمحور (Martin Kleppmann)
- مطالعهای ضروری برای طراحی سیستمهای مدرن.
- پایگاهدادهها، مقیاسپذیری و پردازش داده را به زبانی ساده توضیح میدهد.
۸. طراحی دامنهمحور (Eric Evans)
- یادگیری مدلسازی منطق پیچیده کسبوکار با سادگی.
- دیدگاه شما را در گفتگو با توسعهدهندگان و مدیران تغییر میدهد.
۹. ساخت میکروسرویسها (Sam Newman)
- راهنمای کامل برای ایجاد سیستمهای توزیعشده.
- پر از درسهای عملی و مصالحههای دنیای واقعی.
۱۰. الگوهای معماری نرمافزار سازمانی (Martin Fowler)
- مرجع کلاسیک برای حل مشکلات رایج طراحی.
- وقتی آن را بخوانید، این الگوها را همهجا خواهید دید.
▶️ نکته حرفهای:
فقط این کتابها را نخوانید.
از هر کتاب یک ایده را در پروژه بعدیتان به کار ببرید — این همان جایی است که رشد واقعی اتفاق میافتد.
این کتابها برنامهنویسها را به متفکران،
و مهندسان را به معماران تبدیل میکنند.
❤2🔥2👍1
.NET | دات نت
۱۰ کتابی که شما را به یک مهندس نرمافزار و معمار ۱۰ برابر بهتر تبدیل میکنند: ۱. برنامهنویس عملگرا (Andy Hunt & Dave Thomas) - درسهای کاربردی برای تمام مراحل مسیر شغلی. - آموزش سازگاری، کنجکاوی و یادگیری مداوم. ۲. کدنویس پاک (Robert C. Martin)…
books software engineer (1).pdf
10.1 MB
❤1💯1
۱۰ راز که توسعهدهندههای ارشد برای ساخت کنترلرهای ۱۰ برابر بهتر استفاده میکنن — و توسعهدهندههای میانی و تازهکار ازش بیخبرن
چی هستن این رازها؟ 👇
🔗 LinkedIn
چی هستن این رازها؟ 👇
۱. کنترلرها رو باریک نگه دار
- کنترلر جای منطق تجاری نیست.
- فقط باید مسئول دریافت درخواست و ارسال پاسخ باشه.
- منطق رو منتقل کن به سرویسها یا لایهی اپلیکیشن تا کد تمیز و قابل تست بمونه.
۲. تزریق وابستگی در سطح متد رو ترجیح بده
- لازم نیست همه چیز رو توی سازنده تزریق کنی.
- فقط وابستگیهای مورد نیاز هر متد رو مستقیماً به پارامترهای همون متد تزریق کن.
- این کار کنترلر رو سبکتر و نگهداریش رو راحتتر میکنه.
۳. برای مدیریت خطاها از ProblemDetails استفاده کن
- مدلهای خطای سفارشی رو کنار بذار.
- از ProblemDetails استفاده کن — فرمت استاندارد و داخلی برای خطاهای API.
- پاسخهای خطا رو منسجم و قابل فهم میکنه.
۴. از کنوانسیونهای [ApiController] بهره ببر
- از [ApiController] استفاده کن — اعتبارسنجی مدل، بایند کردن دادهها و تولید پاسخ رو خودش انجام میده.
- کدهای تکراری کمتر، کد تمیزتر بیشتر.
۵. برای دغدغههای مشترک از فیلترها استفاده کن
- لاگگیری، اعتبارسنجی یا مدیریت خطا رو توی هر کنترلر تکرار نکن.
- از فیلترهایی مثل ActionFilter یا ExceptionFilter استفاده کن تا این موارد رو بهصورت سراسری مدیریت کنی.
۶. از محدودیتها و الگوهای مسیر استفاده کن
- محدودیتهایی مثل {id:int} یا {slug:alpha} رو به مسیرها اضافه کن تا درخواستهای نامعتبر رد بشن.
- این کار نقطههای پایانی API رو قابل پیشبینی و خودمستند میکنه.
۷. از نتایج تایپشده استفاده کن
- بهجای IActionResult از Ok<T>()، NotFound() یا Results<T>() استفاده کن.
- وضوح، تستپذیری و مستندسازی Swagger رو بهبود میده.
۸. اعتبارسنجی رو درست انجام بده
- توی هر متد کنترلر اعتبارسنجی دستی انجام نده.
- از [ApiController] و Data Annotation استفاده کن — اعتبارسنجی خودکار با پاسخهای ۴۰۰ تمیز.
۹. نقطههای پایانی رو منطقی گروهبندی کن
- مسیرها رو بر اساس دامنه یا ویژگی گروهبندی کن، نه لایهی معماری.
- نقطههای مرتبط رو کنار هم نگه دار — API راحتتر مقیاسپذیر و قابل پیمایش میشه.
۱۰. از کش خروجی استفاده کن
- با OutputCache نتایج پرتکرار رو کش کن تا پاسخها سریعتر بشن.
- بار روی دیتابیس کم میشه و اپلیکیشن حس روانتری پیدا میکنه.
🔥3❤🔥1
.NET | دات نت
۱۰ راز که توسعهدهندههای ارشد برای ساخت کنترلرهای ۱۰ برابر بهتر استفاده میکنن — و توسعهدهندههای میانی و تازهکار ازش بیخبرن چی هستن این رازها؟ 👇 ۱. کنترلرها رو باریک نگه دار - کنترلر جای منطق تجاری نیست. - فقط باید مسئول دریافت درخواست و ارسال پاسخ…
use---to make Controllers 10x better.pdf
11.5 MB
❤3
بیاین با هم یه سفر ذهنی کنیم به دنیای مفاهیمی که تا الان یاد گرفتین — نه به شکل درس، بلکه به شکل داستان و فلسفهشون 👇
👍6
متغیرها (Variables) — جرقهی ذخیرهی فکر
خیلی سال پیش، وقتی کامپیوترها تازه ساخته شدن، برنامهها فقط یه سری دستور ساده اجرا میکردن:
مثلاً جمع کن یا منفی کن. هیچ حافظهای برای نگه داشتن داده نبود.
بعد یه روز یکی از برنامهنویسها گفت:
اگه بخوام حاصل جمع قبلی رو نگه دارم چی؟ نمیتونم هر بار از اول حساب کنم!
اونجا بود که مفهوم متغیر (variable) بهدنیا اومد — جایی توی حافظه که یه مقدار رو نگه میداره،
مثل مغز انسان که یه چیز رو موقتاً یادش میمونه.
متغیرها اولین قدم انسان برای فکر کردن با ماشین بودن
خیلی سال پیش، وقتی کامپیوترها تازه ساخته شدن، برنامهها فقط یه سری دستور ساده اجرا میکردن:
مثلاً جمع کن یا منفی کن. هیچ حافظهای برای نگه داشتن داده نبود.
بعد یه روز یکی از برنامهنویسها گفت:
اگه بخوام حاصل جمع قبلی رو نگه دارم چی؟ نمیتونم هر بار از اول حساب کنم!
اونجا بود که مفهوم متغیر (variable) بهدنیا اومد — جایی توی حافظه که یه مقدار رو نگه میداره،
مثل مغز انسان که یه چیز رو موقتاً یادش میمونه.
متغیرها اولین قدم انسان برای فکر کردن با ماشین بودن
بخش اول
1👍6❤2
شرطها و حلقهها — تقلید از منطق ذهن انسان
ما انسانها تصمیم میگیریم:
اگه گرسنهم بود، غذا میخورم.
اگه هنوز کارم تموم نشده، ادامه میدم.
همین منطق، همون چیزیه که در کدها شد:
if و else برای تصمیمگیری
for و while برای تکرار
یعنی برنامهنویسی از تقلید رفتار مغز انسان در تصمیمسازی شروع شد.
حلقهها و شرطها کمک میکنن یه ماشین، بدون اینکه فکر داشته باشه،
مثل ما رفتار کنه — تکرار کنه، تصمیم بگیره، مسیر عوض کنه.
ما انسانها تصمیم میگیریم:
اگه گرسنهم بود، غذا میخورم.
اگه هنوز کارم تموم نشده، ادامه میدم.
همین منطق، همون چیزیه که در کدها شد:
if و else برای تصمیمگیری
for و while برای تکرار
یعنی برنامهنویسی از تقلید رفتار مغز انسان در تصمیمسازی شروع شد.
حلقهها و شرطها کمک میکنن یه ماشین، بدون اینکه فکر داشته باشه،
مثل ما رفتار کنه — تکرار کنه، تصمیم بگیره، مسیر عوض کنه.
بخش دوم
👍6❤1
متدها (Functions) — ایدهٔ کارخانهٔ کوچک
تصور کن یه نجار برای هر میخ باید از نو چکش بسازه 😅
این دقیقاً مثل برنامهای بود که قبل از وجود متدها نوشته میشد:
کدهای تکراری همهجا تکرار میشدن.
بعد اومدن گفتن:
بیایم یه کارخانه بسازیم که هر بار بخوام میخ بزنم، فقط صداش بزنم.
اون شد متدها — یه بستهٔ کوچک از منطق که یه کار خاص رو انجام میده.
و شد پایهٔ مفهوم بازاستفاده (reusability) توی برنامهنویسی.
متدها باعث شدن کدها تمیزتر، کوتاهتر و خواناتر بشن
دقیقاً مثل آدمی که برای کارهای روزمرهاش روتین میسازه.
تصور کن یه نجار برای هر میخ باید از نو چکش بسازه 😅
این دقیقاً مثل برنامهای بود که قبل از وجود متدها نوشته میشد:
کدهای تکراری همهجا تکرار میشدن.
بعد اومدن گفتن:
بیایم یه کارخانه بسازیم که هر بار بخوام میخ بزنم، فقط صداش بزنم.
اون شد متدها — یه بستهٔ کوچک از منطق که یه کار خاص رو انجام میده.
و شد پایهٔ مفهوم بازاستفاده (reusability) توی برنامهنویسی.
متدها باعث شدن کدها تمیزتر، کوتاهتر و خواناتر بشن
دقیقاً مثل آدمی که برای کارهای روزمرهاش روتین میسازه.
بخش سوم
👍4❤1
کلاس و شیء (Class & Object) — ایدهٔ دنیای واقعی در برنامه
تا قبل از دههٔ ۷۰ میلادی، برنامهها فقط تابع و داده بودن
یه روز مهندسی به نام آلن کی (Alan Kay) یه ایدهٔ عجیب داد:
اگه برنامههامون هم مثل دنیا از چیزها ساخته بشن چی؟
هر چیز خودش داده و رفتار خودش رو داشته باشه... مثل آدم، ماشین، یا دانشجو.
اون شد شروع فلسفهی Object-Oriented Programming (OOP).
کلاس شد تعریف نوع چیز
و شیء شد نمونهٔ واقعی اون چیز در دنیا.
این انقلاب باعث شد برنامهنویسی از حالت ماشینی بره به انسانی.
از اون به بعد ما شروع کردیم به مدلسازی دنیای واقعی با کد.
تا قبل از دههٔ ۷۰ میلادی، برنامهها فقط تابع و داده بودن
یه روز مهندسی به نام آلن کی (Alan Kay) یه ایدهٔ عجیب داد:
اگه برنامههامون هم مثل دنیا از چیزها ساخته بشن چی؟
هر چیز خودش داده و رفتار خودش رو داشته باشه... مثل آدم، ماشین، یا دانشجو.
اون شد شروع فلسفهی Object-Oriented Programming (OOP).
کلاس شد تعریف نوع چیز
و شیء شد نمونهٔ واقعی اون چیز در دنیا.
این انقلاب باعث شد برنامهنویسی از حالت ماشینی بره به انسانی.
از اون به بعد ما شروع کردیم به مدلسازی دنیای واقعی با کد.
بخش چهارم
👍3❤1
راز های متد 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
متد 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
👍3👨💻1
وراثت (Inheritance) — الهام از DNA
تو از پدرت یه سری ویژگی داری (رنگ چشم، مدل رفتار) ولی خصوصیات خودت رو هم داری.
برنامهنویسها اینو دیدن و گفتن:
پس کلاسها هم میتونن از یه کلاس پدر چیزایی به ارث ببرن، ولی رفتار خودشون رو هم داشته باشن!
و اون شد وراثت — یک DNA کدنویسی
یعنی حذف تکرار (DRY Principle) و رابطهٔ منطقی بین کلاسها.
تو از پدرت یه سری ویژگی داری (رنگ چشم، مدل رفتار) ولی خصوصیات خودت رو هم داری.
برنامهنویسها اینو دیدن و گفتن:
پس کلاسها هم میتونن از یه کلاس پدر چیزایی به ارث ببرن، ولی رفتار خودشون رو هم داشته باشن!
و اون شد وراثت — یک DNA کدنویسی
یعنی حذف تکرار (DRY Principle) و رابطهٔ منطقی بین کلاسها.
بخش پنجم
👍4
اصول طراحی نرمافزار
🔗 LinkedIn
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
(انسجام): میزان ارتباط اجزای یک ماژول با هدف اصلی اون. هرچه بیشتر، بهتر.
1🔥3❤🔥1
Polymorphism
(چندریختی) — فلسفهی یک رفتار، چند معنا
کلمهش یونانیه و یعنی چندشکلی.
مثلاً:
تو میتونی بگی:
«برو»
و برای انسان یعنی راه رفتن، برای ماشین یعنی حرکت کردن، برای برنامه یعنی اجرای دستور.
در برنامهنویسی هم همینه:
یک متد با یه اسم، ولی در هر کلاس رفتار خودش رو داره.
این یعنی درک عمیق از واقعیت:
یک مفهوم میتونه در موقعیتهای مختلف، رفتار متفاوتی داشته باشه.
(چندریختی) — فلسفهی یک رفتار، چند معنا
کلمهش یونانیه و یعنی چندشکلی.
مثلاً:
تو میتونی بگی:
«برو»
و برای انسان یعنی راه رفتن، برای ماشین یعنی حرکت کردن، برای برنامه یعنی اجرای دستور.
در برنامهنویسی هم همینه:
یک متد با یه اسم، ولی در هر کلاس رفتار خودش رو داره.
این یعنی درک عمیق از واقعیت:
یک مفهوم میتونه در موقعیتهای مختلف، رفتار متفاوتی داشته باشه.
بخش ششم
👍5
Interface —توافق بین آدمها
Interface یعنی:
من فقط قول میدم که فلان کارها رو انجام بدم. اما چطور؟ به خودم مربوطه.
مثلاً تو وقتی میری توی یه رستوران با پیشخدمت حرف میزنی، نه با آشپز، نه با مدیر.
پیشخدمت فقط یه interface بین تو و سیستم پشت صحنهست.
در برنامهنویسی، Interface باعث میشه اجزای سیستم بدون آگاهی از جزئیات همدیگه، با هم همکاری کنن.
این همون چیزیه که باعث میشه سیستمها مستقل، مقیاسپذیر و قابلجایگزینی بشن.
Interface یعنی:
من فقط قول میدم که فلان کارها رو انجام بدم. اما چطور؟ به خودم مربوطه.
مثلاً تو وقتی میری توی یه رستوران با پیشخدمت حرف میزنی، نه با آشپز، نه با مدیر.
پیشخدمت فقط یه interface بین تو و سیستم پشت صحنهست.
در برنامهنویسی، Interface باعث میشه اجزای سیستم بدون آگاهی از جزئیات همدیگه، با هم همکاری کنن.
این همون چیزیه که باعث میشه سیستمها مستقل، مقیاسپذیر و قابلجایگزینی بشن.
بخش هفتم
👍4❤1
AITools2025.pdf
22.3 MB
بهترین ابزارهای هوش مصنوعی برای سال ۲۰۲۵
بهرهوری و خلاقیت خود را با قدرتمندترین ابزارهای هوش مصنوعی سال ارتقا دهید!
این ابزارها شیوهی کار، خلق محتوا و خودکارسازی را در زندگی روزمره دگرگون کردهاند.
انتخابی عالی برای دانشجویان، خالقان محتوا، برنامهنویسان و کارآفرینانی که میخواهند در سال ۲۰۲۵ یک قدم جلوتر باشند.
🔗 LinkedIn
بهرهوری و خلاقیت خود را با قدرتمندترین ابزارهای هوش مصنوعی سال ارتقا دهید!
این ابزارها شیوهی کار، خلق محتوا و خودکارسازی را در زندگی روزمره دگرگون کردهاند.
انتخابی عالی برای دانشجویان، خالقان محتوا، برنامهنویسان و کارآفرینانی که میخواهند در سال ۲۰۲۵ یک قدم جلوتر باشند.
👍2❤1
استثناء (Exception) — پذیرش خطا
قبلاً برنامهها اگر خطا داشتن، فوراً میمردن.
بعد انسان گفت:
آخه چرا باید یه اشتباه کوچک کل سیستم رو از کار بندازه؟ ما که خودمون اشتباه میکنیم ولی ادامه میدیم.
و اینطور Exception به دنیا اومد.
یعنی برنامهنویسی یاد گرفت مثل انسان، خطا رو بپذیره و خودش رو اصلاح کنه.
ادامه دارد...
قبلاً برنامهها اگر خطا داشتن، فوراً میمردن.
بعد انسان گفت:
آخه چرا باید یه اشتباه کوچک کل سیستم رو از کار بندازه؟ ما که خودمون اشتباه میکنیم ولی ادامه میدیم.
و اینطور Exception به دنیا اومد.
یعنی برنامهنویسی یاد گرفت مثل انسان، خطا رو بپذیره و خودش رو اصلاح کنه.
بخش هشتم
ادامه دارد...
👍5
.NET | دات نت
استثناء (Exception) — پذیرش خطا قبلاً برنامهها اگر خطا داشتن، فوراً میمردن. بعد انسان گفت: آخه چرا باید یه اشتباه کوچک کل سیستم رو از کار بندازه؟ ما که خودمون اشتباه میکنیم ولی ادامه میدیم. و اینطور Exception به دنیا اومد. یعنی برنامهنویسی یاد گرفت…
برنامهنویسی فقط نوشتن کد نیست؛
در واقع ما داریم دنیای واقعی رو مدلسازی میکنیم،
ولی به زبانی که کامپیوتر بفهمه.
هر بار که یه کلاس میسازی، یه موجود جدید توی دنیای دیجیتالت خلق میکنی.
هر بار که یه Interface مینویسی، یه قانون اجتماعی تعریف میکنی.
و هر بار که Exception هندل میکنی، داری به برنامهت انسانیت یاد میدی 💛
در واقع ما داریم دنیای واقعی رو مدلسازی میکنیم،
ولی به زبانی که کامپیوتر بفهمه.
هر بار که یه کلاس میسازی، یه موجود جدید توی دنیای دیجیتالت خلق میکنی.
هر بار که یه Interface مینویسی، یه قانون اجتماعی تعریف میکنی.
و هر بار که Exception هندل میکنی، داری به برنامهت انسانیت یاد میدی 💛
نتیجه
👍5🔥1🆒1
JavaScriptLibrary.pdf
5 MB
8 کتابخانه جاوااسکریپت که باید در سال 2025 بدانید
اگه توسعهدهندهای هستی که میخوای همیشه یک قدم جلوتر باشی، تسلط بر کتابخانههای درست میتونه ساعتها وقتت رو ذخیره کنه و پروژههات رو چند پله ارتقا بده. این کتابخانههای جاوااسکریپت فقط محبوب نیستن—دارن شیوه ساخت اپلیکیشنهای مدرن وب رو از نو تعریف میکنن.
🔗 LinkedIn
اگه توسعهدهندهای هستی که میخوای همیشه یک قدم جلوتر باشی، تسلط بر کتابخانههای درست میتونه ساعتها وقتت رو ذخیره کنه و پروژههات رو چند پله ارتقا بده. این کتابخانههای جاوااسکریپت فقط محبوب نیستن—دارن شیوه ساخت اپلیکیشنهای مدرن وب رو از نو تعریف میکنن.
❤1👍1🔥1