درخواست کشش (Pull Request) همانطور که میشناسیم حدود ۲۰ سال قدمت دارد؛ حتی جوانتر از حرفه بسیاری از افرادی که اکنون از آن به عنوان یک امر غیرقابل مذاکره دفاع میکنند. بررسی کد (Code Review) نیز دائمی به نظر میرسد، اما اینطور نیست. گوگل حدود سال ۲۰۰۶ بررسی کد را به صورت داخلی آغاز کرد و بسیاری از نرمافزارهای اصلی ویندوز بدون هیچ چیزی شبیه به یک بررسی مدرن عرضه شدند.
بررسی کد یک دروازه تأیید است که دیگر با شکل کار مهندسی نرمافزار مطابقت ندارد. همانطور که در آستانه تغییر دوباره آن هستیم، یادآوری این نکته مفید است که ما خود این عمل را اختراع کردیم. این عمل مشکلات خاصی را حل میکرد: کشف نقصها قبل از یکپارچهسازی، آموزش مهندسان تازهکار، و انتشار دانش بهطوری که هیچ فردی به تنهایی تمام زمینه را در اختیار نداشته باشد. اما در طول مسیر، به انطباق، دروازهبانی، و در بسیاری از سازمانها، به یک نمایش تبدیل شد.
«بررسی کد در مرحله ادغام گیر کرده بود. هوش مصنوعی نیروی محرکهای است که آن را به بالادست منتقل میکند.»
اکنون حجم کد این عمل را شکسته است و دوراهی بین نخواندن کد به هیچ وجه و بررسی خطبهخط کد تولیدشده توسط هوش مصنوعی برای جلوگیری از آشفتگی نیست. بلکه بحث بر سر این است که بررسی کد واقعاً برای چه بود و چطور باید آن کارکردها را برای جهانی بازسازی کرد که در آن ماشینها بیشتر کدها را مینویسند.
بررسی کد در مرحله ادغام گیر کرده است
از هر کسی بپرسید که بررسی کد کجا انجام میشود و پاسخ خودکار است: درست قبل از ادغام (Merge). نه قبل از آن، نه بعد از آن. یک نقطه در خط لوله و این به تنها نقطه تبدیل شده است.
در Thoughtworks، توسعه مبتنی بر شاخههای اصلی (Trunk-based Development)، توسعه مبتنی بر تست (TDD) و برنامهنویسی جفتی (Pair Programming) به عنوان نوعی دین عمل میشود؛ یعنی بررسی یک مراسم رسمی نیست. مزایا به طور مداوم، در داخل جلسه برنامهنویسی جفتی حاصل میشود، نه هفتهها بعد که کسی بالاخره یک تفاوت ۵۰۰ خطی را باز میکند. وقتی هفتهها روی یک شاخه نمینشینید و تستهایتان کافی هستند، یک خط لوله سبز (Green Pipeline) بیشتر چیزی است که نیاز دارید.
این ایده که قبل از یکپارچهسازی نباید تنها جایی باشد که بررسی میکنیم، جدید نیست. چیزی که کم بود یک نیروی محرکه بود. اکنون که ما هوش مصنوعیهای عاملی قدرتمند و IDEهای عاملی داریم که به ما در تولید کد بیشتر کمک میکنند، همه دوباره به آن فکر میکنند. وقتی یک عامل میتواند در یک بعدازظهر کد یک ویژگی را تولید کند، شکافهایی که میخواهید بگیرید به بالادست، به لحظهای که یک توسعهدهنده قصد خود را به ابزار بیان میکند، منتقل میشود. تا زمانی که تفاوت (Diff) وجود دارد، شما در حال بررسی عواقب تصمیمی هستید که ساعتها پیش گرفته شده و ارزش هزاران توکن را دارد.
«تا زمانی که تفاوت وجود دارد، شما در حال بررسی عواقب تصمیمی هستید که ساعتها پیش گرفته شده است.»
توسعه مبتنی بر قصد (Intent-driven Development) در Aviator به معنای ثبت قصد در جایی است که ایجاد میشود. این میتواند یک توضیح مختصر از دامنه، آنچه به صراحت خارج از دامنه است، یا فهرستی از معیارهای پذیرش باشد. از تجربه ما، قصد بهتر است مستقیماً از درخواستها و از تصمیماتی که مهندس در حین کار با عامل گرفته است، استخراج شود.
اکنون چه چیزی را بررسی میکنیم؟
بیان قصد مصنوعاتی تولید میکند: دهها فایل مارکداون به ازای هر ویژگی، مشخصات، گزارشهای سوالات روشنگر، و درخت تصمیم مدفون در یک مکالمه درخواست. اکثر تیمها هیچ کدام را تحت کنترل نسخه قرار نمیدهند. بنابراین ایده آنچه ارزش بررسی کد دارد تغییر کرده است.
سه گروه پدیدار شده است:
- بررسی فقط مشخصات: برخی تیمها فقط مشخصات را بررسی میکنند و به بقیه اعتماد دارند.
- بررسی همه چیز: برخی هنوز هر مصنوع، مشخصات، کد و همه چیز در بین را بررسی میکنند و کاملاً آگاه هستند که در حال تبدیل شدن به گلوگاه هستند.
- بررسی هیچ چیز: برخی هیچ چیز را بررسی نمیکنند و سیستم در حال اجرا را تست میکنند، زیرا حجم هیچ گزینه دیگری برای آنها باقی نمیگذارد.
شیوه انجام بررسی کد توسط تیمها نیز به دلیل حجم کد در حال ایجاد در حال تغییر است. یک تفاوت (Diff) که بیش از پنج فایل را پوشش میدهد، توانایی انسان را برای ارتباط دادن تغییر مورد نظر با تغییر واقعی تحت فشار قرار میدهد. آن را در ده ضرب کنید. بازبین اکنون چیزی فراتر از یک تفاوت و یک تیکت میخواهد؛ او میخواهد قصد اصلی، مسیری که عامل طی کرده و شاید کد را ببیند.
قصد را بخوانید، نه پیادهسازی را
بازبین مجبور نیست به صدها خط کد نگاه کند تا بفهمد آیا درست به نظر میرسد، بلکه به ۱۰ خط قصد و معیارهای پذیرش با یک سوال در ذهن نگاه میکند: آیا این مشکل درست را با محدودیتهای درست حل میکند؟ این استفاده بسیار کارآمدتر از ظرفیت ذهنی انسان است.
این تغییر به ابزارهای جدید نیاز دارد. جریانهای کاری فعلی بررسی کد برای دیدن قصد در کنار کد طراحی نشدهاند. ابزارهایی مانند Crucible یا GitHub Review نشانههایی از این مسیر را دارند، اما تیمها در حال کشف روشهای خود هستند: جاسازی لینکها به مشخصات در توضیحات Pull Request، ذخیره تاریخچه درخواستهای عامل در یک مخزن جداگانه، یا نوشتن نقد بررسی به عنوان توضیح در مقابل کد.
در نهایت، هدف این نیست که از بررسی صرفنظر کنیم، بلکه این است که بررسی را هوشمندانهتر انجام دهیم. با حرکت به سمت بالا دست (Upstream)، میتوانیم تصمیمات را در لحظه گرفتن اصلاح کنیم، نه ساعتها بعد که تبدیل به هزاران خط کد شدهاند.
نتیجهگیری: آینده بررسی کد
بررسی کد همانطور که میشناسیم در حال مرگ نیست، بلکه در حال تحول به یک عمل متمرکز بر قصد است. هوش مصنوعی نه تنها ابزار نوشتن کد، بلکه نیروی محرکهای برای بازاندیشی در فرآیندهای ماست. تیمهایی که زودتر این تغییر را بپذیرند، نه تنها گلوگاه را کاهش میدهند، بلکه کیفیت و سرعت توسعه را بهبود میبخشند.
برای مطالعه بیشتر در مورد بررسی کد و توسعه مبتنی بر شاخه اصلی میتوانید به منابع مرتبط مراجعه کنید.
