حديقة الحيوان التقنية في المشاريع: ما هي، الأسباب والحلول

ما هي حديقة الحيوان التقنية في المشروع

حديقة الحيوان التقنية هي حالة يستخدم فيها مشروع أو شركة عددًا مفرطًا من الأدوات غير المتجانسة التي تحل نفس المهمة. على سبيل المثال، ثلاثة عملاء HTTP مختلفين (Alamofire، OkHttp، Ktor)، ومديري حالة (Redux، MobX)، وثلاث قواعد بيانات (Realm، CoreData، SQLite).

الفرق بين حديقة الحيوان والاختيار المدروس لأدوات مختلفة لمهام مختلفة هو غياب الاستراتيجية. إذا اختار الفريق A React Native، والفريق B اختار Flutter، والفريق C اختار Kotlin Multiplatform دون قرار مشترك — هذه حديقة حيوان. التنوع بحد ذاته ليس ضارًا، بل طبيعته غير المنضبطة هي الضارة.

كل كومة تقنية جديدة في المشروع تزيد الحمل المعرفي على المطورين. للعمل بفعالية، يجب تذكر الفروق الدقيقة لجميع التقنيات المستخدمة. وفقًا لـ Google (2024)، فإن تبديل السياق بين الأكوام المختلفة يقلل إنتاجية المطور بنسبة 23% مقارنة بالعمل في بيئة تقنية موحدة.

أسباب ظهور حديقة الحيوان التقنية

القرارات اللامركزية هي السبب الرئيسي. يختار كل فريق تقنيات لمشروعه دون النظر إلى الاستراتيجية العامة. فريق backend يستخدم Kotlin، فريق ML يستخدم Python، فريق التطبيقات المحمولة يستخدم Flutter. بشكل فردي، القرارات صحيحة، لكنها معًا تخلق حديقة حيوان.

الاندماج والاستحواذ (M&A) — عندما تستحوذ شركة على أخرى، تندمج الأكوام التقنية. نظامان يحلان نفس المشكلات بطرق مختلفة. مثال: بعد الاستحواذ على شركة ناشئة، تحصل الشركة الكبيرة على كومة Ruby on Rails، على الرغم من أن المعيار الداخلي هو Java Spring. يطرح السؤال: إعادة الكتابة أم صيانة كومتين بالتوازي.

تغير التقنيات الرائجة — كل دورة ضجة تضيف كومة جديدة. في 2015، كان الجميع يكتبون بلغة AngularJS، في 2017 — بلغة React، في 2020 — بلغة Svelte. بدون انضباط، يراكم المشروع طبقات من عصور مختلفة. الوحدات القديمة التي تعمل ولكنها غير مدعومة تضيف عدم تجانس دون إمكانية إزالته بسرعة.

لماذا تشكل حديقة الحيوان خطرًا على الفريق والأعمال

انضمام المطورين الجدد يتحول إلى تعلم 5+ تقنيات مختلفة بدلاً من واحدة. بدلاً من أسبوع للاندماج في المشروع، يقضي الوافد الجديد شهرًا في إتقان جميع الأدوات المستخدمة. الوقت حتى الإنتاجية ينمو بشكل متناسب مع عدد الأكوام في المشروع.

تبديل السياق — المطور الذي يعمل مع 3+ أكوام خلال اليوم يقضي ما يصل إلى 30% من الوقت في استعادة السياق بعد كل تبديل. وفقًا لـ جامعة كاليفورنيا (2023)، بعد كل تبديل، يستغرق العودة إلى مستوى الإنتاجية الأصلي 23 دقيقة. مع 5 تبديلات في اليوم — ما يقرب من ساعتين ضائعتين.

مخاطر الأمان — كل كومة تتطلب تحديثات ومراقبة للثغرات ومعرفة بأفضل الممارسات. لا يمكن لفريق أن يكون خبيرًا في جميع التقنيات في وقت واحد. إرهاق التبعيات — عندما يتجاوز عدد المكتبات المستخدمة قدرة الفريق على تتبعها وتحديثها — يشكل تهديدًا مباشرًا لأمان المنتج.

