برنامه نویسی

از رفع اشکال تا بهترین روش ها: مشارکت های منبع باز من در ChatCraft و xUnit

Summarize this content to 400 words in Persian Lang

روابط عمومی اول

این وبلاگ در مورد دو روابط عمومی است که من در این هفته ساختم. اگر آخرین وبلاگ من را در مورد مشارکت من در ChatCraft خوانده باشید، جایی که من روی منوهای Ask و Retry کار کردم، می دانید که من یک جزء قابل استفاده مجدد برای آن منوها ارائه کرده ام. در حین کار روی آن موضوع، یک باگ را کشف کردم.

این اشکال زمانی رخ داد که شما یک پاسخ را دوباره امتحان کردید—گاهی اوقات درخواست در سمت LLM ناموفق بود، اما هیچ پیام خطایی در ChatCraft نمایش داده نمی شد. برای رفع این مشکل، من یک مشکل را باز کردم، یک ویدیو نشان دادم که این اشکال را نشان می دهد، و از نگهدارنده پرسیدم که آیا می توانم روی آن کار کنم.

پس از دریافت تاییدیه نگهدارنده برای کار روی این موضوع، شروع به بررسی موضوع کردم. اولین کار من این بود که تابعی را که مسئول فراخوانی API برای اقدام مجدد است، پیدا کنم. من با بررسی مؤلفه‌ای که دکمه تلاش مجدد را ارائه می‌کند، شروع کردم. سپس، زنجیره ای از اجزای والد را دنبال کردم که از آن عبور کردند RetryFunction به این جزء در نهایت، تابع را پیدا کردم handleRetryClick، که حاوی منطق مدیریت تلاش های مجدد بود. جالب اینجاست که یک وجود داشت //TODO نظری که توسعه‌دهنده اصلی برای اضافه کردن مدیریت خطای رابط کاربری در بلوک catch گذاشته است.

پس از شناسایی مکان، وظیفه بعدی من نمایش پیام خطا با استفاده از useAlert() قلاب، همانطور که توسط نگهدار درخواست شده است. من تغییر را با اضافه کردن آن اجرا کردم error() روشی مانند این:

سپس یک روابط عمومی برای این تغییر ایجاد کردم و درخواست بازبینی نگهدارنده کردم.

این شماره 716 را رفع می کند

برای امتحان مجدد از این بلوک catch را به روز کنید

catch (err) {
// TODO: UI error handling
console.warn(“Unable to retry message”, { model, err });
}

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

به این

catch (err: any) {
error({
title: `Response Error`,
message: err.message,
});
console.warn(“Unable to retry message”, { model, err });
}

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

این نسخه ی نمایشی است:
https://github.com/user-attachments/assets/371ebd0d-dbb1-4236-a38f-110eedee883e

نگهدارنده درخواست یک به روز رسانی کوچک برای تغییر پیام خطا از Response Error به Retry Error. پس از ایجاد این تغییر، روابط عمومی من ادغام شد.

روابط عمومی دوم: بهبود اسناد برای مراجع اعضا در ویژگی های xUnit

اخیراً xUnit را برای نوشتن موارد تست واحد برای یکی از پروژه‌هایم یاد می‌گیرم. در حین کاوش در مخزن xUnit GitHub، متوجه شدم که این یک پروژه منبع باز است. این علاقه من را برانگیخت و شروع به جستجوی مسائلی کردم که بتوانم در آنها مشارکت کنم. من یک مسئله نسبتا ساده پیدا کردم:

هر زمان که استفاده می کنیم string ویژگی‌هایی که برای اشاره به یک عضو در نظر گرفته شده‌اند، باید استفاده از آن را تشویق کنیم nameof به جای رشته های کدگذاری سخت.
این شامل حداقل (لطفاً نگاه کنید و ببینید آیا موارد دیگری وجود دارد):

IFactAttribute.SkipUnless
IFactAttribute.SkipWhen

MemberDataAttribute سازنده

هدف این موضوع بهبود وضوح و قابلیت اطمینان ویژگی هایی بود که اعضای کلاس به آنها ارجاع می دهند. هدف تشویق توسعه دهندگان به استفاده از شیوه های ایمن تر، مانند nameof عملگر، هنگام ارجاع اعضا در ویژگی هایی مانند MemberData، SkipWhen، و SkipUnless.

مشکل

هنگام کار با ویژگی هایی مانند MemberDataAttribute، توسعه دهندگان اغلب برای ارجاع اعضای کلاس به رشته های رمزگذاری شده تکیه می کنند. به عنوان مثال:

[MemberData(“SomeMemberName”)]

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

این رویکرد چندین اشکال دارد:

بازسازی ریسک ها: اگر نام عضو تغییر کند، مرجع رشته به روز نمی شود و منجر به خطاهای زمان اجرا می شود.

خوانایی: رشته های رمزگذاری شده کمتر از استفاده واضح هستند nameof.

کامپایل-زمان ایمنی: رشته‌ها در زمان کامپایل اعتبارسنجی نمی‌شوند، و معرفی اشتباهات تایپی یا خطاها را آسان‌تر می‌کند.

راه حل

