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