Make generic client services in SignalGo that will help you to remove duplicate classes with the same methods

با استفاده از نسخه جدید سیگنالگو میتوانید سرویس های کلاینت را به صورت جنریک بسازید تا از تکرار شدن کلاس های سرویس ها با توابع یکسان جلوگیری کنید
@csharptips

بنابه دلایلی مجور شدیم توی یکی از پروژه هامون از کد جنریتور swagger در یکی از پروژه های ABP استفاده کنیم، وقتی اینکار رو کردیم تازه متوجه شدیم چقدر ما مباحث و مشکلات رو توی سیگنالگو و کدجنریتورش دیدیم و حل کردیم، مشکلاتی از جمله مدیریت فضای نام ها، skip کردن dll ها و حتی replace کردن فضای نام ها، ساپورت کامل Generic ها در انواع خروجی ها و اینکه به برنامه نویس این اجازه رو دادیم تا خروجی مورد نظرش رو هرجور دوست داره بسازه و حتی توی کد جنرتور انگولار و سی شارپ وقتی از سوئگر استفاده کردیم همیشه باید یه سری ویرایش ها انجام میدادیم به خاطر اشتباهات و باگ هایی که داره و حتی از حوصله ما خارجه بخوایم بریم باگ های سوئگر رو رفع کنیم در حالی که سیگنالگو همه ی این نیاز های مارو برطرف میکرد و توسعه دهندش خودمون بودیم و رفع باگهاش هم برامون بسیار راحت بود.
مباحثی مثل تغییر پروتکل ها و استفاده استاندارد و دقیق توی تست کیس ها که به طور 100% مباحث Type safe توش رعایت شده باشه، یکی از دغدغه های ما بود که واقعا توی این زمینه موفق عمل کردیم و امیدوارم یه روزی بتونیم این رو با حمایت برنامه نویسان جهانی کنیم.
کارهایی که ما توی مدیریت Generic ها کردیم حتی هنوز توی فیچر لیست های asp core و سوئگر نیستند و اینکه بتونیم با کمترین میزان کد زدن میکروسرویس هارو پیاده سازی کنیم و خیالمون از کمتر و کمتر شدن باگ ها راحت باشه.
البته منظورم از میکروسرویس ها ساختار استاندارد و عمومی ای که وجود داره نیست، در ساختاری که ما ساختیم چیزی به نام Core وجود داره و عجیب اینکه هرجا توی ساختار به پیچیگی خوردیم برای ما به صورت منطقی مشکلات رو حل و فصل کرد و مارو قانع کرد که این ساختار صحیحه.
به محض Stable شدن ساختاری میکروسرویس های خودمون، حتما کتابی منتشر خواهم کرد و اونو توضیح میدم و متوجه over engineering و فاجعه ای به نام Dependency Injection در زبان برنامه نویسی سی شارپ (و دیگر زبان های Type safe) خواهید بود که امروز بسیار از اهدافش دور شده و زبان برنامه نویسی سی شارپ با کپی کردن از دیگر زبان ها داره با فیچر ها خودش رو نگه میداره، اما ساختار های سمی ای که از شرکت های بسیار بزرگی مثل مایکروسافت حمایت شده باعث شده برنامه نویسان چشم بسته ساختار هاش رو بپذیرن و حتی به خودشون اجازه نقد و انتقاد به ساختار های شرکت هایی مثل گوگل و مایکروسافت و فیسبوک ندن. البته من متوجه این موضوع شدم که ماها موش های آزمایشگاهی در گیتهاب برای اونها هستیم.تعبیر درستی نیست ولی اینکه هر سال معماری ها رو تغییر میدن و مارو از این شاخه به اون شاخه منتقل میکنن یعنی هنوز به یک سیستم و ساختار یکپارچه نرسیدن و دارن از ما استفاده میکنن و متوجه اش نیستیم و خوشحالیم که هر بار تکنولوژی جدید معرفی میکنن در حالی که از ما زمان برای یادگیری میگیرن.

@csharptips

ساپورت کردن Value Tuple ها توی C# 7 یکی از فیچر هایی هست که ما توی سیگنالگو رفعش کردیم ولی این درخواست از سال 2017 توی سوئگر هنوز حل نشده.خیلی واسه ما مهم بود که کد ها وقتی برای کلاینت جنریت میشه تمیز و خوانا باشه:
https://github.com/domaindrivendev/Swashbuckle.AspNetCore/issues/501

