ساختن نرمافزار یه بازی تکنفره نیست
هوش مصنوعیخلاصهٔ کاملتر
نویسنده تو یه پست قبلی گفته بود کد ریویو دربارهی گرفتن باگ نیست، و رایجترین انتقادی که گرفته این بوده که «اگه تازه سر مرحلهی ریویو داری تصمیم میگیری این چیزو بسازی یا نه، یه مرحله رو جا انداختی؛ این تصمیم باید خیلی زودتر، سر مرحلهی داک طراحی گرفته میشد». نویسنده میگه این حرف یه بخشش درسته: فکر کردن به اینکه چی بسازیم، چرا و با چه هزینهای، واقعاً مهمه و با AI مهمتر هم میشه.
اما به گفتهی نویسنده اون نگاه یه فرض پنهان داره: اینکه بخش گروهی کار قبل از نوشتن کد تموم میشه و بعدش توسعه یه بازی تکنفرهست. نویسنده با این مخالفه و میگه ساختن نرمافزاری که رشد کنه و آدما بهش تکیه کنن، همیشه یه بازی چندنفره بوده و کد ریویو یکی از جاهای اصلیه که این بازی اونجا انجام میشه.
نویسنده یه نگاه تاریخی میندازه: قبل از GitHub و Gerrit، لینوس توروالدز تغییرهای لینوکس رو بهصورت پچ تو یه میلینگلیست ریویو میکرد و تصمیم اینکه یه تغییر بره تو هسته یا نه، همونجا گرفته میشد. اسم «pull request» هم از همونجا اومده؛ گیت هنوز یه دستور git request-pull داره که همون ایمیلِ درخواست رو برات مینویسه. پس آوردن یه تغییر واقعی جلوی جمع برای قضاوت، چیز تازهای نیست.
نکتهی اصلی نویسنده اینه که هزینهها عوض شده. تا همین چند سال پیش ارزونترین چیزی که میشد روش جدی بحث کرد یه داک طراحی بود، چون ساختن خودِ کد گرون بود؛ برای همین PRD و RFC و آرشیتکچر ریویو ساختن تا هزینهی اشتباه کم بشه. ولی این داکها فقط یه جانشین برای خودِ کد بودن. حالا که ساختن یه تغییر واقعی یا یه پروتوتایپ معتبر خیلی ارزونتر شده، تیمها مستقیم میرن سراغ خود تغییر، چون تغییر واقعی چیزی رو نشون میده که داک طراحی نمیتونه: اینکه راهحل وقتی با سیستم واقعی روبهرو میشه، چه شکلی میشه.
نویسنده میگه بیشتر بحثهای الان دربارهی AI روی تجربهی تکنفره تمرکز داره: یه برنامهنویس، یه ترمینال، بهرهوری چند برابر. این داستانها واقعیان، ولی یه سقف دارن. نرمافزاری که دووم بیاره رو گروهی از آدما با قضاوت مشترک و سلیقهی مشترک میسازن، و این چیزیه که با هر چقدر هم پرامپتِ باهوش، بهتنهایی به دست نمیآد. ریویو همونجاییه که قضاوت یه نفر با قضاوت یکی دیگه روبهرو میشه و یه تیم تبدیل به تیم میشه.
یه نکتهی دیگه که نویسنده روش تأکید میکنه اینه که بعضی تصمیمها بعد از اینکه به دست کاربر رسید، دیگه قابل برگشت نیست؛ حتی اگه کدشو رولبک کنی. یه فلگ رو روشن میکنی، رفتار جدیدو نشون میدی، بد پیش میره و فلگو برمیگردونی؛ ولی کاربر دیده، نظرشو ساخته و اعتمادی که سالها ساخته شده تو چند دقیقه ترک میخوره. به گفتهی نویسنده کد ریویو یکی از معدود جاهاییه که میشه پرسید «حتی اگه این دقیقاً درست کار کنه، اصلاً میخوایم محصولمون تو دنیای واقعی این کارو بکنه؟» و این سؤال جواب runtime نداره.
نویسنده جمعبندی میکنه که این یه دنیای کاملاً تازه نیست، بلکه یه برگشت به همون شکل قدیمیه. یهسری تصمیمها مثل آرشیتکچرِ کلانِ سازمان یا مسائل امنیت و انطباق هنوز باید قبل از نوشتن کد گرفته بشن، ولی اون مرز داره کوچیکتر میشه. بازی همون بازی چندنفرهی همیشگیه؛ فرقش اینه که حالا میتونیم روی خودِ چیز واقعی بازیش کنیم.
نکات کلیدی:
- نویسنده میگه ساختن نرمافزار ماندگار یه کار گروهیه و کد ریویو یکی از جاهای اصلیشه
- چون نوشتن کد گرون بود، قضاوت رو میبردن تو داک طراحی و PRD؛ حالا که ساختنِ تغییر ارزون شده، بحث برمیگرده سر خود تغییر
- اسم pull request از پچفرستادن برای لینوس توروالدز تو میلینگلیست لینوکس اومده
- بعضی تصمیمها بعد از رسیدن به کاربر دیگه برگشتپذیر نیستن؛ ریویو جاییه که قبل از انتشار دربارهشون قضاوت میشه
- AI این روند رو تندتر میکنه و ریویو رو مرکزیتر، نه کمرنگتر