برای پرداختن به این موضوع، بهبودی در اسناد XML برای این ویژگی‌ها پیشنهاد کردم. اسناد به روز شده به صراحت استفاده از nameof اپراتور به اعضای مرجع، اطمینان از ایمنی زمان کامپایل و خوانایی بهتر.

نمونه به روز رسانی اسناد

برای MemberDataAttribute:

///
/// The name of the public static member on the test class that will provide the test data.
/// It is recommended to use the nameof operator to ensure compile-time safety,
/// e.g., nameof(SomeMemberName).
///

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

برای SkipWhen:

///
/// To avoid issues during refactoring, it is recommended to use the nameof operator
/// to reference the property, e.g., SkipWhen = nameof(IsTestSkipped).
///

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

برای SkipUnless:

///
/// The name of the public static member on the test class that will provide the test data.
/// It is recommended to use the nameof operator to ensure compile-time safety,
/// e.g., nameof(SomeMemberName).
///

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

تاثیر

این تغییرات تجربه توسعه‌دهنده را از طریق:

دلگرم کننده ایمنی زمان کامپایل، کاهش خطاهای زمان اجرا.
تقویت کننده خوانایی و قابلیت نگهداری از کد
حمایت از شیوه های بهتر برای بازسازیبه خصوص در پروژه های بزرگ.

روابط عمومی من

پس از اعمال تغییرات، من یک PR ارسال کردم و درخواست بررسی نگهدار را کردم. شما می توانید روابط عمومی را در اینجا پیدا کنید:

این شماره 2991 را برطرف می کند

MemberDataAttribute: اسناد XML به روز شده برای memberName پارامتری که استفاده از آن را توصیه می کند nameof اپراتور برای ایمنی زمان کامپایل

SkipWhen: اسناد XML به روز شده برای پیشنهاد استفاده از nameof برای ارجاع به خصوصیات استاتیک عمومی برای اطمینان از کد ایمن تر و قابل نگهداری تر.

SkipUnless: یک توصیه در اسناد XML برای استفاده از آن اضافه شده است nameof اپراتور هنگام ارجاع به خصوصیات استاتیک عمومی، ترویج بهترین شیوه ها.

بازتاب ها

این روابط عمومی اهمیت مستندات واضح و دقیق را در هدایت توسعه دهندگان به سمت بهترین شیوه ها تقویت کرد. اگرچه ممکن است این تغییر کوچک به نظر برسد، اما می تواند به طور قابل توجهی بر کیفیت کد و بهره وری توسعه دهندگان تأثیر بگذارد.

روابط عمومی اول

این وبلاگ در مورد دو روابط عمومی است که من در این هفته ساختم. اگر آخرین وبلاگ من را در مورد مشارکت من در ChatCraft خوانده باشید، جایی که من روی منوهای Ask و Retry کار کردم، می دانید که من یک جزء قابل استفاده مجدد برای آن منوها ارائه کرده ام. در حین کار روی آن موضوع، یک باگ را کشف کردم.

این اشکال زمانی رخ داد که شما یک پاسخ را دوباره امتحان کردید—گاهی اوقات درخواست در سمت LLM ناموفق بود، اما هیچ پیام خطایی در ChatCraft نمایش داده نمی شد. برای رفع این مشکل، من یک مشکل را باز کردم، یک ویدیو نشان دادم که این اشکال را نشان می دهد، و از نگهدارنده پرسیدم که آیا می توانم روی آن کار کنم.

پس از دریافت تاییدیه نگهدارنده برای کار روی این موضوع، شروع به بررسی موضوع کردم. اولین کار من این بود که تابعی را که مسئول فراخوانی API برای اقدام مجدد است، پیدا کنم. من با بررسی مؤلفه‌ای که دکمه تلاش مجدد را ارائه می‌کند، شروع کردم. سپس، زنجیره ای از اجزای والد را دنبال کردم که از آن عبور کردند RetryFunction به این جزء در نهایت، تابع را پیدا کردم handleRetryClick، که حاوی منطق مدیریت تلاش های مجدد بود. جالب اینجاست که یک وجود داشت //TODO نظری که توسعه‌دهنده اصلی برای اضافه کردن مدیریت خطای رابط کاربری در بلوک catch گذاشته است.

توضیحات تصویر

پس از شناسایی مکان، وظیفه بعدی من نمایش پیام خطا با استفاده از useAlert() قلاب، همانطور که توسط نگهدار درخواست شده است. من تغییر را با اضافه کردن آن اجرا کردم error() روشی مانند این:

توضیحات تصویر

سپس یک روابط عمومی برای این تغییر ایجاد کردم و درخواست بازبینی نگهدارنده کردم.

این شماره 716 را رفع می کند

برای امتحان مجدد از این بلوک catch را به روز کنید

catch (err) {
        // TODO: UI error handling
        console.warn("Unable to retry message", { model, err });
      }
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

به این

catch (err: any) {
        error({
          title: `Response Error`,
          message: err.message,
        });
        console.warn("Unable to retry message", { model, err });
      }
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

این نسخه ی نمایشی است:

https://github.com/user-attachments/assets/371ebd0d-dbb1-4236-a38f-110eedee883e

نگهدارنده درخواست یک به روز رسانی کوچک برای تغییر پیام خطا از Response Error به Retry Error. پس از ایجاد این تغییر، روابط عمومی من ادغام شد.

روابط عمومی دوم: بهبود اسناد برای مراجع اعضا در ویژگی های xUnit

اخیراً xUnit را برای نوشتن موارد تست واحد برای یکی از پروژه‌هایم یاد می‌گیرم. در حین کاوش در مخزن xUnit GitHub، متوجه شدم که این یک پروژه منبع باز است. این علاقه من را برانگیخت و شروع به جستجوی مسائلی کردم که بتوانم در آنها مشارکت کنم. من یک مسئله نسبتا ساده پیدا کردم:

هر زمان که استفاده می کنیم string ویژگی‌هایی که برای اشاره به یک عضو در نظر گرفته شده‌اند، باید استفاده از آن را تشویق کنیم nameof به جای رشته های کدگذاری سخت.

این شامل حداقل (لطفاً نگاه کنید و ببینید آیا موارد دیگری وجود دارد):

  • IFactAttribute.SkipUnless
  • IFactAttribute.SkipWhen
  • MemberDataAttribute سازنده

هدف این موضوع بهبود وضوح و قابلیت اطمینان ویژگی هایی بود که اعضای کلاس به آنها ارجاع می دهند. هدف تشویق توسعه دهندگان به استفاده از شیوه های ایمن تر، مانند nameof عملگر، هنگام ارجاع اعضا در ویژگی هایی مانند MemberData، SkipWhen، و SkipUnless.


مشکل

هنگام کار با ویژگی هایی مانند MemberDataAttribute، توسعه دهندگان اغلب برای ارجاع اعضای کلاس به رشته های رمزگذاری شده تکیه می کنند. به عنوان مثال:

[MemberData("SomeMemberName")]
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

این رویکرد چندین اشکال دارد:

  • بازسازی ریسک ها: اگر نام عضو تغییر کند، مرجع رشته به روز نمی شود و منجر به خطاهای زمان اجرا می شود.
  • خوانایی: رشته های رمزگذاری شده کمتر از استفاده واضح هستند nameof.
  • کامپایل-زمان ایمنی: رشته‌ها در زمان کامپایل اعتبارسنجی نمی‌شوند، و معرفی اشتباهات تایپی یا خطاها را آسان‌تر می‌کند.

راه حل

برای پرداختن به این موضوع، بهبودی در اسناد XML برای این ویژگی‌ها پیشنهاد کردم. اسناد به روز شده به صراحت استفاده از nameof اپراتور به اعضای مرجع، اطمینان از ایمنی زمان کامپایل و خوانایی بهتر.

نمونه به روز رسانی اسناد

برای MemberDataAttribute:

/// 
/// The name of the public static member on the test class that will provide the test data. 
/// It is recommended to use the nameof operator to ensure compile-time safety, 
/// e.g., nameof(SomeMemberName).
/// 
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

برای SkipWhen:

/// 
/// To avoid issues during refactoring, it is recommended to use the nameof operator
/// to reference the property, e.g., SkipWhen = nameof(IsTestSkipped).
/// 
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

برای SkipUnless:

/// 
/// The name of the public static member on the test class that will provide the test data.
/// It is recommended to use the nameof operator to ensure compile-time safety, 
/// e.g., nameof(SomeMemberName).
/// 
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید


تاثیر

این تغییرات تجربه توسعه‌دهنده را از طریق:

  • دلگرم کننده ایمنی زمان کامپایل، کاهش خطاهای زمان اجرا.
  • تقویت کننده خوانایی و قابلیت نگهداری از کد
  • حمایت از شیوه های بهتر برای بازسازیبه خصوص در پروژه های بزرگ.

روابط عمومی من

پس از اعمال تغییرات، من یک PR ارسال کردم و درخواست بررسی نگهدار را کردم. شما می توانید روابط عمومی را در اینجا پیدا کنید:

این شماره 2991 را برطرف می کند

  • MemberDataAttribute: اسناد XML به روز شده برای memberName پارامتری که استفاده از آن را توصیه می کند nameof اپراتور برای ایمنی زمان کامپایل
  • SkipWhen: اسناد XML به روز شده برای پیشنهاد استفاده از nameof برای ارجاع به خصوصیات استاتیک عمومی برای اطمینان از کد ایمن تر و قابل نگهداری تر.
  • SkipUnless: یک توصیه در اسناد XML برای استفاده از آن اضافه شده است nameof اپراتور هنگام ارجاع به خصوصیات استاتیک عمومی، ترویج بهترین شیوه ها.


بازتاب ها

این روابط عمومی اهمیت مستندات واضح و دقیق را در هدایت توسعه دهندگان به سمت بهترین شیوه ها تقویت کرد. اگرچه ممکن است این تغییر کوچک به نظر برسد، اما می تواند به طور قابل توجهی بر کیفیت کد و بهره وری توسعه دهندگان تأثیر بگذارد.

نوشته های مشابه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دکمه بازگشت به بالا