شاید توی سی شارپ 9 قابلیت Record زیاد به چشمتون بیاد و بلافاصله بخواید ازش استفاده کنید، بذارید چند تا نکته رو بهتون قبل از استفاده از این قابلیت گوشزد کنم:

1.سی شارپ یک زبان Strongly Type هست، رفتن سی شارپ به سمت قابلیت هایی که در زبان های پایتون و جاوا اسکریپت و php و دارت و دیگر زبان های داینامیک برای راحت کد زدن وجود داره به معنی خوب بودن اون قابلیت ها نیست بلکه یک سیاست توی سی شارپ برای جذب مشتری و دولوپر های بیشتر هست، بنابراین اینکه شما یک کلاس رو توی سی شارپ اینطوری بنویسید:
public record Person (string Name,int Age);

توانایی کامنت گذاری برای پارامتر ها رو نخواهید داشت و از مولفه اصلی تمیز کد زدن فاصله میگیرید.

2.این قابلیت یک مشکل پروفورمنسی داره و علتش اینه که با اشاره گر ها کار نمی کنه و تمامی پارامتر ها رو موقع Equal مورد بررسی قرار میده، در نتیجه وقتی جایی از برنامه میخواد برابر بودن اون رو با یک آبجکت دیگه مورد بررسی قرار بده کلیه پارامتر ها رو بررسی میکنه، شاید برای برنامه نویسی رابط کاربری مهم نباشه اما توی برنامه نویسی بک اند و رکوئست های زیاد و همزمان پرفورمنس رو تحت تاثیر قرار میده.

3.زبان برنامه نویسی سی شارپ یکمی داره از اون هدف اصلیش دور میشه و به جای متمرکز شدن روی قابلیت های Strongly Type سعی در این داره که شبیه زبان های دیگه بشه بهمین علت شما در نسخه های اخیر بدون نوشتن کلاس و متد Main مثل پایتون میتونید با یکی دو خط کد برنامه سازی کنید.بنابراین سعی کنید از همه ی قابلیت های سی شارپ استفاده نکنید چون اکثرشون برای آموزش راحت تر به دانش آموزان و رقابت با زبان های برنامه نویسی دیگه ساخته میشه و شاید کاربرد آنچنانی نداشته باشه جز اینکه زبان برنامه نویسی رو پیچیده تر کنه.

@CSharpTips

دو تا از مهمترین مولفه هایی که Dependency Injection باعث کندی پرفورمنس توی سیستم شما و شلخته شدن معماری پروژه شما میشه اینا هستند:

1.شما در یک کلاس سرویس دوتا interface رو inject میکنید در حالی که ممکنه در بعضی از سرویس هاتون (متد هاتون) از اونا استفاده نکنید.این یعنی بخواید نخواید اون Dependency توی constructor کلاس inject خواهد شد و علاوه بر اینکه اینکار یک سربار اضافه بر روی سرویس های شماست حتی اینکه چرا از اون کلاس inject شده استفاده نمی کنید ولی اونو inject میکنید و یا در فیلد های کلاس شما هست خودش مساله هست که معماری سیستم شمارو زیر سوال میبره.بنابراین راه کار اینه که کلاسیرو inject کنید که حتما از اون توی تمامی سرویس ها استفاده میکنید یا اگر نمی کنید توابع رو در یک سرویس جداگانه بزنید که این عمل هم خودش ممکنه باعث زیاد شدن کلاس های سرویس ها به ازای هر interface ای که inject میکنید بشه.

2.به طور کلی استفاده از عملیات runtime برای instance گرفتن کلاس ها از طریق Activator.CreateInstance و روش های دیگه ی Runtime چندین برابر نسبت به عملیات کامپایل تایم کند هست.یعنی شما اگر به صورت دستی یک کلاس رو new کنید صد ها برابر سریعتر از کلاسی هست که به صورت runtime در حافظه new میشه.در Dependency Injection به طور کاملا صد در صد کلاس های سرویس شما به ازای هر بار صدا زدن توسط Activator در حافظه new میشن و همونجا هم constructor هایی که باید inject بشن هم new یا به صورت cache توی اون کلاس inject میشن نمیتونم بگم این عملیات چقدر کند هست اما وقتی این اتفاق توی بک اند کم کم اتفاق میوفته به قول معروف قطره قطره جمع شود وانگهی دریا شود، سیستم شما رو بشدت کند میکنه و شما کماکان دنبال کدهایی در ساختار خودتون برای بالا بردن پرفورمنس میگردید در حالی که مشکل از جای دیگه آب میخوره.

