#استخدام
ما در شرکت سازه‌های هوشمند داده‌بنیان کارو در حال توسعه‌ی یک نرم‌افزار مالی/حسابداری تحت وب هستیم و به دنبال برنامه‌نویس بک‌اند (.NET 8 / C#) با مهارت‌های زیر هستیم

🔹 مهارت های مورد نیاز:
ASP .NET Core 8 / C# 11-12
Entity Framework Core 8
SQL Server
REST API، JWT Auth، Git / GitFlow



✨ مهارت‌های امتیازی:
Unit Testing، Docker، Redis، RabbitMQ، CI/CD، Azure/AWS, Clean Architecture، DDD، Design Patterns

شرایط همکاری:
• نوع همکاری: تمام‌وقت (ساعت ۸:۳۰ تا ۱۶:۳۰)
• محل کار: سمنان یا تهران (امکان همکاری دورکار برای نیروهای توانمند - به شرط فعالیت و دردسترس بودن طی ساعات کاری مشخص شده - وجود دارد)
• حقوق: توافقی بر اساس سطح توانایی
• زمان کاری: شنبه تا چهارشنبه / پنجشنبه ها یک هفته درمیان

لطفاً رزومه خود را با عنوان «Backend Developer – [سطح مهارت شما]» به @ryhnjhr79 ارسال کنید.
در صورت تمایل، لینک GitHub یا نمونه پروژه‌های خود را نیز ضمیمه نمایید

بزرگترین دروغ این روزهای بازار کار برنامه‌نویسی

🔗 YouTube

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

از این هفته، هر هفته دو ویدئوی منتخب از بهترین محتوای آموزشی برنامه‌نویسی در یوتیوب رو با هشتگ #ویدئو_کدنویس به اشتراک می‌ذارم.
هدف اینه که ویدیوهای واقعاً مفید و کاربردی بین برنامه‌ نویس‌ها دست‌به‌دست بشن.

اگر شما هم ویدئوی باارزشی پیدا کردید، برام بفرستید تا در کانال منتشرش کنیم و بقیه هم استفاده کنن.

از میان این همه رزومه… واقعاً کی به مصاحبه می‌رسه؟

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

اینجوری رزومه‌ها رو غربال می‌کنم:

• مرحله اول: ۳۰ ثانیه تصمیم‌گیری
🛑 رد فوری اگر:
- تکنولوژی‌های اصلی Job Denoscription نیست
- رزومه عمومی و کپی‌پیست برای همه پوزیشن‌ها
- لینک‌ها باز نمی‌شن (یه 404 = بی‌دقتی)
- غلط املایی و فرمت شلخته
- رزومه ۵ صفحه‌ای با اطلاعات نامرتبط
- بات برای پر کردن GitHub = رد سریع

✅ ادامه می‌دم اگر:
- حداقل ۶۰٪ match با JD
- رزومه شخصی‌سازی‌شده برای ما
- لینک‌ها سالم و قابل بررسی
- خوانا، خلاصه و مرتب

• مرحله دوم: ۲–۳ دقیقه بررسی عمیق‌تر
✔️ تجربه کاری (اولویت اصلی)
- ثبات شغلی؟ مشروع و منطقی؟
- پروژه‌ها مرتبط؟
- شرح وظایف و تأثیر واقعی؟

✔️ Tech Stack
- واقعاً باهاش کار کرده یا فقط لیست کرده؟
- توضیح پروژه‌محور؟ (نه فقط نام تکنولوژی)

✔️ LinkedIn
- پروفایل زنده و حرفه‌ای؟
- تاریخ‌ها با رزومه همخوان؟

✔️ GitHub / Portfolio
- پروژه واقعی و قابل اجرا؟
- کامیت‌های طبیعی و منظم (نه ۱۰۰ کامیت در یه روز 😅)

🎯 چه کسی دعوت می‌شه؟
✔ رزومه مخصوص همین موقعیت
✔ پروژه واقعی با لینک و نتیجه
✔ پروفایل لینکدین مرتب و واقعی

❌ چه کسی رد می‌شه؟
- اغراق («expert در همه‌چیز» 😎)
- لینک‌های خراب
- تناقض رزومه و LinkedIn
- پروژه مصنوعی برای پر کردن رزومه

🎁 نکته مهم برای کارجوها

👶 Junior:
۳ پروژه واقعی > ۱۰۰ کامیت بی‌معنی

🧑💻 Mid/Senior:
ارزش واقعی = تجربه، حل مسئله، تأثیر کاری

GitHub داشتن خوبه؛ ولی همه‌چیز نیست.

✅ چک‌لیست قبل از ارسال رزومه
☑ رزومه مخصوص این آگهیه؟
☑ لینک‌ها سالم‌اند؟
☑ تکنولوژی‌های JD برجسته شد؟
☑ < ۲ صفحه و خواناست؟
☑ لینکدین آپدیت؟
☑ حداقل ۲ پروژه واقعی؟


من دنبال آدم کامل نیستم…
دنبال آدم واقعی، دقیق و مسئولم.

🔗 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)
- مرجع کلاسیک برای حل مشکلات رایج طراحی.
- وقتی آن را بخوانید، این الگوها را همه‌جا خواهید دید.

▶️ نکته حرفه‌ای:
فقط این کتاب‌ها را نخوانید.
از هر کتاب یک ایده را در پروژه بعدی‌تان به کار ببرید — این همان جایی است که رشد واقعی اتفاق می‌افتد.

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

🔗 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 نتایج پرتکرار رو کش کن تا پاسخ‌ها سریع‌تر بشن.
- بار روی دیتابیس کم می‌شه و اپلیکیشن حس روان‌تری پیدا می‌کنه.


🔗 LinkedIn

متغیرها (Variables) — جرقه‌ی ذخیره‌ی فکر

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

بعد یه روز یکی از برنامه‌نویس‌ها گفت:

اگه بخوام حاصل جمع قبلی رو نگه دارم چی؟ نمی‌تونم هر بار از اول حساب کنم!

اونجا بود که مفهوم متغیر (variable) به‌دنیا اومد — جایی توی حافظه که یه مقدار رو نگه می‌داره،
مثل مغز انسان که یه چیز رو موقتاً یادش می‌مونه.

متغیرها اولین قدم انسان برای فکر کردن با ماشین بودن

بخش اول

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

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

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

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

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

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

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

بخش دوم

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

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

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

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

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

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

بخش سوم

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

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

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

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

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

بخش چهارم

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

🔗 YouTube

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