تعقيد البنية التحتية — CI/CD يحتاج إلى تكوين لكل كومة. أنظمة بناء مختلفة (Gradle، CocoaPods، npm، pip)، متطلبات بيئة مختلفة. فريق البنية التحتية ينفق الموارد على صيانة خطوط أنابيب غير متجانسة بدلاً من تحسينها.

كيفية تشخيص المشكلة في المشروع

جرد الأكوام — قم بتجميع قائمة كاملة بالتقنيات المستخدمة: اللغات، الأطر، قواعد البيانات، CI/CD، أنظمة المراقبة. لكل تقنية، سجل عدد المشاريع/الوحدات، مستوى الدعم وعدد المطورين المتمكنين منها على المستوى المهني.

Technology Radar — طريقة من ThoughtWorks تقسم التقنيات إلى 4 أرباع: Adopt، Trial، Assess، Hold. Adopt — الأكوام الموصى بها، Trial — التجريبية، Assess — قيد التقييم، Hold — غير موصى بها للاستخدام. مثال: Flutter في Adopt، React Native في Hold — الفرق تفهم ماذا تختار.

مقياس تكلفة الصيانة — قدر عدد ساعات الهندسة التي تُنفق على صيانة كل كومة شهريًا. إذا كانت الكومة تستهلك 10% من الموارد ولكنها تستخدم في 2% من الوحدات — فهي مرشحة للاستبدال. خريطة حرارية للكومة بمحاور "عدد المشاريع" مقابل "تعقيد الصيانة" تظهر المناطق المشكلة بوضوح.

طرق توحيد الأكوام التقنية

سجلات القرارات المعمارية (ADR) — توثيق القرارات المعمارية مع تبرير اختيار التقنية. كل ADR يحتوي على السياق والبدائل المدروسة والحجج للاختيار. Michael Nygard (2022) نشر هذا النهج، واليوم ADR هو معيار للفرق التي تتحكم في التنوع التقني.

مجلس مراجعة التقنيات — لجنة من المطورين القادة توافق على التقنيات الجديدة في المشروع. تُتخذ القرارات بناءً على معايير: التوافق مع الأكوام الموجودة، دعم المجتمع، تكلفة الترحيل، توفر المواهب. Spotify تستخدم لجنة مماثلة منذ 2018.

بوابة للمشاريع الجديدة — قاعدة: أي خدمة أو وحدة جديدة تستخدم فقط الأكوام المعتمدة. الاستثناءات ممكنة عبر ADR مع التبرير. مثال: يمكن كتابة خدمة مصغرة جديدة بلغة Kotlin فقط إذا أثبت الفريق أن Java غير مناسبة لهذه المهمة. الاستخدام غير المقيد لأي تقنية محظور.

التقليل التدريجي لتنوع الأكوام

المرحلة 1: التجميد — يتم إيقاف المشاريع الجديدة على الأكوام غير المدعومة. يتم تحديد تاريخ نهاية العمر لكل كومة في الربع Hold. الوظائف الجديدة تُكتب فقط على الأكوام المعتمدة. الوحدات القديمة تستمر في العمل ولكن لا يتم توسيعها.

المرحلة 2: الدمج — يتم اختيار أداة واحدة لكل مهمة. عميل HTTP واحد، مدير حالة واحد، قاعدة بيانات واحدة. يتم جدولة الوحدات على الأكوام البديلة للترحيل حسب الأولوية. نمط Strangler Fig هو الطريقة الرئيسية للاستبدال دون توقف النظام.

المرحلة 3: الترحيل — في كل سباق، يخصص الفريق 20% من الوقت لإعادة كتابة الوحدات الحرجة من الأكوام القديمة إلى المعتمدة. الهندسة المستهدفة تُوثق ولا تتغير دون قرار من اللجنة. تستغرق العملية من 6 إلى 24 شهرًا حسب حجم حديقة الحيوان.

مثال: ترحيل عملاء HTTP

// Before: 3 different HTTP clients in one project
class HttpClientResolver {
    def resolve(moduleName) {
        switch(moduleName) {
            case "payments": return new OkHttpClient()
            case "chat": return new KtorClient()
            case "analytics": return new RetrofitClient()
        }
    }
}