ارباب حلقهها: برج دیدهبانی
در قسمت قبل گفتم وقتی تولید کد سریعتر میشه ولی روش review همون روش قبلی باقی میمونه، فقط صف رو از developer به reviewer منتقل کردیم. اونجا اشاره کردم که موارد حساس همچنان باید با نظارت انسانی باشه، طراحی و اجرای این نظارت هم باید با ساز و کار و سرعت فعلی ما همخوانی داشته باشه. من طی این مدت روشهای مختلفی دیدم ولی روش Viktor Farcic جالبترینش بود و ممکنه الهام بخش خوبی برای روشهای جدید دیگه باشه.
ویکتور در این ویدئو روش کار خودش رو توضیح میده، در این workflow انسان در دو نقطه وارد میشه: قبل از پیادهسازی، طرح تستهای مهم رو تأیید میکنه و در پایان، قبل از اجازه merge، ویدئوی کوتاهی از اجرای واقعی همون تستها رو میبینه.
ابتدا agent از روی نیازمندیها مشخص میکنه چه رفتارهایی باید آزمایش بشن. ویکتور این طرح رو بررسی میکنه تا مطمئن بشه خواستهاش درست فهمیده شده. بعد agentها با نقشهای مختلف و به شکل هماهنگ، نوشتن کد و تست، بررسی تغییرات و آماده کردن PR رو انجام میدن.
در مثالی که نشون میده، قرار بوده وضعیت برنامه بعد از قطع و وصل اتصال درست بهروزرسانی بشه. agentها اجرای این سناریو رو ضبط میکنن و در پایان، همراه نتیجه تستها، کلیپ رو برای بررسی در اختیارش میذارن. به این ترتیب، برای دیدن رفتار برنامه لازم نیست هر بار خودش تمام مراحل رو دستی تکرار کنه.
چیزی که من از ویکتور یاد گرفتم اینه که طراحی چیزی که ناظر میبینه، خودش بخشی از طراحی workflow است.
خروجیهایی مثل «کار انجام شد و همه تستها پاس شدن» بهتنهایی تصویر روشنی نمیده، باید بدونیم چه چیزی آزمایش شده و آیا همون رفتاری هست که انتظار داشتیم.
البته یک کلیپ موفق یا چند تست سبز، همهچیز رو ثابت نمیکنن. سناریوهای خطا، دسترسیها و چیزهایی که اصلاً تست نشدهاند هنوز اهمیت دارن. ناظر باید محدودیت بررسی رو هم ببینه تا بدونه کجا میتونه تصمیم بگیره و کجا به بررسی بیشتری نیاز داره.
به نظرم برج دیدهبانی از همینجا ساخته میشه، نتیجه و شواهدش قابلدیدن باشن، موارد نیازمند تصمیم مشخص باشن و امکان توقف یا برگردوندن کار برای اصلاح وجود داشته باشه. در روش ویکتور هم انسان هنوز در ابتدا و انتها داخل حلقهست، اما لازم نیست در تمام مراحل همراه agentها حرکت کنه.
اگر برای تأیید کار agent مجبوریم تمام مسیرش رو دوباره طی کنیم، هنوز سیستم مناسبی برای نظارت نساختیم.