دربارهٔ این فصل
یادداشتِ همراه نوارتا حالا برایتان پیش آمده که هنگام خواندن کدهای نوشته شده توسط همکارانتان، احساس کنید هر کس با زبان خودش حرف می‌زند و سر درآوردن از منطق برنامه‌ها وقت زیادی از شما بگیرد؟ در یک سازمان بزرگ با هزاران برنامه‌نویس، بدون داشتن قوانین مشخص، پروژه به سرعت تبدیل به کلافی سردرگم می‌شود که نگهداری‌اش غیرممکن است. کتاب «مهندسی نرم‌افزار در گوگل» نوشتهٔ «تیتوس وینترز، تام مانشریک و هایروم رایت» در فصل هشتم به سراغ همین موضوع حیاتی می‌رود و بررسی می‌کند که چگونه راهنماهای سبک و قوانین مدون می‌توانند نظم و پایداری را به مخازن عظیم کد هدیه دهند.
مسئلهٔ اصلی در سازمان‌های نرم‌افزاری این است که رفتار خوب و بد برنامه‌نویسان تعریف‌نشده باقی می‌ماند و با رشد تیم، سلیقه‌های شخصی جایگزین انسجام می‌شود. گزینه‌ها از آزادی کامل توسعه‌دهندگان در انتخاب الگوها تا داشتن مجموعه‌ای از قوانین خشک متغیر است. نویسندگان کتاب اشاره می‌کنند که قوانین گوگل قوانین سخت‌گیرانه‌ای هستند که باید رعایت شوند، نه صرفاً پیشنهادهایی دوستانه. به عنوان نمونه، در زبان سی‌پلاس‌پلاس، گوگل استفاده از استثناها را ممنوع کرده است؛ تصمیمی که شاید در بیرون از گوگل عجیب به نظر برسد اما برای حفظ سادگی و کنترل جریان خطا در یک کدبانک چند میلیاردی ضروری است.
یکی از چالش‌های بزرگ طراحی قوانین، حفظ تعادل بین محدودیت و کارایی است و قانون‌گذاران باید مطمئن شوند که هر قاعده واقعاً به هدف نهایی کمک می‌کند. انتخاب اشتباه در اینجا یعنی تحمیل بار ذهنی اضافه‌کاری به توسعه‌دهندگان بدون اینکه ارزش واقعی خلق شود. برای مثال، راهنمای سبک پایتون در گوگل توسعه‌دهندگان را از استفاده از ویژگی‌های بسیار پویا مانند بازتاب reflection منع می‌کند، زیرا این قابلیت‌ها خواندن کد را مبهم و ردیابی خطاها را برای مهندسان دیگر به شدت دشوار می‌سازند.
یکی دیگر از اصول کلیدی این است که قوانین باید خوانندهٔ کد را بر نویسندهٔ آن ترجیح دهند زیرا کد در طول عمر خود بسیار بیشتر از آنکه نوشته شود، خوانده می‌شود. راه‌حل گوگل در این زمینه الزام به درج شواهد صریح از رفتار مورد انتظار در کد است. مثلاً در سی‌پلاس‌پلاس، استفاده از ابزار مدیریت مالکیت اشاره‌گرها یعنی std::unique_ptr به جای اشاره‌گرهای خام الزامی شده است تا هر زمان که تابعی مالکیت داده‌ای را می‌گیرد، خوانندهٔ کد بلافاصله و بدون نیاز به بررسی پیاده‌سازی داخلی تابع، از انتقال مالکیت باخبر شود.
حفظ سازگاری درون‌سازمانی مزیتی است که به مهندسان اجازه می‌دهد بدون اتلاف وقت وارد بخش‌های ناآشنای کد شوند و کار را جلو ببرند. گزینه‌های پیش رو شامل پذیرش استانداردهای بیرون از سازمان یا ساخت استانداردهای داخلی است و معاوضهٔ اصلی در اینجا از دست دادن مقداری از آزادی خلاقانه در ازای کسب بهره‌وری تیمی است. به عنوان یک مثال ملموس، اگرچه پایتون در جامعهٔ جهانی از تورفتگی چهاراسپیسی استفاده می‌کند، گوگل مدت‌ها به دلیل همسویی با کدهای سی‌پلاس‌پلاس خود از تورفتگی دواسپیسی استفاده می‌کرد اما بعدها با بزرگ‌تر شدن پروژه‌ها و تعامل با دنیای خارج، این قانون را اصلاح کرد تا با استانداردهای جامعهٔ پایتون هماهنگ شود.
نکتهٔ قابل توجه این است که نوشتن قوانین تنها نیمی از مسیر است و اعمال دستی آن‌ها در مقیاس وسیع دوام نمی‌آورد؛ به همین دلیل بخش بزرگی از فرآیندها به کمک ابزارهای خودکار پیش می‌رود. در این راستا، استفاده از تحلیل ایستا (Static Analysis) یعنی بررسی خودکار کد بدون اجرای آن برای پیدا کردن خطاهای الگو و ساختار بسیار رایج است. ابزارهایی مانند clang-tidy برای زبان سی‌پلاس‌پلاس یا فرمت‌کننده‌های خودکار کد کمک می‌کنند تا بدون نیاز به بحث‌های فرساینده در بازبینی کد (Code Review) یعنی بررسی تغییرات کد توسط همکاران پیش از ادغام، تمام فایل‌ها به یک شکل استاندارد و یکدست فرمت شوند.
پیشنهاد من به شما این است که در تیم‌های خود به جای تحمیل قوانین سلیقه‌ای و پیچیده، روی چند اصل روشن مانند خوانایی کد، به حداقل رساندن غافلگیری برای خوانندهٔ آینده و اتوماسیون فرمت‌دهی تمرکز کنید تا انرژی تیم صرف حل مسئله شود نه بحث دربارهٔ فاصله گذاری‌ها. قوانین خوب نباید دست‌وپاگیر باشند، بلکه باید به عنوان ریل‌گذاری‌هایی مطمئن به تیم کمک کنند تا با خیال راحت در مسیر رشد و مقیاس‌پذیری حرکت کند.