‫داستان مشارکت من در OpenAI.NET

builder.AddChatClient("Chat");
public sealed class MyService(ChatClient chatClient)
{
    // Use chatClient...
}

اولین بررسی، بزرگ‌تر از کد من بود

متن‌باز یعنی دانستن اینکه چه زمانی باید منتظر ماند

بازگشت Pull Request به زندگی

• هر کلاینت تخصصی، کلاس ClientSettings با تایپ قوی (Strongly Typed) مخصوص به خود را دریافت می‌کند.
• ویژگی‌های آن کلاس تنظیمات، بازتاب‌دهنده پارامترهای سازنده (Constructor) اصلی کلاینت است.
• رفتار اعتبارنامه‌ها از مدل تنظیمات پایه مشترک می‌آید، به جای اینکه در هر تایپ مشتق شده دوباره اختراع شود.
• هر کلاینت سازنده‌ای می‌گیرد که شیء تنظیمات آن را می‌پذیرد.
• ثبت سرویس‌ها از IHostApplicationBuilder و زیرساخت عمومی System.ClientModel استفاده می‌کند.
• هر دو نوع ثبت معمولی و Keyed پشتیبانی می‌شوند تا امکان داشتن چندین کلاینت از یک نوع با پیکربندی‌های متفاوت فراهم شود.

[Experimental("SCME0002")]
public sealed class ChatClientSettings : ClientSettings
{
 public string? Model { get; set; }

 public OpenAIClientOptions? Options { get; set; }

 protected override void BindCore(IConfigurationSection section)
 {
 // Bind client-specific configuration.
 }
}

[Experimental("SCME0002")]
public ChatClient(ChatClientSettings settings)
 : this(
 settings.Model,
 AuthenticationPolicy.Create(settings),
 settings.Options)
{
}

حرکت سریع و کشف اینکه طراحی هنوز در حال حرکت است

آزمونی سخت: یادگیری از طریق بررسی (Review)

یک منبع واحد برای حقیقتِ اعتبارسنجی (Validation Truth)

نام‌های پیکربندی بخشی از اپلیکیشن کاربر هستند

builder.AddKeyedChatClient("primary", "PrimaryChat");
builder.AddKeyedChatClient("premium", "PremiumChat");

اجتناب از جفت‌شدگی اتفاقی (Accidental Coupling)

منطق Bind کردن را جایی قرار دهید که داده‌ها درک شوند

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

لحظه‌ای که لحن بازخوردها تغییر کرد

کیلومتر آخر، باشکوه نبود

• درک اسکریپت‌های Build خاص پروژه؛
• همگام نگه داشتن فایل‌های API عمومی تولید شده؛
• پاسخ شفاف وقتی نتایج محلی و نتایج CI با هم نمی‌خوانند؛
• پذیرفتن کمک وقتی نگهداران پروژه می‌توانند سریع‌تر مشکلات خاص مخزن را حل کنند؛
• و درگیر ماندن حتی بعد از اینکه کارهای «جالب» کدنویسی تمام شده است.

نشان بنفش

اثر موجی: مشارکتی فراتر از یک متد کمکی

• تنظیمات با تایپ قوی که از پیکربندی بارگذاری می‌شوند؛
• گزینه‌های تودرتو برای Pipeline، Retry، Endpoint، Logging و کلاینت؛
• اعتبارنامه‌هایی که از طریق پیکربندی یا Resolvers خارجی تامین می‌شوند؛
• ثبت‌های معمولی و Keyed کلاینت؛
• چندین نمونه از یک نوع کلاینت؛
• و سینتکس مرجع برای به اشتراک گذاشتن پیکربندی بین کلاینت‌ها.

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

• API عمومی را برای اکوسیستم طراحی کنید، نه فقط برای یک مثال فوری. متد ثبت کلاینتی که برای یک کلاینت پیش‌فرض کار می‌کند، ممکن است زمانی که اپلیکیشن به چندین نمونه با پیکربندی متفاوت نیاز دارد، شکست بخورد.
• اورلودها را از طریق یک مدل ساخت و اعتبارسنجی واحد هدایت کنید. تکرار اعتبارسنجی در سازنده‌ها باعث ایجاد ناسازگاری‌های ظریف می‌شود.
• فقط برای حذف تکرار، از ارث‌بری استفاده نکنید. یک تایپ پایه مشترک می‌تواند تبدیل به یک جفت‌شدگی (Coupling) ناخواسته بین کلاینت‌هایی شود که در حالت عادی مستقل هستند.
• منطق Bind کردن را نزدیک به تایپی قرار دهید که معنای مقادیر را درک می‌کند. پارس کردن پیکربندی، مقادیر پیش‌فرض و اعتبارسنجی نباید در کلاس‌های Extension غیرمرتبط پخش شوند.
• سازگاری مستلزم پوشش کامل است. اگر یک ویژگی از نظر مفهومی برای خانواده‌ای از کلاینت‌ها کاربرد دارد، پیاده‌سازی جزئی می‌تواند یک ظاهر عمومی گیج‌کننده ایجاد کند.
• تزریق وابستگی Keyed یک مورد استثنایی (Edge Case) نیست. داشتن چندین مدل، Endpoint، Tenant یا اعتبارنامه، از الزامات عادی محیط Production است.
• تست‌ها باید تجربه توسعه‌دهنده را تأیید کنند، نه صرفاً ثبت سرویس را. دیدن یک Service Descriptor در کانتینر کافی نیست؛ Bind شدن پیکربندی و کلاینت‌های Resolve شده باید درست عمل کنند.
• آرتیفکت‌های تولید شده API بخشی از قرارداد هستند. خطوط پایه API عمومی و اسکریپت‌های Export لایق همان توجهی هستند که به کدهای دست‌نویس می‌شود.

آنچه درباره ارتباطات آموختم

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

تأمل نهایی