<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>نوشته های Nima Airyana</title><link>https://virgool.ir/feed/@nima.airyana</link><description>مهندس نرم‌افزار با تمرکز روی C# و .NET، علاقه‌مند به معماری نرم‌افزار، DDD، Clean Code و رشد به سمت Engineering Manager. درباره تجربه‌های مهندسی و یادگیری‌هایم می‌نویسم.</description><language>fa</language><pubDate>2026-11-11 11:16:44</pubDate><image><url>https://files.virgool.ir/upload/users/244135/avatar/zkJnYe.jpg</url><title>Nima Airyana</title><link>https://virgool.ir/@nima.airyana</link></image><item><title>کد چیه؟ چرا توی عصر هوش مصنوعی کد فقط یه دستور نیست، بلکه مدل فهم سیستمه</title><link>https://virgool.ir/@nima.airyana/what-is-code-wqihigbrllbs</link><description>این روزها ابزارهای هوش مصنوعی می‌تونن توی چند ثانیه برای ما کد تولید کنن؛ از یک Function ساده گرفته تا API، تست و حتی بخش‌هایی از یک قابلیت کامل.همین موضوع یه سؤال مهم ایجاد کرده:وقتی نوشتن کد هر روز راحت‌تر و سریع‌تر می‌شه، ارزش واقعی یک مهندس نرم‌افزار کجاست؟مقالهٔ What Is Code? نوشتهٔ اونمش جوشی (Unmesh Joshi) از Thoughtworks دقیقاً سراغ همین سؤال می‌ره.ایدهٔ اصلی مقاله اینه:کد فقط دستورهایی نیست که کامپیوتر اجراشون کنه؛ کد مدلیه که ما با کمکش مسئله، قوانین کسب‌وکار و ساختار سیستم رو می‌فهمیم.کد فقط برای ماشین نیستوقتی دربارهٔ کد حرف می‌زنیم، معمولاً اولین چیزی که به ذهنمون میاد اینه که کد باید به کامپیوتر بگه چه کاری انجام بده.مثلاً:اطلاعاتی رو بخونه؛محاسبه‌ای انجام بده؛داده‌ای رو ذخیره کنه؛با یک سرویس دیگه ارتباط بگیره.اما کد یک نقش مهم دیگه هم داره: توضیح‌دادن سیستم برای آدم‌ها.یک کدبیس خوب باید به ما نشون بده:سیستم دربارهٔ چه مفاهیمی صحبت می‌کنه؛هر مفهوم چه معنایی داره؛چه ارتباطی بین بخش‌های مختلف وجود داره؛چه قانون‌هایی نباید شکسته بشن.مثلاً در یک سیستم فروش، احتمالاً با مفاهیمی مثل مشتری، سفارش، پرداخت، ارسال و مرجوعی روبه‌رو می‌شیم.اما فقط اینکه چند کلاس با اسم‌های Customer، Order و Payment داشته باشیم، به این معنی نیست که مدل خوبی ساختیم.سؤال‌های مهم‌تر این‌ها هستن:سفارش دقیقاً چه زمانی ثبت‌شده محسوب می‌شه؟اگر پرداخت ناموفق باشه چه اتفاقی برای سفارش می‌افته؟آیا سفارش ارسال‌شده قابل لغوه؟چه کسی اجازه تغییر اطلاعات سفارش رو داره؟همین قانون‌ها و رفتارها هستن که مدل واقعی سیستم رو می‌سازن.مدل خوب فقط اسم کلاس‌ها نیست؛ ترکیبی از معنا، رفتار و قوانین کسب‌وکاره.برنامه‌نویس در واقع داره ترجمه می‌کنههر کسب‌وکاری زبان مخصوص خودش رو داره.برای ساختن یک سیستم بانکی، فقط بلدبودن C# یا Java کافی نیست. باید مفهوم‌هایی مثل موجودی، تسویه، بدهی، تراکنش برگشتی و محدودیت اعتباری رو هم بفهمیم.یک برنامه‌نویس در عمل بین چند زبان ترجمه انجام می‌ده:زبان کسب‌وکار؛زبان طراحی نرم‌افزار؛زبان برنامه‌نویسی.کار اصلی اینه که مفهوم‌های واقعی کسب‌وکار رو به شکلی وارد کد کنیم که هم ماشین بفهمه و هم انسان.مثلاً مفهوم «پول» رو در نظر بگیر.در نگاه اول شاید بگیم پول فقط یک عدد decimal هست، اما واقعاً این‌طور نیست.پول:مقدار داره؛ارز داره؛قانون‌هایی برای محاسبه و مقایسه داره.پس اگر این مفهوم رو فقط به یک عدد ساده تبدیل کنیم، بخشی از معنی اصلی رو از دست دادیم.کد خوب کمک می‌کنه این معنی‌ها گم نشن.ارتباط این موضوع با DDDاین نگاه خیلی به یکی از ایده‌های اصلی Domain-Driven Design نزدیکه.در DDD مفهومی داریم به اسم Bounded Context.یعنی هر بخش از سیستم می‌تونه زبان و مدل خودش رو داشته باشه.مثلاً کلمهٔ «مشتری» در بخش‌های مختلف یک شرکت الزاماً یک معنی نداره:در فروش، کسیه که خرید انجام می‌ده؛در حسابداری، یک طرف حساب مالیه؛در پشتیبانی، کسیه که قرارداد خدماتی داره.یکی از اشتباه‌های رایج اینه که بخوایم یک مدل بزرگ به اسم Customer بسازیم و همه این معنی‌ها رو داخلش قرار بدیم.نتیجه معمولاً یک مدل شلوغ و مبهم می‌شه که هر تغییری در یک بخش، بخش‌های دیگه رو هم تحت تأثیر قرار می‌ده.راه بهتر اینه که هر بخش، مفهوم‌ها و قوانین خودش رو داشته باشه و ارتباط بین مدل‌ها واضح طراحی بشه.دو چیز که اسم یکسان دارن، لزوماً مفهوم یکسانی ندارن.طراحی خوب از روز اول کامل مشخص نیستیکی از نکته‌های جالب مقاله اینه که معمولاً از روز اول نمی‌دونیم بهترین طراحی سیستم دقیقاً چیه.خیلی از چیزها وقتی روشن می‌شن که شروع به ساختن کنیم، بازخورد بگیریم و مدل ذهنی‌مون رو اصلاح کنیم.فرآیند واقعی معمولاً این شکلیه:مدل اولیه → پیاده‌سازی → بازخورد → اصلاح مدل → Refactoringدو اشتباه رایج این وسط وجود داره.اشتباه اول اینه که بخوایم قبل از اینکه مسئله رو واقعاً بشناسیم، همه‌چیز رو طراحی کنیم.یعنی از همان اول همه Aggregateها، سرویس‌ها و مرزهای سیستم رو مشخص کنیم.این کار معمولاً باعث ایجاد انتزاع‌هایی می‌شه که هنوز دلیل واقعی ندارن.اشتباه دوم هم اینه که بدون هیچ مدل ذهنی فقط شروع به اضافه‌کردن قابلیت‌ها کنیم.نتیجه معمولاً یک کدبیس پر از Handler، DTO و سرویس‌های پراکنده است که هیچ زبان مشترکی پشتش وجود نداره.هوش مصنوعی کدنویسی را سریع‌تر می‌کند، نه فهم رااینجا یکی از مهم‌ترین بخش‌های مقاله مطرح می‌شه.هوش مصنوعی می‌تونه خیلی سریع ساختارهایی مثل:RepositoryFactoryMediatorCommand HandlerDomain Eventبسازه.اما سؤال اصلی این نیست که آیا این کد اجرا می‌شه یا نه.سؤال اصلی اینه:آیا ما می‌دونیم چرا این ساختار رو داریم؟اگر جواب این سؤال رو ندونیم، فقط داریم سرعت تولید پیچیدگی رو بیشتر می‌کنیم.مقاله از این موضوع با مفهوم Cognitive Debt یا بدهی شناختی یاد می‌کنه.یعنی وقتی ساختارها و اصطلاحات زیادی وارد سیستم می‌شن، اما تیم واقعاً معنی و دلیل وجودشون رو نمی‌فهمه.مشکل اصلی استفاده از هوش مصنوعی نیست.مشکل وقتی شروع می‌شه که:سرعت تولید کد از سرعت شکل‌گیری فهم مشترک در تیم بیشتر بشه.ارزش یک مهندس ارشد در آینده چیست؟پیام مقاله این نیست که باید با هوش مصنوعی مقابله کنیم.اتفاقاً برعکس؛ باید ازش استفاده کنیم.اما ارزش یک مهندس ارشد فقط در سریع‌تر کدنویسی‌کردن نیست.ارزش اصلی در این چیزهاست:فهمیدن مسئلهٔ واقعی؛پیدا کردن مفهوم‌های درست؛انتخاب واژه‌های دقیق؛طراحی مرزهای مناسب؛مشخص‌کردن قوانین سیستم؛جلوگیری از پیچیدگی‌های غیرضروری.هوش مصنوعی می‌تونه کد تولید کنه، اما هنوز این ما هستیم که باید تصمیم بگیریم چه چیزی ارزش ساختن داره.در نهایت، کد چیست؟کد فقط چیزی نیست که کامپیوتر اجرا می‌کنه.کد بخشی از دانش سیستم ماست؛ جایی که مفهوم‌ها، قوانین و تصمیم‌های طراحی ثبت می‌شن.احتمالاً در آینده تولید کد خیلی ارزان‌تر و سریع‌تر می‌شه، اما فهمیدن مسئله، ساختن مدل درست و ایجاد یک سیستم قابل‌فهم همچنان یکی از مهم‌ترین مهارت‌های مهندسی نرم‌افزار باقی می‌مونه.یک مهندس خوب کسی نیست که فقط کد بیشتری تولید کنه؛ کسیه که بتونه یک مسئله پیچیده رو به مدلی تبدیل کنه که هم انسان‌ها و هم ماشین‌ها بتونن بفهمنش.دربارهٔ مقالهٔ اصلیاین نوشته، برداشت و بازنویسی فارسی از ایده‌های مقالهٔ اصلیه و ترجمهٔ کلمه‌به‌کلمه نیست.عنوان اصلی مقاله: What Is Code?نویسنده: اونمش جوشی (Unmesh Joshi)محل انتشار: وب‌سایت مارتین فاولرلینک مقالهٔ اصلی:https://martinfowler.com/articles/what-is-code.html</description><category>Nima Airyana</category><author>Nima Airyana</author><pubDate>Thu, 06 Aug 2026 15:16:59 +0330</pubDate></item><item><title>استراک تایپ ها در سی شارپ</title><link>https://virgool.ir/@nima.airyana/استراک-تایپ-ها-در-سی-شارپ-uc9dwhplknb7</link><description>خب اول از همه مهمترین نکته که همه میدونیم یا باید بدونیم اینه که استراک ها ولیو تایپ هستنالبته بر خلاف کلاس هاخب چرا این نکته مهمه؟میتونم بگم اصلی ترین دلیلش اینه که مستقیم داخل استک ذخیره سازی میشن و حالت ارجاع (رفرنس) ندارن که این خودش میتونه باعث افزایش چندین برابری شما در پرفرمنستون باشه ، منابع کمتری استفاده بشه و این که ولیو تایپ ها قابل تغییر (mutable) هستن ، این ها عمده دلایل بسیار مهم استفاده از استراک ها هستن که باید حتما بهشون توجه کردمحدویت ها در استراکچر ها نسبت به کلاس هاما نمیتونیم یه سازنده بدون پارامتر داخل استراک داشته باشیم ، هر استراکچری یه دیفالت کاستراکتور داره که بدون پارامتر هستما نمیتونیم فیلد ها یا پراپرتی هامون رو مقدار دهی اولیه کنیم ، البته میشه فیلد ها یا پراپرتی های استاتیک یا کانست رو مقدار دهی اولیه کرد (اینیشیالایز کرد)یه سازنده داخل استراک تایپ باید تمامی فیلد ها رو مقدار دهی کنهنمیتونیم استراکچر ها رو از کلاس یا استراکچر دیگه ای ارث بری کنیم ، البته میشه از اینترفیس ارث بری کردو در آخر نمیشه فاینالایزر (finalizer) داخل استراک تایپ لحاظ کردبر اساس داکیومنت اصلی خود وبسایت مایکروسافت</description><category>Nima Airyana</category><author>Nima Airyana</author><pubDate>Sat, 16 Jan 2021 14:11:26 +0330</pubDate></item><item><title>اعداد بزرگ تر از لانگ در سی شارپ</title><link>https://virgool.ir/@nima.airyana/اعداد-بزرگ-تر-از-لانگ-در-سی-شارپ-srhaqru0eb9m</link><description>اعداد بزرگ تر از لانگ در سی شارپتا حالا شده که اعدادی بزرگ تر از لانگ یا یو لانگ نیاز داشته باشین داخل سی شارپ؟واقعا بزرگتر از یو لانگ مگه میشه نیاز داشت؟ با این حال مایکروسافت فکر اینجا رو هم کرده و یه چیزی به ما میده به اسم بیگ اینتفکر کنین یه چنین عددی نیاز دارین : 6277101735386680762814942322444851025767571854389858533375اوکی توی این حالت چیکار میکنید؟میتونیم از مثال زیر استفاده کنیم برای این کار :BigInteger number = BigInteger.Pow(UInt64.MaxValue, 3);Console.WriteLine(number);// The example displays the following output://    6277101735386680762814942322444851025767571854389858533375واقعا فوق العادستاما نکته مهمی که هست و باید در نظر داشته باشیم ، اینه که بیگ اینتجرها immutable (غیر قابل تغییر) هستن پس پرفرمنستون رو یه مقدار پایین میارنبر اساس سایت مایکروسافت :BigInteger number = BigInteger.Multiply(Int64.MaxValue, 3);number++;Console.WriteLine(number);Although this example appears to modify the value of the existing object, this is not the case. BigInteger objects are immutable, which means that internally, the common language runtime actually creates a new BigInteger object and assigns it a value one greater than its previous value. This new object is then returned to the caller.لینک مقاله ی مربوطه :https://docs.microsoft.com/en-us/dotnet/api/system.numerics.biginteger?view=net-5.0</description><category>Nima Airyana</category><author>Nima Airyana</author><pubDate>Thu, 14 Jan 2021 02:10:20 +0330</pubDate></item><item><title>فالس شدن کل شرط وقتی یکی از شروط NaN باشه (سی شارپ)</title><link>https://virgool.ir/@nima.airyana/فالس-شدن-کل-شرط-وقتی-یکی-از-شروط-nan-باشه-سی-شارپ-qowcsjutzzws</link><description>فالس شدن کل شرط وقتی یکی از شروط NaN باشه (سی شارپ)لس شدن کل شرط وقتی یکی از شروط NaN باشهمیدونستین توی زبان سی شارپ وقتی که یک از شروط NaN باشه باعث میشه که کل شرط به صورت فالس باشه؟بر اساس مقاله مقایسه در داخل سایت مایکروسافت این مورد دقیقا بیان شده ، به عکس زیر توجه کنیدنکته ای که داخل سایت خود مایکروسافت لحاظ شدهبرای مثال :Console.WriteLine(double.NaN &lt; 5.1);   // output: FalseConsole.WriteLine(double.NaN &gt;= 5.1);  // output: Falseلینک منبع مقاله :https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/comparison-operators</description><category>Nima Airyana</category><author>Nima Airyana</author><pubDate>Wed, 13 Jan 2021 23:57:21 +0330</pubDate></item></channel></rss>