#CSharp
#Dependency_Injection
@CsharpTips

SignalGo 5.0 Performance vs Asp Net Core 5.0
Without JsonGo and version 6.0

1000 request concurrent

------
SignalGo Self Host Net Core 3.1 Debug:
------
TotalTime: 7591.359 ms
finish Success :1000 Fail :0
Success Min Time: 433 ms
Success Max Time: 7564 ms
______________________________________

------
Asp Core Self Host Net 5.0 Release
------
TotalTime: 15128.056 ms
finish Success :1000 Fail :0
Success Min Time: 1591 ms
Success Max Time: 15094 ms
______________________________________

------
Asp Core Self Host Net 3.1 Release
------
TotalTime: 26935.405 ms
finish Success :1000 Fail :0
Success Min Time: 1698 ms
Success Max Time: 26917 ms
______________________________________

آیا شما از سیگنالگو استفاده می کنید؟ Are you using SignalGo?
anonymous poll

بله Yes – 5
👍👍👍👍👍👍👍 29%

خیر No – 5
👍👍👍👍👍👍👍 29%

در آینده استفاده می کنم I will use in the future – 4
👍👍👍👍👍👍 24%

قبلا استفاده می کردم I already use – 3
👍👍👍👍 18%

👥 17 people voted so far.

یه جوری کد میزنی انگاری که دیرته
نوشتن باگهاتم جزئی از تقدیرته

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

چی میشه باگ هاتو رفع بکنی
همه ی تست هاتو پس بکنی

تقصیر من چیه آرزوش این شده
کارتو تموم کنم بعد خودکشی

تو سال 2017 وقتی بک اند برخی پروژه هامون رو با WCF زدیم و خواستیم کلاینت اندروید هم داشته باشیم، در نتیجه تصمیم گرفتیم کلاینت اندروید رو با جاوا بزنیم و وقتی زدیم متوجه شدیم WCF به صورت Duplex کلاینت های جاوا رو ساپورت نمی کنه، کار سخت شد شروع کردیم تحقیق کردن و مجبور شدیم ابزار رو عوض کنیم در نتیجه SignalR رو انتخاب کردیم، سیگنال آر گزینه خوبی بود و تا جای ممکن کارمون رو راه انداخت اما توی اسکیل های بزرگ تر به مشکلات جبران ناپذیری خوردیم که دیگه برامون پروژه قابل توسعه نبود، پیشنهاد دادم به مدیرمون که میتونیم خودمون ابزاری بسازیم که ارتباط بین کلاینت و سرور رو خودمون مدیریت کنیم، بعد از موافقت مدیریت شروع به ساختن پروژه ی SignalGo کردیم و تا به امروز خیلی پروژه ها رو باهاش توسعه دادیم همه نقطه ضعف ها و مشکلاتی که داشت رو حل و رفع کردیم و همچنان در حال توسعه اون هستیم.
حالا امروز بعد از انتشار دات نت 5 میبینم که WCF دیگه توسعه داده نمیشه و مایکروسافت به طور مستقیم دیگه از اون پشتیبانی نمی کنه.
حالا ابزار های سیگنالگو با بیش از 60 هزار دانلود توی nuget مایکروسافت همچنان با قدرت ادامه میده 👌💪💪
#به_ما_بپیوندید

#تخصصی
#سی_شارپ
#پرفورمنس

