هارنس ارزیابی کوچک بهتر از داشبورد بزرگی است که کسی اجرا نمی‌کند
اگر منتظر پلتفرم ارزیابی کامل هستی، حلقه بازخوردی را عقب می‌اندازی که واقعاً لازم داری. کار ارزیابی اغلب پشت جاه‌طلبی پلتفرم می‌ماند. تیم UI داخلی، سیستم امتیاز، حاشیه‌نویسی، و هر متریکی که به ذهنش می‌رسد را تصور می‌کند. در همین فاصله فیچر AI با تقریباً هیچ بررسی کیفیت تکرارپذیر عوض می‌شود.
درد زود دیده می‌شود. قابلیت اطمینان، توجه توسعه‌دهنده، هزینه، و اعتماد محصول همه به این وابسته‌اند که بشود گفت این تغییر بهتر شد یا بدتر. داشبورد شیک که از کار روزانه دور است کهنه می‌شود. هارنس کوچک که کنار کد زندگی می‌کند اجرا می‌شود.
کی این الگو می‌ارزد
وقتی گردش کار تکرار می‌شود، محصول به اندازه کافی روشن است که موفقیت را تعریف کنی، و دلیل داری از اول به نگهداری فکر کنی. اگر خود کاربرد هنوز مبهم است، دامنه را تنگ کن. زیرساخت عمومی دور یک مسئله حل‌نشده، انعطافی است که هیچ کاربری هنوز از آن سود نبرده.
سریع‌ترین مسیر معمولاً یک گردش کار تیز است با مرز قوی، ورودی صریح، و تعریف «به اندازه کافی خوب» برای نسخه اول. یک مشت مورد نماینده، یک رانر تکرارپذیر، جایی برای ثبت انتظار، و راه سبک برای مقایسه خروجی بین تغییر پرامپت یا مدل اغلب کافی است تا مهم‌ترین رگرسیون را نشان دهد.
مرز را قبل از کد بنویس
کار را در یک جمله بنویس. شکل ورودی را بگو. بگو خروجی باید چه شکلی باشد. ساده به نظر می‌رسد و جلوی رانش معماری را می‌گیرد چون بقیه سیستم دور قرارداد پایدار طراحی می‌شود نه دور حال‌وهوا.
همزمان تصمیم بگیر کدام بخش مال مدل است و کدام در کد معمولی اپ می‌ماند. هرچه گردش کار مهم‌تر شود این تفکیک ارزشمندتر است. اگر فیچر به صورتحساب، مجوز، داده پروداکشن، یا گذار وضعیت قابل‌دیدن کاربر دست می‌زند، آن بخش‌ها را اپ با اعتبار سخت مالک شود. مدل جایی کمک کند که کار فازی است. پیامد را اپ مالک شود.
برای هارنس، خروجی مورد انتظار را داده نگه دار. مثلاً فیلدهایی که باید باشند، ابزاری که نباید صدا زده شود، و امتناعی که باید دیده شود. اسکرین‌شات چت مورد آزمون نیست.
رانر را کسل نگه دار تا واقعاً اجرا شود
بهترین خاصیت هارنس کوچک این است که صادق می‌ماند. توسعه‌دهنده اجراش می‌کند. می‌فهمد موردها نماینده چه هستند. شکست تازه را همان روزی که دیده شد اضافه می‌کند. این از داشبورد صیقلی که چون از جریان روز دور است کهنه شده ارزشمندتر است.
مسیر کد را عمداً کسل کن. یک اسکریپت یا job در CI، اعتبار خروجی تایپ‌دار، و لاگ دور گام گران یا شکست‌خور. لایه ارکستراسیون زیرک دیگر معمولاً کمتر از این‌ها می‌ارزد.
نسخه اول باید بتواند صادقانه خراب شود. وضعیت جزئی روشن و یک مسیر موفقیت باریک سالم‌تر از این است که سیستم قبل از استحقاق خودمختار به نظر برسد. اگر موردی شکست خورد، خروجی واقعی و دلیل را نشان بده. نمره واحد بدون نمونه، عادت را نمی‌سازد.
پروداکشن را فراموش نکن، ولی داشبورد نساز
با زمان سیستم می‌تواند بزرگ شود. حلقه کوچک را همچنان محافظت کن: اجرای محلی، بررسی CI برای موردهای کلیدی، و یک گذر بازبینی انسانی برای رفتاری که نمره ماشینی خوب توصیفش نمی‌کند. هدف گزارش برای خودش نیست. هدف این است که وقتی سیستم عوض شد زود بفهمی.
اگر گردش کار کند، گران، یا ناسازگار می‌شود، هارنس باید همان را هم ببیند. مهلت، شکست اعتبار، و هزینه تقریبی هر مورد را ثبت کن. لازم نیست سیستم صورتحساب باشد. باید بشود گفت تغییر پرامپت موردها را بهتر کرده یا فقط طولانی‌تر و گران‌تر.
مشاهده‌پذیری حداقلی روی خود فیچر جدا از هارنس است: تأخیر، شکست، و هزینه به تفکیک گردش کار. هارنس رگرسیون قبل از انتشار را می‌گیرد. متریک پروداکشن می‌گوید کاربر واقعی همان چیزی را می‌بیند که موردها نمایندگی می‌کردند یا نه.
اشتباه‌هایی که هارنس را می‌کشد
ساخت بیش از حد نسخه اول. انتزاع پهن چون «آینده لازم دارد»، بعد هفته‌ها نگهداری انعطافی که هنوز کاربری از آن سود نبرده.
تعریف نکردن موفقیت. اگر کسی نداند کیفیت خروجی، تأخیر، یا قابلیت اطمینان قابل قبول چیست، پیاده‌سازی را منصفانه قضاوت نمی‌کنی و فیچر هدف متحرک می‌شود.
نادیده گرفتن دست‌به‌دست انسان. حتی گردش کار خودکار به نقطه بازبینی روشن، فرض قابل‌دیدن، و زمینه کافی نیاز دارد تا هم‌تیمی بدون مهندسی معکوس کل سیستم دخالت کند.
و اشتباه چهارم که مخصوص ارزیابی است: موردهایی که از دموی خوشحال کپی شده‌اند و هیچ شکست واقعی را نمایندگی نمی‌کنند. اولین موردها را از تیکت و از جواب غلطی که خودت دیدی بردار.
فهرست کوتاه برای شروع
یک کاربرد محدود را بردار و قرارداد خروجی را صریح کن. نتیجه را قبل از اینکه کد پایین‌دست به آن تکیه کند اعتبار کن. چند مورد از شکست واقعی بنویس. رانر را در CI همان بارکننده‌ای کن که پروداکشن استفاده می‌کند، یا حداقل نزدیک به آن. مشاهده‌پذیری حداقلی تأخیر و شکست و هزینه را اضافه کن. کاربر واقعی را وقتی بیاور که می‌دانی رفتار کمی‌خراب چه شکلی است.
هارنس کوچک برنده است چون عادت می‌سازد. عادت است که کار کیفیت را از آرزو به مهندسی عادی تبدیل می‌کند.
پرسش‌های کوتاه
**داشبورد کی لازم می‌شود؟** وقتی چند تیم روی همان مجموعه مورد کار می‌کنند و اجرای محلی دیگر برای مقایسه کافی نیست. تا آن روز، اسکریپت و CI کافی است.
**نمره خودکار همه چیز را می‌سنجد؟** نه. برای شکل خروجی و ابزار ممنوع خوب است. برای لحن و قضاوت باریک، بازبینی انسانی روی نمونه کوچک را نگه دار.
**چند مورد کافی است؟** به اندازه رفتارهایی که اگر بشکنند محصول دروغ می‌گوید. کم و واقعی بهتر از زیاد و تزیینی است.