پروجیکٹس میں ٹیکنالوجی چڑیا گھر: یہ کیا ہے، وجوہات اور حل

پروجیکٹ میں ٹیکنالوجی چڑیا گھر کیا ہے

ٹیکنالوجی چڑیا گھر ایک ایسی صورت حال ہے جب کوئی پروجیکٹ یا کمپنی ایک ہی کام کو حل کرنے کے لیے ضرورت سے زیادہ تعداد میں متنوع اوزار استعمال کرتی ہے۔ مثال کے طور پر، تین مختلف HTTP کلائنٹ (Alamofire، OkHttp، Ktor)، دو اسٹیٹ مینیجر (Redux، MobX)، اور تین ڈیٹا بیس (Realm، CoreData، SQLite)۔

چڑیا گھر اور مختلف کاموں کے لیے مختلف اوزاروں کے شعوری انتخاب کے درمیان فرق حکمت عملی کی عدم موجودگی ہے۔ اگر ٹیم A React Native کا انتخاب کرتی ہے، ٹیم B Flutter کا انتخاب کرتی ہے، اور ٹیم C Kotlin Multiplatform کا انتخاب کرتی ہے بغیر کسی مشترکہ فیصلے کے — یہ چڑیا گھر ہے۔ تنوع خود نقصان دہ نہیں ہے، اس کی بے قابو نوعیت نقصان دہ ہے۔

پروجیکٹ میں ہر نیا اسٹیک ڈویلپرز کے لیے علمی بوجھ بڑھاتا ہے۔ مؤثر طریقے سے کام کرنے کے لیے، استعمال کردہ تمام ٹیکنالوجیز کی باریکیوں کو یاد رکھنا ضروری ہے۔ Google (2024) کے مطابق، مختلف اسٹیک کے درمیان سیاق و سباق کی تبدیلی متحد تکنیکی ماحول میں کام کرنے کے مقابلے میں ڈویلپر کی پیداواری صلاحیت کو 23% کم کر دیتی ہے۔

ٹیکنالوجی چڑیا گھر کی وجوہات

وکندریقرت فیصلے بنیادی وجہ ہیں۔ ہر ٹیم مجموعی حکمت عملی کو مدنظر رکھے بغیر اپنے پروجیکٹ کے لیے ٹیکنالوجی کا انتخاب کرتی ہے۔ بیک اینڈ ٹیم Kotlin استعمال کرتی ہے، ML ٹیم Python استعمال کرتی ہے، موبائل ٹیم Flutter استعمال کرتی ہے۔ انفرادی طور پر، فیصلے درست ہیں، لیکن مل کر وہ ایک چڑیا گھر بناتے ہیں۔

انضمام و حصول (M&A) — جب کوئی کمپنی دوسری کمپنی کو حاصل کرتی ہے، تو ٹیکنالوجی اسٹیک ضم ہو جاتے ہیں۔ دو نظام ایک ہی مسئلہ کو مختلف طریقوں سے حل کرتے ہیں۔ مثال: ایک اسٹارٹ اپ کے حصول کے بعد، ایک بڑی کمپنی کو Ruby on Rails اسٹیک ملتا ہے، حالانکہ اندرونی معیار Java Spring ہے۔ سوال پیدا ہوتا ہے: دوبارہ لکھیں یا دو اسٹیک کو متوازی طور پر برقرار رکھیں۔

بدلتی ہوئی رجحان ساز ٹیکنالوجیز — ہر ہائپ سائیکل ایک نیا اسٹیک شامل کرتا ہے۔ 2015 میں، سب AngularJS میں لکھتے تھے، 2017 میں — React میں، 2020 میں — Svelte میں۔ نظم و ضبط کے بغیر، ایک پروجیکٹ مختلف ادوار کی تہیں جمع کرتا ہے۔ میراثی ماڈیول جو کام کرتے ہیں لیکن تعاون یافتہ نہیں ہیں، اسے جلدی ختم کرنے کی صلاحیت کے بغیر غیر یکسانیت بڑھاتے ہیں۔

چڑیا گھر ٹیم اور کاروبار کے لیے کیوں خطرناک ہے

نئے ڈویلپرز کی آن بورڈنگ ایک کے بجائے 5+ مختلف ٹیکنالوجیز سیکھنے میں بدل جاتی ہے۔ پروجیکٹ میں شامل ہونے میں ایک ہفتے کے بجائے، ایک نیا فرد استعمال کردہ تمام اوزاروں میں مہارت حاصل کرنے میں ایک مہینہ گزارتا ہے۔ پیداواری صلاحیت تک کا وقت پروجیکٹ میں اسٹیک کی تعداد کے تناسب سے بڑھتا ہے۔

سیاق و سباق کی تبدیلی — ایک ڈویلپر جو دن میں 3+ اسٹیک کے ساتھ کام کرتا ہے، ہر تبدیلی کے بعد سیاق و سباق کو بحال کرنے میں 30% تک وقت گزارتا ہے۔ کیلیفورنیا یونیورسٹی (2023) کے مطابق، ہر تبدیلی کے بعد اصل پیداواری صلاحیت کی سطح پر واپس آنے میں 23 منٹ لگتے ہیں۔ دن میں 5 تبدیلیوں کے ساتھ — تقریباً 2 گھنٹے ضائع۔

سیکیورٹی کے خطرات — ہر اسٹیک کو اپ ڈیٹس، کمزوریوں کی نگرانی اور بہترین طریقوں کے علم کی ضرورت ہوتی ہے۔ ایک ٹیم ایک ساتھ تمام ٹیکنالوجیز میں ماہر نہیں ہو سکتی۔ انحصار تھکاوٹ — جب استعمال کردہ لائبریریوں کی تعداد ٹیم کی انہیں ٹریک اور اپ ڈیٹ کرنے کی صلاحیت سے تجاوز کر جائے — مصنوعات کی سیکیورٹی کے لیے براہ راست خطرہ ہے۔

بنیادی ڈھانچے کی پیچیدگی — 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 ٹیکنالوجی تنوع پر قابو پانے والی ٹیموں کے لیے ایک معیار ہے۔

Technology Review Board — سرکردہ ڈویلپرز کی ایک کمیٹی جو پروجیکٹ میں نئی ٹیکنالوجیز کی منظوری دیتی ہے۔ فیصلے معیار کی بنیاد پر کیے جاتے ہیں: موجودہ اسٹیک کے ساتھ مطابقت، کمیونٹی سپورٹ، منتقلی کی لاگت، ہنر کی دستیابی۔ 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()
        }
    }
}