باغ‌وحش فناوری در پروژه‌ها: چیست، علل و روش‌ها

باغ‌وحش فناوری در پروژه چیست

باغ‌وحش فناوری — وضعیتی است که در یک پروژه یا شرکت از تعداد بیش از حد ابزارهای متنوع برای حل یک مسئله استفاده می‌شود. مثلاً سه کلاینت HTTP مختلف (Alamofire، OkHttp، Ktor)، دو مدیریت حالت (Redux، MobX) و سه پایگاه داده (Realm، CoreData، SQLite).

تفاوت باغ‌وحش با انتخاب آگاهانه ابزارهای مختلف برای وظایف مختلف در نبود استراتژی است. اگر تیم A React Native، تیم B Flutter و تیم C Kotlin Multiplatform را بدون تصمیم مشترک انتخاب کند — این باغ‌وحش است. تنوع به خودی خود مضر نیست، آنچه مضر است عدم کنترل آن است.

هر پشته جدید در پروژه بار شناختی برنامه‌نویسان را افزایش می‌دهد. برای کار مؤثر باید نکات ظریف همه فناوری‌های استفاده‌شده را به خاطر داشت. طبق داده‌های Google (2024)، تغییر زمینه بین پشته‌های مختلف بهره‌وری برنامه‌نویس را ۲۳٪ در مقایسه با کار در محیط فناوری یکپارچه کاهش می‌دهد.

علل پیدایش باغ‌وحش فناوری

تصمیمات غیرمتمرکز — علت اصلی. هر تیم فناوری‌ها را برای پروژه خود بدون توجه به استراتژی کلی انتخاب می‌کند. تیم بک‌اند از Kotlin، تیم ML از Python، تیم موبایل از Flutter استفاده می‌کند. به طور جداگانه تصمیمات درست هستند، اما با هم باغ‌وحش ایجاد می‌کنند.

ادغام‌ها و اکتساب‌ها — وقتی شرکتی دیگری را تصاحب می‌کند، پشته‌های فناوری با هم ادغام می‌شوند. دو سیستم یک وظیفه را به روش‌های مختلف حل می‌کنند. مثال: پس از خرید استارت‌آپ، شرکت بزرگ پشته آن را روی Ruby on Rails دریافت می‌کند، در حالی که استاندارد داخلی Java Spring است. این سؤال مطرح می‌شود: بازنویسی کند یا دو پشته را به صورت موازی نگه دارد.

تغییر فناوری‌های مد روز — هر چرخه hype یک پشته جدید اضافه می‌کند. در ۲۰۱۵ همه AngularJS می‌نوشتند، در ۲۰۱۷ — React، در ۲۰۲۰ — Svelte. بدون انضباط، پروژه لایه‌هایی از دوران‌های مختلف جمع می‌کند. ماژول‌های قدیمی که کار می‌کنند اما پشتیبانی نمی‌شوند، بدون امکان حذف سریع تنوع ایجاد می‌کنند.

چرا باغ‌وحش برای تیم و کسب‌وکار خطرناک است

راه‌اندازی برنامه‌نویسان جدید به یادگیری ۵+ فناوری مختلف به جای یک فناوری تبدیل می‌شود. به جای یک هفته برای آشنایی با پروژه، تازه‌کار یک ماه وقت صرف تسلط بر همه ابزارهای استفاده‌شده می‌کند. زمان رسیدن به بهره‌وری متناسب با تعداد پشته‌های پروژه افزایش می‌یابد.

تغییر زمینه — برنامه‌نویسی که با ۳+ پشته در طول روز کار می‌کند تا ۳۰٪ زمان را برای بازیابی زمینه پس از هر تغییر از دست می‌دهد. طبق داده‌های University of California (2023)، پس از هر تغییر برای بازگشت به سطح اولیه بهره‌وری ۲۳ دقیقه نیاز است. با ۵ تغییر در روز — تقریباً ۲ ساعت از دست می‌رود.

ریسک‌های امنیتی — هر پشته نیاز به به‌روزرسانی، نظارت بر آسیب‌پذیری‌ها و دانش بهترین شیوه‌ها دارد. تیم نمی‌تواند همزمان در همه فناوری‌ها متخصص باشد. خستگی وابستگی — وقتی تعداد کتابخانه‌های استفاده‌شده از توانایی تیم برای پیگیری و به‌روزرسانی آنها فراتر می‌رود — تهدیدی مستقیم برای امنیت محصول است.

پیچیدگی زیرساخت — CI/CD باید برای هر پشته پیکربندی شود. سیستم‌های ساخت مختلف (Gradle، CocoaPods، npm، pip)، نیازمندی‌های محیطی متفاوت. تیم زیرساخت منابع را برای نگهداری pipelineهای متنوع به جای بهبود آنها صرف می‌کند.

