۱۲ سال تجربه به‌عنوان توسعه‌دهنده‌ی .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

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

#استخدام
ما در شرکت سازه‌های هوشمند داده‌بنیان کارو در حال توسعه‌ی یک نرم‌افزار مالی/حسابداری تحت وب هستیم و به دنبال برنامه‌نویس بک‌اند (.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