ادغام کد یک قرارداد است. به محض اینکه تغییری روی شاخه اصلی قرار میگیرد، هر تیم دیگری در سازمان فرض میکند که آن تغییر کار میکند. اما بیشتر سازمانهای مهندسی هرگز این قرارداد را مکتوب نکردهاند. آنها یک خط لوله دارند که بررسیها را اجرا میکند و هر چیزی که بررسیها پوشش میدهند، همان چیزی است که ادغام وعده میدهد. اما اگر بپرسید یک علامت تیک سبز روی یک درخواست ادغام (PR) دقیقاً چه چیزی را تضمین میکند، به ندرت پاسخ دقیقی دریافت میکنید.
این ابهام زمانی مقرونبهصرفه بود که کد با سرعت انسانی نوشته میشد و نویسندگان آن زمینه را در ذهن داشتند و پس از ادغام در دسترس بودند. اما اکنون هر دو شرط از بین رفتهاند. عوامل کدنویسی هوش مصنوعی حجم درخواستهای ادغام را چند برابر کردهاند و سهم فزایندهای از تغییرات توسط چیزی نوشته میشود که هیچ زمینه پایداری را حفظ نمیکند. پیامد آن در نظرسنجی اخیر GitLab آشکار شده است: ۸۵٪ از پاسخدهندگان گفتند که گلوگاه از نوشتن کد به بررسی کد تغییر کرده است. زمان آن رسیده که این قرارداد را به صراحت تعریف کنیم و به نقاط ضعف خطوط لوله امروزی نگاه کنیم.
چهار لایه اطمینان در ادغام کد
ابزارها را کنار بگذارید؛ یک تغییر قبل از اینکه بقیه سازمان روی آن بنا کنند، باید چهار چیز را ثابت کند:
- خوب شکل گرفته باشد: کامپایل شود، لینت و تحلیل استاتیک را پاس کند و یک مصنوع قابل استقرار تولید کند.
- از نظر داخلی صحیح باشد: تستهای واحد تأیید کنند که منطق آنچه نویسنده در نظر داشته را انجام میدهد، به صورت ایزوله و با وابستگیهای شبیهسازی شده.
- در مرزهای خود سازگار باشد: به قراردادهای API که مصرفکنندگان به آن وابسته هستند و طرحهای دادهای که تولیدکنندگان منتشر میکنند، احترام بگذارد.
- در برابر سیستم واقعی به درستی رفتار کند: این لایه شامل رفتارهای عملکردی و غیرعملکردی است. از نظر عملکردی، نتایج درست را برمیگرداند و جریانهای همسایگان را محترم میشمارد. از نظر غیرعملکردی، تحت ترافیک واقعی از نظر تأخیر، نرخ خطا، مصرف منابع و سازگاری عقبمانده مقاومت میکند. این بررسی نه در برابر ماکها یا فیکسچرهای ضبطشده، بلکه در برابر نسخههای زنده سرویسها با اشکال داده واقعی انجام میشود.
سه لایه اول ارزان هستند و نیازی به محیط واقعی ندارند. اما لایه چهارم که گرانقیمت است، تنها لایهای است که دستهای از باگها را که واقعاً در میکروسرویسها آسیب میزنند، میگیرد: تغییری که به صورت محلی درست و از نظر سیستمی اشتباه است.
چرا لایه چهارم از دروازه خارج شد؟
در بیشتر دهه گذشته، لایه چهارم قبل از ادغام اجرا نمیشد. تعیین رفتار سیستم واقعی به محیطی نیاز داشت که هر سرویس در آن اجرا شود و چنین محیطهایی کمیاب، گران و کند بودند. تیمها یک یا دو محیط مشترک داشتند که اغلب خراب بودند. بنابراین صنعت یک مصالحه آرام انجام داد: ادغام روی سه لایه اول و سپس کشف رفتار سیستم پس از آن در یک محیط مشترک. ما مدیریت انتشار، پنجرههای انجماد و چرخشهای آمادهباش را برای پیشتولید عمدتاً برای مدیریت عواقب ایجاد کردیم.
این مصالحه در سرعت انسانی به سختی برقرار بود. اما اکنون با افزایش حجم PRها توسط هوش مصنوعی، این رویکرد شکسته شده است. زمان آن رسیده که اعتبارسنجی سیستم را به قبل از ادغام منتقل کنیم.
راهحلهای عملی برای مقابله با گلوگاه بررسی کد
برای حل این مشکل، سازمانها باید لایه چهارم را به خط لوله خود اضافه کنند. این کار نیازمند محیطهای آزمایشی مقیاسپذیر و خودکار است. ابزارهایی مانند Docker و Kubernetes میتوانند به ایجاد محیطهای ایزوله برای هر PR کمک کنند. همچنین، استفاده از بررسی کد خودکار با هوش مصنوعی میتواند بار انسانی را کاهش دهد، اما نباید جایگزین بررسی عمیق انسانی شود.
در نهایت، موفقیت در این مسیر نیازمند تغییر فرهنگ سازمانی است. تیمها باید قرارداد ادغام را به صراحت تعریف کنند و مطمئن شوند که هر تغییری قبل از ورود به شاخه اصلی، تمام چهار لایه اطمینان را پشت سر گذاشته است. تنها در این صورت است که میتوان از پتانسیل کامل هوش مصنوعی در کدنویسی بهره برد، بدون اینکه کیفیت و پایداری سیستم قربانی شود.
