BusinessValue با CQS – انجمن DEV

Summarize this content to 400 words in Persian Lang
ساده سخت تر است
چالش
امروز من در مورد یک دوجوی کدنویسی صحبت می کنم که خود کوچکتر و بزرگتر من علیه یکدیگر انجام می دهند. یک توسعه دهنده همیشه در دوجوی کدنویسی فعال است. توسعه دهنده فعال آزاد است که تصمیم بگیرد چه چیزی را توسعه دهد. اما او باید افکار خود را برای توسعه دهنده دیگر توضیح دهد.
شرکتی که آنها برای آن کار می کنند یک سیستم کمک مالی ایجاد کرده است. مردم می توانند مقداری پول اهدا کنند و کل مبلغ همه کمک ها را ببینند. چالش پیش روی Coding Dojo اکنون توسعه بیشتر این سیستم است. نمونه برنامه در GitHub موجود است.
مقالات من را بخوانید تا بفهمید چگونه من [younger](https://medium.com/@kinneko-de/344fe6e8e4f6) و [older](https://medium.com/@kinneko-de/0de8a4351da2) خود این دوجوی کدنویسی را حل کردند.
این یک نمونه تمرین برای کدنویسی دوجو در سی شارپ است.
این برنامه از یک بخش رابط کاربری و یک بخش سرور با یک پایگاه داده تشکیل شده است. همه چیز در یک برنامه برای جلوگیری از پیچیدگی غیر ضروری است. فراخوانی های API به فراخوانی روش کاهش می یابد.
مقالههای من را بخوانید تا بدانید چگونه جوانتر و بزرگتر من این دوجوی کدنویسی را حل کردند.
برنامه را بیشتر توسعه دهید. شما در تصمیم گیری های خود کاملا آزاد هستید
نمونه معماری در دنیای واقعی
در دنیای واقعی، UI روی کلاینت اجرا می شود. رابط کاربری از طریق یک API به سرور دسترسی خواهد داشت.
منابع
تصویر سرفصل با استفاده از قابلیت های تولید تصویر Gemini تولید شده است.
Gemini یک مدل زبان بزرگ است که توسط هوش مصنوعی گوگل توسعه یافته است. این می تواند تصاویر واقعی و متنوع را بر اساس پیام های متنی ایجاد کند. درباره Gemini بیشتر بدانید.
خود بزرگتر من در این مقاله نقش توسعه دهنده فعال را بر عهده خواهد گرفت. مقاله دیگر من را بخوانید تا دریابید که خود کوچکترم در عوض چه کاری انجام می دهد.
کدنویسی دوجو
خود بزرگتر: بیایید ابتدا آنچه را که سرویس انجام می دهد تجزیه و تحلیل کنیم.پول اهدا شده را به پروژه اضافه می کند. سپس مقدار کل پول اهدا شده را انتخاب می کند. بنابراین دو کار انجام می دهد.
خود سفارش دهید: نه به طور کلی. شاید به دلیل اصل مسئولیت واحد به این موضوع بپردازید. به نظر من به طراحی کد بیشتری می پردازد. در این سرویس دو متد پشت سر هم فراخوانی می شوند. اما سرویس و کد باید ابتدا در خدمت کسب و کار باشد، نه برعکس.
اما فکر نمی کنم این سرویس پاسخگوی نیاز مشتری باشد. اهداکننده باید قبل از اینکه ببیند دیگران چه چیزی را قبل از او اهدا کرده اند، پول اهدا کند. شاید بهتر باشد ابتدا پولی را که قبلاً اهدا شده است به آنها نشان دهیم، حتی بدون اینکه آنها مجبور به کمک مالی باشند. این ممکن است آنها را تشویق کند که پول بیشتری اهدا کنند. دومین مورد استفاده برای این گزینه جستجوی جدید این است که صاحب پروژه ببیند چقدر پول قبلاً اهدا شده است.
خود جوانتر: از کدام چارچوب برای حل این مشکل می خواهید استفاده کنید؟
خود بزرگتر: من برای انجام این کار نیازی به چارچوبی ندارم. فقط موضوع تنظیم مجدد کد فعلی است. این یک کار ساده است.من بخش پرس و جو از روش سرویس را حذف می کنم و روش دوم را اضافه می کنم که فقط مقدار کل پول را انتخاب می کند. من الان دو روش در سرویس دارم.
public async Task<int> GetTotalDonations()
{
return await Database.GetTotalDonations();
}
public async Task UpdateDonation(int donation)
{
await Database.AddDonation(donation);
}
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
همچنین باید رابط کاربری را اصلاح کنم. رابط کاربری اکنون می تواند در ابتدا مقدار پول اهدا شده را دریافت کند.
if (firstRender)
{
await GetTotalDonations();
}
private async Task GetTotalDonations()
{
Total = await Server.GetTotalDonations();
}
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
پس از اینکه کاربر مقداری پول اهدا کرد، ما نیز باید مبلغ را به روز کنیم. کاربر نیاز به بازخورد فوری دارد تا احساس کند پولش دریافت شده است.
private async Task Donate()
{
await Server.UpdateDonation(MyDonation);
[…]
await GetTotalDonations();
}
وارد حالت تمام صفحه شوید
از حالت تمام صفحه خارج شوید
مقالات من را بخوانید تا بفهمید چگونه من [younger](https://medium.com/@kinneko-de/344fe6e8e4f6) و [older](https://medium.com/@kinneko-de/0de8a4351da2) خود این دوجوی کدنویسی را حل کردند.
این یک نمونه تمرین برای کدنویسی دوجو در سی شارپ است. از الگوی اهدا کپی شده است
این راه حل کدگذاری دوجوی خود بزرگتر من است.
مقاله من را بخوانید تا دریابید که چگونه خود کوچکتر من این دوجوی برنامه نویسی را حل کرد.
برنامه را بیشتر توسعه دهید. شما در تصمیم گیری های خود کاملا آزاد هستید
خود جوانتر: هنگامی که ما این را به عنوان یک سرویس واقعی مستقر می کنیم، این کار سربار بیشتری را معرفی می کند. هر تماس سربار شبکه را معرفی می کند.
خود بزرگتر: بله حق با شماست. اما تفکیک عملکرد به دو روش سیستم ما را انعطاف پذیرتر می کند. به احتمال زیاد فقط با ترکیب تماس ها با موارد استفاده تجاری مناسب می شود. بنابراین قابلیت نگهداری را بهبود می بخشد. اگر واقعاً مربوط به عملکرد بود، ما فقط میتوانیم کد را کپی کنیم و هر دو روش میتوانستیم کل مبلغ کمک مالی را درخواست کنیم. اما من فکر نمی کنم عملکرد در این مورد استفاده برای ما مرتبط باشد.
خود جوانتر: من می بینم که ما پرس و جو و دستوری را که کمک های مالی را به روز می کند از هم جدا کردیم. این CQRS است، درست است؟
خود بزرگتر: نه واقعا. CQRS برای سرویس های پیچیده تر است که در آن چندین سرویس با پایگاه داده های مختلف داریم. و همچنین در این موارد شما آن را فقط در مرحله بعدی اضافه می کنید که واقعاً می خواهید برای پرس و جوهای پیچیده تر بهینه سازی کنید. اما برای پروژه های کوچک در مراحل اولیه، این کار بیش از حد است.الگویی به نام CQS وجود دارد، اما من این کار را برای افزودن ارزش تجاری به برنامه و نه فقط برای استفاده از یک الگو انجام دادم.
خود جوانتر: جالبه صاحب محصول، کار ما تمام شد.
صاحب محصول: من به بحث شما گوش دادم و واقعا جالب بود. رویکرد ممکن است جالب باشد. اما من می خواهم ابتدا با مشتریان خود در مورد آن صحبت کنم. فعلاً باید کد را در یک شاخه ویژگی نگه داریم. شاید بتوانیم بر اساس مقدار پولی که قبلاً اهدا شده است، کلمات انگیزشی بیشتری نیز اضافه کنیم.
نتیجه گیری
من هر روز بیشتر و بیشتر متوجه می شوم که اجرا به خاطر رضایت شخصی نیست. این در مورد ارائه ارزش تجاری به شرکت است، و این چیزی است که شرکت به من پول می دهد.
پس از سالها توسعه و حفظ کدهای موجود، متوجه شدم که نگهداری زمانبرترین و گرانترین بخش توسعه نرمافزار است. به همین دلیل این روزها راه حل های ساده را ترجیح می دهم. این شامل اصلاح مفاهیم برای ساده نگه داشتن کد تا حد امکان است. چون ساده سخت تر است.
فراموش نکنید که در این مقاله واکنشی بگذارید و سپس امیدوارم در مورد رویکرد جوان ترم بخوانید.
ساده سخت تر است
” loading=”lazy” width=”644″ height=”529″/>
چالش
امروز من در مورد یک دوجوی کدنویسی صحبت می کنم که خود کوچکتر و بزرگتر من علیه یکدیگر انجام می دهند. یک توسعه دهنده همیشه در دوجوی کدنویسی فعال است. توسعه دهنده فعال آزاد است که تصمیم بگیرد چه چیزی را توسعه دهد. اما او باید افکار خود را برای توسعه دهنده دیگر توضیح دهد.
شرکتی که آنها برای آن کار می کنند یک سیستم کمک مالی ایجاد کرده است. مردم می توانند مقداری پول اهدا کنند و کل مبلغ همه کمک ها را ببینند. چالش پیش روی Coding Dojo اکنون توسعه بیشتر این سیستم است. نمونه برنامه در GitHub موجود است.
مقالات من را بخوانید تا بفهمید چگونه من [younger](https://medium.com/@kinneko-de/344fe6e8e4f6) و [older](https://medium.com/@kinneko-de/0de8a4351da2) خود این دوجوی کدنویسی را حل کردند.
این یک نمونه تمرین برای کدنویسی دوجو در سی شارپ است.
این برنامه از یک بخش رابط کاربری و یک بخش سرور با یک پایگاه داده تشکیل شده است. همه چیز در یک برنامه برای جلوگیری از پیچیدگی غیر ضروری است. فراخوانی های API به فراخوانی روش کاهش می یابد.
مقالههای من را بخوانید تا بدانید چگونه جوانتر و بزرگتر من این دوجوی کدنویسی را حل کردند.
برنامه را بیشتر توسعه دهید. شما در تصمیم گیری های خود کاملا آزاد هستید
نمونه معماری در دنیای واقعی
در دنیای واقعی، UI روی کلاینت اجرا می شود. رابط کاربری از طریق یک API به سرور دسترسی خواهد داشت.
منابع
تصویر سرفصل با استفاده از قابلیت های تولید تصویر Gemini تولید شده است.
Gemini یک مدل زبان بزرگ است که توسط هوش مصنوعی گوگل توسعه یافته است. این می تواند تصاویر واقعی و متنوع را بر اساس پیام های متنی ایجاد کند. درباره Gemini بیشتر بدانید.
خود بزرگتر من در این مقاله نقش توسعه دهنده فعال را بر عهده خواهد گرفت. مقاله دیگر من را بخوانید تا دریابید که خود کوچکترم در عوض چه کاری انجام می دهد.
کدنویسی دوجو
خود بزرگتر: بیایید ابتدا آنچه را که سرویس انجام می دهد تجزیه و تحلیل کنیم.
پول اهدا شده را به پروژه اضافه می کند. سپس مقدار کل پول اهدا شده را انتخاب می کند. بنابراین دو کار انجام می دهد.
خود سفارش دهید: نه به طور کلی. شاید به دلیل اصل مسئولیت واحد به این موضوع بپردازید. به نظر من به طراحی کد بیشتری می پردازد. در این سرویس دو متد پشت سر هم فراخوانی می شوند. اما سرویس و کد باید ابتدا در خدمت کسب و کار باشد، نه برعکس.
اما فکر نمی کنم این سرویس پاسخگوی نیاز مشتری باشد. اهداکننده باید قبل از اینکه ببیند دیگران چه چیزی را قبل از او اهدا کرده اند، پول اهدا کند. شاید بهتر باشد ابتدا پولی را که قبلاً اهدا شده است به آنها نشان دهیم، حتی بدون اینکه آنها مجبور به کمک مالی باشند. این ممکن است آنها را تشویق کند که پول بیشتری اهدا کنند. دومین مورد استفاده برای این گزینه جستجوی جدید این است که صاحب پروژه ببیند چقدر پول قبلاً اهدا شده است.
خود جوانتر: از کدام چارچوب برای حل این مشکل می خواهید استفاده کنید؟
خود بزرگتر: من برای انجام این کار نیازی به چارچوبی ندارم. فقط موضوع تنظیم مجدد کد فعلی است. این یک کار ساده است.
من بخش پرس و جو از روش سرویس را حذف می کنم و روش دوم را اضافه می کنم که فقط مقدار کل پول را انتخاب می کند. من الان دو روش در سرویس دارم.
public async Task<int> GetTotalDonations()
{
return await Database.GetTotalDonations();
}
public async Task UpdateDonation(int donation)
{
await Database.AddDonation(donation);
}
همچنین باید رابط کاربری را اصلاح کنم. رابط کاربری اکنون می تواند در ابتدا مقدار پول اهدا شده را دریافت کند.
if (firstRender)
{
await GetTotalDonations();
}
private async Task GetTotalDonations()
{
Total = await Server.GetTotalDonations();
}
پس از اینکه کاربر مقداری پول اهدا کرد، ما نیز باید مبلغ را به روز کنیم. کاربر نیاز به بازخورد فوری دارد تا احساس کند پولش دریافت شده است.
private async Task Donate()
{
await Server.UpdateDonation(MyDonation);
[...]
await GetTotalDonations();
}
مقالات من را بخوانید تا بفهمید چگونه من [younger](https://medium.com/@kinneko-de/344fe6e8e4f6) و [older](https://medium.com/@kinneko-de/0de8a4351da2) خود این دوجوی کدنویسی را حل کردند.
این یک نمونه تمرین برای کدنویسی دوجو در سی شارپ است. از الگوی اهدا کپی شده است
این راه حل کدگذاری دوجوی خود بزرگتر من است.
مقاله من را بخوانید تا دریابید که چگونه خود کوچکتر من این دوجوی برنامه نویسی را حل کرد.
برنامه را بیشتر توسعه دهید. شما در تصمیم گیری های خود کاملا آزاد هستید
خود جوانتر: هنگامی که ما این را به عنوان یک سرویس واقعی مستقر می کنیم، این کار سربار بیشتری را معرفی می کند. هر تماس سربار شبکه را معرفی می کند.
خود بزرگتر: بله حق با شماست. اما تفکیک عملکرد به دو روش سیستم ما را انعطاف پذیرتر می کند. به احتمال زیاد فقط با ترکیب تماس ها با موارد استفاده تجاری مناسب می شود. بنابراین قابلیت نگهداری را بهبود می بخشد. اگر واقعاً مربوط به عملکرد بود، ما فقط میتوانیم کد را کپی کنیم و هر دو روش میتوانستیم کل مبلغ کمک مالی را درخواست کنیم. اما من فکر نمی کنم عملکرد در این مورد استفاده برای ما مرتبط باشد.
خود جوانتر: من می بینم که ما پرس و جو و دستوری را که کمک های مالی را به روز می کند از هم جدا کردیم. این CQRS است، درست است؟
خود بزرگتر: نه واقعا. CQRS برای سرویس های پیچیده تر است که در آن چندین سرویس با پایگاه داده های مختلف داریم. و همچنین در این موارد شما آن را فقط در مرحله بعدی اضافه می کنید که واقعاً می خواهید برای پرس و جوهای پیچیده تر بهینه سازی کنید. اما برای پروژه های کوچک در مراحل اولیه، این کار بیش از حد است.
الگویی به نام CQS وجود دارد، اما من این کار را برای افزودن ارزش تجاری به برنامه و نه فقط برای استفاده از یک الگو انجام دادم.
خود جوانتر: جالبه صاحب محصول، کار ما تمام شد.
صاحب محصول: من به بحث شما گوش دادم و واقعا جالب بود. رویکرد ممکن است جالب باشد. اما من می خواهم ابتدا با مشتریان خود در مورد آن صحبت کنم. فعلاً باید کد را در یک شاخه ویژگی نگه داریم. شاید بتوانیم بر اساس مقدار پولی که قبلاً اهدا شده است، کلمات انگیزشی بیشتری نیز اضافه کنیم.
نتیجه گیری
من هر روز بیشتر و بیشتر متوجه می شوم که اجرا به خاطر رضایت شخصی نیست. این در مورد ارائه ارزش تجاری به شرکت است، و این چیزی است که شرکت به من پول می دهد.
پس از سالها توسعه و حفظ کدهای موجود، متوجه شدم که نگهداری زمانبرترین و گرانترین بخش توسعه نرمافزار است. به همین دلیل این روزها راه حل های ساده را ترجیح می دهم. این شامل اصلاح مفاهیم برای ساده نگه داشتن کد تا حد امکان است. چون ساده سخت تر است.
فراموش نکنید که در این مقاله واکنشی بگذارید و سپس امیدوارم در مورد رویکرد جوان ترم بخوانید.