چگونه مشکل را در پروژه تشخیص دهیم

موجودی پشته — فهرست کامل فناوری‌های استفاده‌شده را تهیه کنید: زبان‌ها، فریم‌ورک‌ها، پایگاه‌های داده، CI/CD، سیستم‌های نظارت. برای هر فناوری تعداد پروژه‌ها/ماژول‌ها، سطح پشتیبانی و تعداد برنامه‌نویسان مسلط در سطح حرفه‌ای را مشخص کنید.

Technology Radar — روش ThoughtWorks که فناوری‌ها را به ۴ ربع تقسیم می‌کند: Adopt، Trial، Assess، Hold. Adopt — پشته‌های توصیه‌شده، Trial — آزمایشی، Assess — در حال ارزیابی، Hold — استفاده توصیه نمی‌شود. مثال: Flutter در Adopt، React Native در Hold — تیم‌ها می‌دانند چه چیزی را انتخاب کنند.

متریک هزینه نگهداری — تخمین بزنید چه تعداد ساعت مهندسی در ماه صرف نگهداری هر پشته می‌شود. اگر پشته ۱۰٪ منابع را مصرف می‌کند اما در ۲٪ ماژول‌ها استفاده می‌شود — کاندیدای جایگزینی است. نقشه حرارتی پشته: محورهای «تعداد پروژه‌ها» در مقابل «پیچیدگی نگهداری» مناطق مشکل‌دار را نشان می‌دهد.

روش‌های استانداردسازی پشته فناوری

سوابق تصمیمات معماری (ADR) — مستندسازی تصمیمات معماری با توجیه انتخاب فناوری. هر ADR شامل زمینه، گزینه‌های جایگزین بررسی‌شده و استدلال‌های موافق انتخاب است. Michael Nygard (2022) این رویکرد را رایج کرد و امروز ADR استانداردی برای تیم‌های کنترل‌کننده تنوع فناوری است.

کمیته بررسی فناوری — کمیسیونی از برنامه‌نویسان ارشد که فناوری‌های جدید در پروژه را تأیید می‌کند. تصمیم بر اساس معیارهایی گرفته می‌شود: سازگاری با پشته موجود، پشتیبانی جامعه، هزینه مهاجرت، در دسترس بودن استعداد. Spotify از سال ۲۰۱۸ از کمیته مشابهی استفاده می‌کند.

دروازه برای پروژه‌های جدید — قانون: هر سرویس یا ماژول جدید فقط از پشته تأییدشده استفاده می‌کند. استثناها از طریق ADR با توجیه ممکن است. مثال: میکروسرویس جدید را می‌توان در Kotlin نوشت فقط اگر تیم ثابت کند Java برای این وظیفه مناسب نیست. استفاده بی‌قیدوشرط از هر فناوری ممنوع است.

کاهش تدریجی تنوع پشته‌ها

مرحله ۱: توقف — پروژه‌های جدید روی پشته‌های پشتیبانی‌نشده متوقف می‌شوند. برای هر پشته از ربع Hold تاریخ پایان عمر تعیین می‌شود. قابلیت جدید فقط روی پشته‌های تأییدشده نوشته می‌شود. ماژول‌های قدیمی به کار خود ادامه می‌دهند اما توسعه نمی‌یابند.

مرحله ۲: تجمیع — برای هر وظیفه یک ابزار انتخاب می‌شود. یک کلاینت HTTP، یک مدیریت حالت، یک پایگاه داده. ماژول‌های روی پشته‌های جایگزین برای مهاجرت بر اساس اولویت برنامه‌ریزی می‌شوند. الگوی Strangler Fig — روش اصلی جایگزینی بدون توقف سیستم.

مرحله ۳: مهاجرت — هر اسپرینت تیم ۲۰٪ زمان را برای بازنویسی ماژول‌های بحرانی از پشته‌های قدیمی به تأییدشده اختصاص می‌دهد. معماری هدف در سند ثابت می‌شود و بدون تصمیم کمیته تغییر نمی‌کند. فرآیند بسته به اندازه باغ‌وحش از ۶ تا ۲۴ ماه طول می‌کشد.

مثال: مهاجرت کلاینت‌های HTTP

// قبل: ۳ کلاینت HTTP مختلف در یک پروژه
class HttpClientResolver {
    def resolve(moduleName) {
        switch(moduleName) {
            case "payments": return new OkHttpClient()
            case "chat": return new KtorClient()
            case "analytics": return new RetrofitClient()
        }
    }
}