دربارهٔ این فصل
یادداشتِ همراه نوارتا حالا برایتان پیش آمده که هنگام کار روی یک پروژه، فایل‌های مختلفی با نام‌های نهایی و اصلاحی بسازید و آخرش هم ندانید کدام نسخه واقعاً به‌روز است؟ وقتی بیش از یک نفر روی پروژه‌ای کار می‌کنند که قرار است ماه‌ها و سال‌ها زنده بماند، کپی کردن فایل‌ها دیگر جواب نمی‌دهد و به ابزاری جدی نیاز داریم.
این موضوع در کتاب «مهندسی نرم‌افزار در گوگل» نوشتهٔ تیتوس وینترز، تام مانشریک و هایروم رایت بررسی شده و نشان می‌دهد که چطور انتخاب ابزار و سیاست‌های کنترل نسخه می‌تواند سرنوشت یک سازمان بزرگ را تغییر دهد.
یکی از چالش‌های اصلی، انتخاب بین سیستم کنترل نسخه متمرکز و سیستم کنترل نسخه توزیع‌شده است. در سیستم‌های متمرکز مثل اس‌وی‌ان، یک مخزن مرکزی واحد وجود دارد که همه چیز آنجا ثبت می‌شود، اما در مدل‌های توزیع‌شده مثل گیت، هر توسعه‌دهنده کل تاریخچه را روی سیستم خودش دارد. مشکل سیستم‌های توزیع‌شده این است که اگر سیاست روشنی نداشته باشید، هر کس روی شاخه‌ای جدا کار می‌کند و پیدا کردن نسخهٔ معتبر دشوار می‌شود. راه‌حل این است که حتی در سیستم‌های توزیع‌شده، یک مخزن و شاخهٔ مشخص به عنوان منبع حقیقت در نظر گرفته شود تا همه بدانند کد اصلی کجاست.
مسئلهٔ مهم دیگر، تله‌ای به نام شاخه‌های توسعه dev branches است که خیلی از تیم‌ها برای حفظ پایداری محصول به آن پناه می‌برند. مشکل اینجاست که شاخه‌های طولانی‌مدت برای توسعه، در نهایت زمان ادغام شدن با شاخهٔ اصلی به مشکلی بزرگ و پرهزینه تبدیل می‌شوند که هماهنگی‌اش وقت تیم را می‌گیرد. نویسندگان کتاب معتقدند به جای استفاده از شاخه‌های طولانی، باید از روش توسعه روی شاخهٔ اصلی trunk-based development استفاده کرد و پایداری را با کمک تست‌های دقیق و یکپارچه‌سازی پیوسته (Continuous Integration) به دست آورد. در این روش، تغییرات کوچک به صورت مداوم به شاخهٔ اصلی اضافه می‌شوند و کدهای ناقص در زمان اجرا غیرفعال می‌مانند.
بحث جذاب دیگر، قانون تک‌نسخه‌ای One-Version Rule در گوگل است. در یک سازمان بزرگ، اگر تیم‌های مختلف بتوانند نسخه‌های متفاوتی از یک کتابخانه یا وابستگی را استفاده کنند، پروژه‌ها در زمان ترکیب شدن با خطاهای عجیبی روبه‌رو می‌شوند. گوگل با استفاده از مخزن یکپارچه (Monorepo) و ابزارهای داخلی خودش، این قانون را اجرا می‌کند که برای هر وابستگی، فقط و فقط یک نسخه وجود داشته باشد تا توسعه‌دهندگان درگیر انتخاب نسخه نشوند. البته اجرای این مدل در مقیاس‌های بسیار بزرگ نیاز به زیرساختی دارد که بتواند ده‌ها هزار مهندس و میلیون‌ها خط کد را بدون کندی مدیریت کند.
پیشنهاد من به شما این است که اگر روی پروژه‌ای تیمی کار می‌کنید که عمرش از چند روز بیشتر است، حتماً از یک سیستم کنترل نسخه استفاده کنید و از ساختن شاخه‌های موازی و طولانی‌مدت پرهیز کنید. اجازه ندهید انتخاب‌های متعدد دربارهٔ نسخه‌های مختلف کدهای شما را از مسیر اصلی منحرف کند.
امیدوارم این بخش از صحبت‌ها توانسته باشد دید روشن‌تری نسبت به مدیریت کد و شاخه‌ها در ابعاد بزرگ به شما بدهد. تا اپیزود بعدی، کدها و پروژه‌هایتان پایدار و سرراست باد.