یکی از کارهایی که شما میتونید با سی شارپ انجام بدید تا دسترسی مستقیم به یک مقدار توی حافظه از یک متغیر داشته باشید استفاده از StructLayout هست.
در مثال زیر اگر شما مقدار value رو تغییر بدید مقادیر 4 بایت در حافظه در متغیر های byte0 تا byte3 تغییر میکنن.برای همین شما نیاز به BitConverter ندارید تا یک عدد رو به یک ارایه از بایت ها تبدیل کنید.
یکی از دلایلی که JsonGo از بقیه serializer ها سریعتر عمل میکنه (حتی سریالایرز های unsafe)
مثال:

    [StructLayout(LayoutKind.Explicit)]
    public ref struct IntStruct
    {
        [FieldOffset(0)]
        public byte byte0;
        [FieldOffset(1)]
        public byte byte1;
        [FieldOffset(2)]
        public byte byte2;
        [FieldOffset(3)]
        public byte byte3;

        [FieldOffset(0)]
        public int Value;
    }

@CsharpTips

#سی_شارپ
#تست
#آزمایشگاه

یکی از ابزارهای تست ابزار Mock کردن تست هاست، ابزارهایی توی سی شارپ و زبان های برنامه نویسی وجود دارن که شما میتونید باهاشون مدل های آزمایشگاهی خودتون رو کمی به واقعیت نزدیک کنید و برای پروژه خودتون تست بنویسید.
اما آیا این تست ها 100% واقعی بودن و به واقعیت نزدیک بودن تست شمارو تضمین میکنن؟ خیر، آیا تا بحال بهش فکر کردید؟ چقدر فرق میکنن؟
ببینید توی تست های Mock چند تا اتفاق بد میوفته:
1.شما حتما باید یک فضای اضافی برای Mock کردن کلاس هاتون بسازید، این یعنی اینکه حتما مجبورید برای نوشتن Mock اینترفیس داشته باشید و حتما کلاس های اصلی پروژه تون درگیر داشتن اینترفیس هایی میشن که میتونستن هیچوقت وجود نداشته باشن. یعنی باید برنامه نویسی کنید.
از نظر من تست بالاترین لایه ی سیستم هست، معماری پروژه شما نباید بدونه شما دارید براش تست می نویسید، در نتیجه نباید کدهای لایه ی پایین اپلیکیشن خودتون رو درگیر کد های لایه بالاتر کنید، این یعنی پیچیدگی و پیچیدگی = مرگ
فرض رو بر این بگیرید که اصلا قرار نیست پروژه های سطح پایین درگیر خراب کاری هایی که شما سمت تست می کنید بشن.حالا چیکار میکنید؟
2.فرایندها به طور 100% واقعی تست نمیشن، مثلا وقتی شما یک سرور خارجی رو به صورت Rest صدا میزنید این سرور ممکنه خروجی xml یا json داشته باشه آیا همه ی فرایند های serialize و deserialize و post و get و ارتباط های شبکه ای شما هم با سرور مورد نظر تست میشه؟ Exception های اون سرور چطور؟ هیچ کدوم؟ پس این سرور mock فقط قراره یه سری داده رو بگیره و بفرسته؟ همون ورودی و خروجی های خودمون؟

اگر هنوز فکر میکنید دارم اغراق میکنم سر بزنید به لینک زیر تا ببینید چرا برنامه نویس ها نمیتونن یک کلاس HttpClient رو Mock کنند و دست به دامن تغییرات زیادی توی کدهاشون شدن:
https://stackoverflow.com/questions/36425008/mocking-httpclient-in-unit-tests

حالا اینارو گفتم که بعدش چه چیزی گفته باشم؟
ما توی شرکتمون ابزاری ایجاد کردیم به نام Laboratory و نام مدل های آزمایشگاهی اونو گذاشتیم Mockup کاری که این ابزار میکنه اینه که به صورت 100% فرایند تست Mock شمارو تضمین میکنه و به شکل یک سرور واقعی اما به صورت مجازی موقع تست های شما در پشت صحنه اجرا میشه و تمامی فرایند های پروژه شما از ابتدا تا انتها و حتی بعد از HttpClient ها و ... جایی که حتی Header ها رو میتونید برگردونید جایی که دقیقا یک پورت http گوش بزنگه تا httpClient شما بهش رکوئست بزنه تا به صورت واقعی درخواست های xml یا json یا ... رو به سرویس های شما برگردونه.
حالا دیگه نه نیازی دارید interface های اضافه بسازید، نه نیاز دارید که حتی یک خط اضافه توی لاجیک هاتون به خاطر Mock کردن پروژه بزنید اعم از ساختن interface ها یا حتی تغییرکد ها توی تست کیس ها تنها کاری که میکنید یه سری Resource میسازید تا در فرایند تست سرور به صورت مجازی لود بشه و داده هارو مجازی سازی کنه.

