با شمارهٔ موبایل وارد شوید تا بتوانید اشتراک بخرید و در گفتگو شرکت کنید.

خلاصهٔ صوتی کتاب ۱۴۰۵/۰۸/۰۲

فصل نوزدهم: بازبینی کد در مقیاس گوگل با ابزار Critique

از کتاب مهندسی نرم‌افزار در گوگل · تیتوس وینترز، تام مانشریک و هایروم رایت

جلد مهندسی نرم‌افزار در گوگل
SHABGOFTAR PORTABLE AUDIOهمراهِ شنیدن
صدایی برای همراه بردنPODCAST · PERSONAL STEREO
شب‌گفتار / دفترچهٔ همراهSHABGOFTAR · LINER NOTES

دربارهٔ این فصل

یادداشتِ همراه نوار
جلد مهندسی نرم‌افزار در گوگلمهندسی نرم‌افزار در گوگلتیتوس وینترز، تام مانشریک و هایروم رایتدیدن همهٔ قسمت‌های این کتاب ←

تا حالا به این فکر کرده‌اید که در شرکتی با هزاران توسعه‌گر و یک مخزن بزرگ کد، چطور مطمئن می‌شوند کدهای جدید کیفیت لازم را دارند و سیستم را خراب نمی‌کنند؟ فرآیند بازبینی کد (Code Review) یکی از ارکان اصلی در مهندسی نرم‌افزار (Software Engineering) است، اما ابزارهایی که این فرآیند را پشتیبانی می‌کنند به همان اندازهٔ خود فرآیند اهمیت دارند.

کتاب «مهندسی نرم‌افزار در گوگل» نوشتهٔ «تیتوس وینترز، تام مانشریک و هایروم رایت» در فصل نوزدهم به سراغ ابزار داخلی گوگل به نام Critique می‌رود و نشان می‌دهد که چطور یک ابزار ساده و متمرکز می‌تواند مقیاس‌پذیری (Scalability) توسعه نرم‌افزار را تضمین کند.

نخستین ایدهٔ کلیدی در طراحی این ابزار، سادگی افراطی در رابط کاربری است. مشکل اینجاست که ابزارهای پیچیده با گزینه‌های زیاد، توسعه‌دهندگان را خسته می‌کنند و سرعت کار را پایین می‌آورند. طراحان این ابزار بین افزودن قابلیت‌های مختلف و حفظ سادگی، همیشه سادگی را انتخاب کرده‌اند؛ بارگذاری سریع، استفاده از کلیدهای میانبر و نشانگرهای بصری واضح از ویژگی‌های این رویکرد است.

ایدهٔ دوم، تکیه بر بنیاد اعتماد و ارتباطات عمومی است. در فرهنگ کاری گوگل، بازبینی کد ابزاری برای کند کردن دیگران نیست، بلکه راهی برای توانمندسازی آن‌هاست. ابزار پیام‌رسان یا پروتکل پیچیده‌ای برای ارتباطات ندارد و از توسعه‌دهندگان می‌خواهد نظرات خود را صریح بنویسند یا پیشنهاد ویرایش ارائه دهند تا از سوءتفاهم‌ها جلوگیری شود.

ایدهٔ سوم مدیریت جریان کار و قابلیت مقایسهٔ تفاوت‌هاست. درک کدهای تغییریافته در تغییرات بزرگ دشوار است، بنابراین ابزار از الگوریتم‌های پیشرفته برای برجسته کردن تغییرات خطی، نادیده گرفتن فضاهای خالی و تشخیص جابه‌جایی کدها استفاده می‌کند. همچنین تحلیل ایستا (Static Analysis) به صورت خودکار روی کدها اجرا می‌شود و خطاهای سبک نگارشی را با تراشه‌های رنگی نشان می‌دهد تا نویسنده پیش از بررسی انسانی آن‌ها را اصلاح کند.

ایدهٔ چهارم ویژگی مشخص کردن مسئول فعلی است. در پروژه‌هایی که چندین بازبینی‌کننده وجود دارد، فهمیدن اینکه الان نوبت چه کسی است که واکنش نشان دهد یک چالش جدی است. این ویژگی مشخص می‌کند که تغییر فعلی در انتظار پاسخ چه کسی است و نام افراد مسئول را پررنگ می‌کند تا روند کار متوقف نشود.

ایدهٔ پنجم امتیازدهی و تأیید نهایی تغییرات است که بر اساس تأییدیهٔ مربوط به ظاهر مناسب کد، تأیید رسمی و نبود نظرات حل‌نشده انجام می‌شود. این سیستم ساده به نویسنده اجازه می‌دهد به محض دریافت تأییدیه‌ها، کد را با اطمینان وارد مخزن اصلی کند.

پیشنهاد من این است که در تیم‌های خودتان، به جای پیچیده کردن فرآیندهای بازبینی با قوانین دست‌وپاگیر، روی سادگی ابزارها، شفافیت در تعیین مسئولیت هر مرحله و اعتماد متقابل تمرکز کنید.

امیدوارم از این روایت لذت برده باشید و در قسمت‌های بعدی با مباحث بیشتری از مهندسی نرم‌افزار در گوگل همراه ما باشید.