چند مدل در اپ وقتی جواب می‌دهد که هر کدام صاحب یک کار باشند

استفاده از بیش از یک مدل می‌تواند معنی داشته باشد. طراحی کل اپ دور تعویض مدل معمولاً نه. به محض اینکه تیم می‌فهمد می‌شود ارائه‌دهنده را ترکیب کرد، وسوسه می‌شود همه‌چیز را انتزاع کند. ناگهان هر endpoint هر مدلی را پشتیبانی می‌کند، هر پرامپت سعی می‌کند جهانی باشد، و کسی نمی‌تواند جواب دهد در پروداکشن کدام ارائه‌دهنده صاحب کدام کار است.

این مشکل‌ها یک‌باره فاجعه نیستند. آرام مالیات می‌گیرند: مالکیت نامعلوم، اشتباه تکراری، هزینه پنهان، دست‌به‌دست ناجور، و تصمیم‌هایی که به پرامپت یا دانش قبیله‌ای رانده شده‌اند. بعد از مدتی در تکرار کندتر، حادثه پرسروصداتر، و محصولی که سخت‌تر از چیزی که باید قابل اعتماد است دیده می‌شوند. این علامت آن است که خود گردش کار به توجه نیاز دارد، نه ابزار داخلش به‌تنهایی.

شکل انتخابی، نه جهانی

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

گردش کار باید آن‌قدر صریح باشد که بشود یاد داد و بازبینی کرد. اگر هم‌تیمی تازه نفهمد سیستم از کجا شروع می‌شود، چه ورودی می‌خواهد، و قضاوت انسان کجا هنوز لازم است، گردش کار سالم نیست.

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

بدون آشوب واردش کن

یک مسیر تکراری را انتخاب کن که دردش روشن و ریسک‌اش قابل مهار است. جریان مطلوب را به زبان ساده بنویس قبل از اینکه به ابزار وصل کنی. این کار احتمال اینکه اتوماسیون فرایند ضعیف را قایم کند به‌جای اینکه بهترش کند کم می‌کند.

بعد وضوح عملیاتی: چه چیزی لاگ می‌شود، چه چیزی بازبینی می‌شود، در شکست چه می‌شود، و تصمیم نهایی مال کیست. تیم وقتی این جواب‌ها پیدا باشند سریع‌تر حرکت می‌کند، مخصوصاً وقتی قدم کمک‌گرفته از مدل وارد تصویر شود.

انتزاع پهن‌تر را بعد از این بساز. گردش کار خوب استفاده دوباره را خودش به دست می‌آورد. لازم نیست روز اول ادای فریمورک را دربیاورد.

حفاظی که کار را عاقل نگه می‌دارد از جنس رابط تایپ‌دار است، لایه آداپتر کوچک که ویژگی خاص ارائه‌دهنده را قایم کند، و مورد ارزیابی بسته به همان مسیری که مدل را واقعاً استفاده می‌کند. انتخاب مدل را در لاگ و trace قابل دیدن کن تا تصمیم محصول داخل پیکربندی مرموز گم نشود.

تیم بالغ این‌جا از تیم صرفاً مشتاق جدا می‌شود. حفاظ چون سیستم ضعیف است نیست. چون کار مهم است، لبه واقعی است، و قابلیت اطمینان وقتی مرز روشن باشد جمع می‌شود. در عمل یعنی تعریف باریک کار، دست‌به‌دست تایپ‌دار جایی که ممکن است، رفتار جایگزین قابل دیدن، و تمایل به نگه داشتن عمل حساس پشت بازبینی صریح.

چه چیزی نسازم

آنچه نمی‌سازم یک انتزاع غول «مستقل از ارائه‌دهنده» است که فرق واقعی را پاک می‌کند و همان فرق را در ده جای دیگر نشت می‌دهد. کد یک هفته ظریف است و بعد می‌پوسد به شرط، چون مدل‌ها واقعاً یک جور رفتار نمی‌کنند. شکل خطا، سقف زمینه، معنای دما، و جزئیات خروجی ساخت‌یافته یکی نیستند. آداپتر کوچک این فرق را در یک جا جمع می‌کند. انتزاعی که وانمود می‌کند فرق وجود ندارد، فرق را به محل فراخوانی برمی‌گرداند.