@csharptips

همراه با آهنگ بخونید 😆

باگ
چشم بسته کد رو بهت دادم
با پای خودم به دامت افتادم
دیگه چی میخوای از جون دیباگم

باگ
تو که معماری رو از قبلش دیدی
بهم میریزی هی مگه مریضی
با این همه باز چه سپیچی

باگ
سوسه ای وسط پیشونی
یه کدی که تا همیشه میمونی
به جون خودت درد بی درمونی

باگ
یه کد کثیف پر طرفداری
حیف تو فقط که مردم آزاری
داری میکنی برده داری

آهای عالیجناب باگ
هیچی نمی کنی لاگ
حریف تو نمیشه
هیچ تستی توی دیباگ

منو بی تستام میخوای
تو اینجوری خوشی باگ
ولی بازم دمت گرم
چه زیبا میکشی تایم

.
.
.
.
.
.



باگ
با توام ای کد هرجایی
چیزی نمونده چون آخرایی
بعد فکر میکنی آخر دنیایی

باگ
منه منگ توی گشت شبونه
گاهی حتی با قطر بالاخونه
فکر میکنی خیلی آسونه



آهای عالیجناب باگ
زدم یدونه وبلاگ
بگم خسته شدم باز
شدم از دستت هلاک


منو بی تستام میخوای
تو اینجوری خوشی باگ
ولی بازم دمت گرم
چه زیبا میکشی تایم

@CSharpTips

در معماری نرم افزار بخصوص Back-End اونم توی معماری میکروسرویس ها پرفورمنس بسیار مساله مهمی هست، بحث فقط سرعت بازدهی به مشتری نیست، بلکه شامل هزینه هایی که برای شرکت ها در نظر گرفته میشه هم هست، شما با استفاده از یک معماری خوب و ساختار چینی درست و بالا بردن پرفورمنس سیستم میتونید برای شرکتتون هزینه های کمتری برای بروزرسانی، پهنای باند و حتی تعداد سرور ها در نظر بگیرید، فکرشو بکنید یک شرکت بزرگی میشید مثل مایکروسافت و سالانه هزاران یا میلیون ها دلار صرف نگهداری سرور ها میکنید، در حالی که با یک کد خوب میتونید هزاران دلار صرفه جویی کنید چون معمولا توی بالانس کردن سرویس هاتون به کیس های بیشتری نیاز خواهید داشت پس اگر کد بهینه بزنید توی پروژه های بزرگ تعداد کیس ها و سرورها کمتر خواهد شد
@csharptips

چندتا چیز مهم رو هیچوقت یادتون نره:
1.همه چیز توی اینترنت نیست
2.تا جای ممکن وابستگی هاتون رو پایین بیارید
3.از ابزار هایی که سیستم شمارو به سیستم خودشون وابسته و برای تغییر شمارو درگیر هزینه های زیادی میکنن دوری کنید
4.فراموش نکنید شرکت های بزرگ نادان نیستن که بهترین ابزارهاشونو لقمه کنن و بدن شما استفاده کنید قطعا شما ازمایشگاهشون هستید اونا بهترین ایده ها و بهترین کارهاشونو برای خودشون نگه میدارن
5.مطالعه خوبه تا خلاقیت خودتون و راه خودتون رو پیدا کنید، تقلید و استفاده کننده نباشید اینکار بشدت شمارو کند و بعد از مدتی ضعیف و بی اعتبار میکنه
6.به چالش بکشید و دنبال چالش های جدید باشید تا پیشرفت کنید هیچ سیستمی رو بهترین ندونید معماری بی نقض نداریم همه چیزو زیر سوال ببرید و راه کار جدید و بهتر ارائه کنید تا جا برای پیشرفت بذارید به چالش کشیدن با ارائه راهکار بهتر با معنیه وگرنه ارزشی نداره
7.همیشه توی شرکت ها دوتا هدف رو دنبال کنید یکی موفقیت خودتون یکی موفقیت شرکت و همکارانتون اگر دومی رو از دست بدید غمگین نمیشید.
شمام اگر نکته ای دارید اضافه کنید..
@CsharpTips

