دربارهٔ این فصل
یادداشتِ همراه نوارتا حالا به این فکر کرده‌اید که چرا وقتی یک کتابخانه یا بسته را در پروژه‌تان آپدیت می‌کنید، ناگهان بخش‌های کاملاً بی‌ربطی از برنامه از کار می‌افتند؟ چطور ممکن است کدی که سال‌ها بدون مشکل کار کرده، با یک تغییر کوچک در پشتهٔ فنی زیرین، کل سیستم را زمین بزند؟
در فصل بیست‌ویکم کتاب «مهندسی نرم‌افزار در گوگل» نوشتهٔ «تیتوس وینترز، تام مانشریک و هایروم رایت»، به سراغ یکی از پیچیده‌ترین و کم‌درک‌شده‌ترین چالش‌ها در دنیای کدنویسی، یعنی مدیریت وابستگی (Dependency Management) رفته‌اند و بررسی کرده‌اند که چطور مدیریت این شبکه‌های پیچیده می‌توانند آیندهٔ پروژه‌های نرم‌افزاری را تضمین یا تخریب کنند.
مشکل اصلی اینجاست که برنامه‌نویسان اغلب به وابستگی‌ها به چشم تکه‌کدهایی منفرد نگاه می‌کنند، در حالی که ما با یک شبکهٔ درهم‌تنیده از کتابخانه‌ها روبرو هستیم که تغییر در یک نقطه از آن، موجی از تغییرات را در سراسر سیستم ایجاد می‌کند. گزینه‌های پیش روی تیم‌ها از انجماد نسخه‌ها و تغییر ندادن هیچ‌چیز تا استفاده از مدل‌های پیچیده متغیر است، اما معاملهٔ اصلی اینجاست: استفاده از کد دیگران سرعت توسعه را بالا می‌برد اما هزینهٔ نگهداری درازمدت و ریسک خرابی را به شدت افزایش می‌دهد. برای نمونه، اگر دو کتابخانهٔ مجزا در پروژهٔ شما به دو نسخهٔ ناسازگار از یک کتابخانهٔ پایه نیاز داشته باشند، با یک بن‌بست جدی در ساختار پروژه روبه‌رو خواهید شد.
وقتی صحبت از مقیاس و زمان می‌شود، مسئله ابعاد تازه‌ای به خود می‌گیرد و قانون هایروم (Hyrum's Law) وارد میدان می‌شود که به این معناست: با داشتن تعداد کافی کاربر، هر رفتار واقعی از سیستم شما، حتا رفتارهای مستندنشده، توسط کسی به عنوان قرارداد استفاده خواهد شد. گزینه‌های مختلفی مثل نسخه‌گذاری معنایی (Semantic Versioning) تلاش می‌کنند با اعداد و ارقام این ریسک را مدیریت کنند، اما این روش‌ها در مقیاس بزرگ اغلب شکست می‌خورند زیرا نمی‌توانند تمام وابستگی‌های پنهان و رفتارهای ناخواسته را پیش‌بینی کنند.
در دنیای مهندسی نرم‌افزار، وابستگی‌ها کدهای رایگان و بدون هزینه‌ای نیستند که بتوانیم به راحتی آن‌ها را به پروژه تزریق کنیم و فراموششان کنیم. برای مقابله با این چالش‌ها، پیشنهاد من این است که پیش از افزودن هر کتابخانهٔ خارجی، نه تنها به کارایی امروز آن، بلکه به هزینهٔ پنهان آپدیت‌های سال‌های آینده و توانایی تیم در نگهداری آن فکر کنید و تا جای امکان، ترجیح دهید مسائل را درون سازمان خود حل کنید تا اینکه به کتابخانه‌های کنترل‌نشده وابسته شوید.
مدیریت وابستگی‌ها هنرِ تعادل میان استفاده از کدهای آماده و پذیرش ریسک تغییرات در طول زمان است و شناخت این مرز باریک، تفاوت میان یک نرم‌افزار شکننده و یک سیستم پایدار را رقم می‌زند.