دربارهٔ این فصل
یادداشتِ همراه نوارتا حالا به این فکر کرده‌اید که چرا وقتی چند نفر به یک تکه کد نگاه می‌کنند، نتیجه کار خیلی بهتر از زمانی می‌شود که آن را تنها و در سکوت نوشته‌اید؟ چطور ممکن است شرکتی با ده‌ها هزار مهندس، میلیاردها خط کد را در یک مخزن واحد مدیریت کند بدون اینکه سیستم زیر پایش خرد شود؟
این موضوعی است که در فصل نهم از کتاب «مهندسی نرم‌افزار در گوگل» نوشته تیتوس وینترز، تام مانشریک و هایروم رایت به آن پرداخته شده است و نشان می‌دهد چرا بازبینی کد فراتر از پیدا کردن ساده چند خط باگ است.
اولین مسئله‌ای که تیم‌ها با آن روبه‌رو می‌شوند این است که اصلاً چرا باید هر تکه کدی پیش از ورود به مخزن اصلی بازبینی شود. گزینه‌ها متنوعند؛ از اینکه هر کسی هر چه خواست را مستقیم ثبت کند تا اینکه گروهی معدود به عنوان دروازه‌بان همه‌چیز را کنترل کنند. نویسندگان نشان می‌دهند که اگر بررسی صحت عملکرد تنها هدف باشد، هزینه فرآیند از ارزش آن بیشتر می‌شود. معاوضه اصلی این است که سرعت اولیه فدای پایداری بلندمدت می‌شود. به عنوان مثال، در گوگل تقریباً هیچ تغییری بدون تایید ثبت نمی‌شود و هر مهندسی موظف است در این فرآیند شرکت کند تا هم‌سویی و صحت کد تضمین شود.
دومین چالش، موضوع مالکیت و مقیاس‌پذیری است. وقتی تعداد افراد زیاد می‌شود، تعیین اینکه چه کسی مسئول کدام بخش از کد است سخت می‌شود. راه حل این است که سیستم بر اساس پوشه‌های ساختاری از فایل‌های مالکان اداره شود. معاوضه در اینجا تمرکززدایی در برابر کنترل مرکزی است؛ یعنی هر تیمی مسئولیت دایرکتوری خودش را بر عهده می‌گیرد بدون اینکه نیازی به تایید مدیران رده‌بالا باشد. برای نمونه، فایل‌های مالکان در شاخه‌های مختلف دایرکتوری مشخص می‌کنند که چه کسانی حق تایید نهایی تغییرات را دارند.
مسئله سوم اهمیت خوانایی و یکدستی در کل پایگاه کد است. خطر اینجاست که هر توسعه‌دهنده‌ای با سبک شخصی خودش کد بزند و بعد از مدتی هیچ‌کس نتواند کدهای دیگران را بخواند. گزینه گوگل جدا کردن تاییدیه خوانایی (readability) از تاییدیه منطقی است. معاوضه این است که شاید نویسنده مجبور شود کدی را که از نظر منطقی درست است بازنویسی کند تا با استانداردها همخوانی داشته باشد. مثلاً برای نوشتن کدهای جاوا، حتماً باید تأییدیه فردی را بگیرید که دوره تخصصی خوانایی آن زبان را گذرانده است.
چهارمین ایده کلیدی، تمرکز روی تغییرات کوچک است. مشکل اینجاست که توسعه‌دهندگان دوست دارند پروژه‌های بزرگ را یکجا تمام کنند و بفرستند. معاوضه این است که خواندن و بررسی تغییرات بزرگ بسیار زمان‌بر و خطاپذیر است. روش پیشنهادی این است که تغییرات به قطعات کوچک‌تر از دویست خط تقسیم شوند. مثلاً وقتی تغییرات کوچک می‌فرستید، همکاران شما می‌توانند در کمتر از بیست و چهار ساعت به شما بازخورد بدهند و فرآیند توسعه متوقف نشود.
پنجمین نکته، مزایای فرهنگی و اشتراک دانش در این فرآیند است. بدون یک سیستم مدون، بازبینی کد می‌تواند به یک جروکمرانی شخصی تبدیل شود. معاوضه اتکا به ابزار در برابر ایجاد تنش انسانی است. به عنوان مثال، ابزار بازبینی کد (Critique) مثل پلیس خوب عمل می‌کند و انتقادات را از حالت شخصی خارج کرده و به یک گفتگوی سازنده تبدیل می‌کند.
به عنوان پیشنهاد عملی، به نظرم می‌رسد بهتر است در تیم خودتان عادت کنید کدهای خود را پیش از ارسال خرد کنید و از همکارانتان بخواهید ابتدا به جای جنگیدن بر سر سلیقه، روی خوانایی و درک منطق تمرکز کنند.
بازبینی کد در نهایت تنها یک مانع در مسیر ثبت کد نیست، بلکه چسبی است که مهندسان را به هم وصل می‌کند و دانش فنی را در سراسر سازمان جریان می‌دهد.