مقایسه کارکرد فیلد و پراپرتی در کلاسهای سی شارپ

https://youtu.be/BA3mpAyRbCU

سه تا نکته مهم در مورد Field و پروپتری:
1.فیلد ها پروفورمنس بیشتری در حالت اجرای get و set توی کلاس شما دارن، یکی از علت هاش اینه که پروپتری ها خودشون دارای دو متد get و set هستند حتی به صورت پیشفرض get و set خالی هم بذارید پرفورمنس اجرای کد رو پایین میارن.بنابراین یکی از پیشنهادات خودم اینه که موقعی بحث پروفورمنس خیلی مطرح هست حتما از فیلد ها به جای پروپرتی ها استفاده کنید.
2.علت بوجود اومدن پروپرتی ها قابلیت بارگذاری یا override کردن مقادیر get و set در اونهاست، بنابراین توی binding های برنامه نویسی کلاینت توی WPF شما نمیتونید از field ها انتظار داشته باشید در هنگام تغییرات پروپرتی های بایند شده رو براتون بروزرسانی کنن و خیلی مهم هست که حتما اونجا از پروپرتی استفاده بشه.
3.و مساله بعدی Entity framework هست وقتی شما از پروپرتی استفاده میکنید EF میاد و اونارو توی کلاس جدید برای Change Tracker خودش override میکنه برای همین موقعی که شما میخواید یک مدل دیتابیسی رو ویرایش کنید میتونید بدون کد اضافی یک پروپرتی رو توی دیتابیس ویرایش کنید اما اگر از field استفاده میکردید change tracker نمیتونست تشخصی بده شما چه وقتی فیلد یک مدل دیتابیسی رو تغییر دادید.علتش اینه که توی سی شارپ از طریق Emit و Reflection ها توانایی ساخت یک متد برای فیلد ها وجود نداره و فیلد ها مستقیما اشاره به مقدار یک متغیر توی حافظه میکنن نه مقدار یک متد توی حافظه برای همین قابلیت این رو ندارن که شما اونارو توی حافظه مجدد بسازید یا تغییرشون بدید.

@CSharpTips

پروژه اپن سورس BinaryGo Preview 8 ریلیز شد.
این پروژه توی سریالازر باینری نزدیک به دوبرابر سرعت بیشتری نسبت به سریالایزر grpc protobuf داره.
علاوه بر این، مزیت بزرگ دیگه ای که این ابزار نسبت به ابزار های مشابه مثل grpc داره اینه که شما لازم نیست بالای کلاس ها و پروپرتی هاتون Attribute بذارید یا فایل های proto بسازید. یعنی کد هاتون کلین و بدون Dependency به پکیج باقی میمونن.
سورس پکیج:
https://github.com/Ali-YousefiTelori/BinaryGo

نصب پکیج:
https://www.nuget.org/packages/BinaryGo

@CSharpTips

یکی از مشکلاتی که شما ممکنه توی استفاده از GRPC یا MessagePack یا ZeroBuffer بخورید مبحث backward-compatibility هست.

فرض کنید شما میخواهید مدل های سرویستون رو بروزرسانی کنید، چندتا رو حذف کنید و یکم اونارو مرتب کنید، خوب برای مرتب کردن سعی میکنید ایندکس ProtoMember رو تغییر ندید، ولی مطمئنا برای حذف کردن نمیتونید به این راحتی تصمیم بگیرید، برای همین توصیه ای که شده اینه که اونارو منقضی کنید و دست بهشون نزنید و کم کم یه برنامه زمانی براش بذارید تا اونارو به طور کامل حذف کنید.
چه اتفاقی میوفته این وسط:
1.کدهاتون شلخته و کثیف میشه، یعنی چیزهای اضافه ای دارید که دوست دارید حذف کنید ولی نمیتونید به این سادگی اینکار رو انجام بدید
2.معماری ای که میخواستید بچینید و مرتب باشه کم کم توی ده ها میکروسرویس داره توسط صد ها اتریبیوت ProtoMember فقط برای یکم پرفورمنس بهم میریزه و فردا که خواستید تغییرش بدید باید کلی چیز اضافه از توی مدل هاتون پاک کنید. یعنی وابستگی
این مورد رو برای تغییر انواع هم خواهید داشت مثلا اگر یک نوع int رو به string یا بالعکس تغییر بدید سیستم شما با خطا مواجه میشه.