انعطاف را برای تحت تأثیر گذاشتن هم نمی‌سازم. سطح پهن گران است. گردشی که از نظر تئوری همه‌چیز را می‌تواند، اغلب گردشی می‌شود که هیچ‌کس کامل نمی‌فهمد. همان لحظه اعتماد شروع به ریختن می‌کند.

هرچه کار گران‌تر، دیدنی‌تر، یا حیاتی‌تر برای کسب‌وکار باشد، پیش‌فرض روشن‌تر و شاخه پنهان کمتر می‌خواهم. ابهام در جستجو قابل تحمل است. در پروداکشن گران است.

اگر مدل دوم فقط به‌خاطر تنوع فروشنده آمده و هیچ کار مشخصی را بهتر نمی‌کند، اضافه‌اش نکن. دو صورت‌حساب، دو محدودیت نرخ، و دو حالت خرابی، بدون برد محصول، مالیات خالص است. مدل دوم باید جمله‌ای داشته باشد به این شکل: «این کار را این مدل انجام می‌دهد چون آن یکی در این مورد ارزیابی مشخص کم می‌آورد.» بدون آن جمله، مسیر اضافه نکن.

شروع عملی

یک درد تکراری را بردار و جریان مطلوب را به زبان ساده بنویس. نقطه دست‌به‌دست را صریح کن تا انسان و ابزار درباره مسئولیت حدس نزنند. دید کافی بگذار که تیم بفهمد گردش کار اصطکاک را کم کرده یا فقط جابه‌جا کرده به جایی کمتر دیده‌شده. فقط وقتی پهن کن که نسخه اول آن‌قدر پایدار باشد که هم‌تیمی داوطلبانه نگهش دارد.

اپ چندمدلی وقتی مفید است که صاحب‌نظر باشد. اگر می‌دانی هر مدل چرا آن‌جا است و چه کاری را مالک است، معماری قابل فهم می‌ماند. اگر نه، انعطاف خودش مالیات می‌شود.

صورت‌حساب و حادثه را به کار ببند، نه به فروشنده

وقتی مدل دوم وارد شد، اولین چیزی که می‌شکند معمولاً کیفیت نیست. دیدن است. یک کلید API مشترک برای همه قابلیت‌ها یعنی نمی‌دانی دسته‌بندی گران شده یا پیش‌نویس. هزینه را با نام کار لاگ کن، حتی اگر هر دو کار موقتاً یک مدل باشند. روزی که مسیرها جدا شوند، تاریخچه هنوز قابل مقایسه است.

در حادثه هم همین نام را بخواه. «مدل پایین است» جمله کافی نیست. کدام کار کاربر ایستاده، رفتار جایگزین چیست، و آیا کار قطعی اپ هنوز جلو می‌رود. اگر مدل خلاصه‌سازی خوابید، ثبت رکورد نباید بایستد. اگر مدل تنها راه اعتبار مجوز شده، از قبل مرز را اشتباه کشیده‌ای و مدل دوم آن را درست نمی‌کند.

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

پرسش‌های کوتاه

**یک کلاینت مشترک برای همه مدل‌ها؟** فقط به اندازه ارسال درخواست و خواندن خطای مشترک. رفتار خاص هر مدل را پشت آداپتر همان کار قایم کن، نه پشت رابط جهان‌شمول.

**مدل را در UI عوض کنم؟** برای ابزار داخلی شاید. برای محصول مشتری، تعویض مدل باید تصمیم مسیر باشد نه تنظیم کاربر، مگر اینکه خود محصول همین انتخاب را بفروشد.

**ارزیابی را یک‌بار برای همه مسیرها بزنم؟** نه. موردها را به کاری ببند که آن مدل واقعاً انجام می‌دهد. ارزیابی عمومی، رگرسیون مسیر را دیر نشان می‌دهد.