প্রকল্পে প্রযুক্তি চিড়িয়াখানা: এটি কী, কারণ এবং সমাধান

প্রকল্পে প্রযুক্তি চিড়িয়াখানা কী

প্রযুক্তি চিড়িয়াখানা হল এমন একটি পরিস্থিতি যখন একটি প্রকল্প বা কোম্পানি একই কাজ সমাধানের জন্য অত্যধিক সংখ্যক ভিন্ন ভিন্ন টুল ব্যবহার করে। উদাহরণস্বরূপ, তিনটি ভিন্ন 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()
        }
    }
}