میبینید، من همیشه مخالف این هستم که از یک پکیجی استفاده کنم که فردا برای چهار تا تغییر ذهنم رو هزار جا درگیر کنه و نتونم ریفکتور و تمیز بودن پروژه هامو هندل کنم.شاید این موضوع توی میکروسرویس ها زیاد معضل نباشه چون بهر حال میگید ما پنجاه تا میکروسرویس رو ویرایش میکنیم درست میشه.
ولی وقتی بحث کلاینت در میون باشه دیگه نمیتونید کاری بکنید، شما نمیتونید اپلیکیشن های کلاینت رو بزور بروزرسانی کنید اینطوری شما براحتی backward-compatibility رو میبرید زیر سوال.

ما توی BinaryGo این معضل بزرگ رو حل کردیم، علاوه بر اینکه شما اتریبیوت و وابستگی ندارید حتی ساختاری به نام StructureChanged برای breacking changes و backward-compatibility بوجود اوردیم که هیچ مشکلی برای تغییر مدل ها بوجود نمیاره 😊
@CSharpTips

جدیدترین پکیجی که شروع کردم به نوشتن CodeReviewer هست، این پکیج قراره فقط به پروژه های تست شما اضافه بشه و یه سری تست کیس جدید به پروژه هاتون اضافه میکنه فرض کنید شما یکسری برنامه نویس تازه کار توی شرکتتون دارید که برخی از اصول های برنامه نویسی رو رعایت نمی کنند این پکیج قراره کار کد رویو رو برای شما آسون تر کنه، برای مثال اگر کسی توی نام گذاری پروپرتی ها یا کلاس های سی شارپ PascalCase رو رعایت نکنه یه سری تست ها Pass نمی شن و بهش هشدار میدن که کجا رو اشتباه کد زده، هرچند ویژوال استادیو خودش یه سری پیشنهاداتی برای اینکار داره اما دوتا نکته هست:
1.برنامه نویس های تازه کار همه چیز رو نمیدونن و از همه ی قابلیت های سی شارپ استفاده نمی کنند و همیشه شما باید کدهاشون رو چشمی Review کنید.
2.برای خیلی مسائل مثل Validation ها و اتریبیوت های خاص که باید برای یه سری کدها زده بشه همیشه ویژوال استادیو نمیتونه کمکتون کنه و شما برای اینکه به برنامه نویس هاتون یاد بدید که اصول و معماری رو درست رعایت کنند همیشه نیاز به رویو کردن کدهاشون دارید.

هرچند این پکیج رو تازه شروع به نوشتن کردم اما توی خیلی مسائل مخصوصا زمانی که از Pipeline های Azure استفاده میکنید تا تست ها پس بشه سپس پروژه ریلیز بشه کاربرد های جالبی میتونه داشته باشه.
هدف اصلی این پکیج انجام تست کیس هایی روی کدهای برنامه نویسان برای رعایت مسائل Clean Code و معماری پروژه هاتون هست.
پروژه Open Source هست و حتی خودتون هم میتونید جزو توسعه دهندگان اون باشید.
https://github.com/Ali-YousefiTelori/CodeReviewer

پکیج:
https://www.nuget.org/packages/CodeReviewer

@CSharpTips

تست بی کد 😆 این قسمت آهنگ خاطره انگیز رگ خواب از محسن یگانه:

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

تو اجرا نکردی کد مشکوکم رو
ندیده گرفتی تست بی کدم رو

با این آرزویی که بی تست محاله
یه خط کد با مفهوم، فقط یک خیاله

چقدر حیفه این تست
همینجور هدر شه
یروزی یه کاربر بره دست به کار شه، بره دست به سر شه!

باید سر کنم با
همین تست خالی
حالا باگ رو سرور بگو در چه حالی

تو اجرا نکردی کد مشکوکم رو
ندیده گرفتی تست بی کدم رو

با این آرزویی که بی تست محاله
یه خط کد با کامنت، فقط یک خیاله

نکته آموزشی: توی ویژوال استادیو تست های تو خالی پس می شوند چون هیچ Assert ای ندارند 😳😆

@CsharpTips