অ্যাপ ডেভেলপমেন্টে লিগ্যাসি — এটি কী, ঝুঁকি এবং কাজের কৌশল

অ্যাপ ডেভেলপমেন্টে লিগ্যাসি কী

লিগ্যাসি — কোড বা সিস্টেম যা প্রোডাকশনে চলতে থাকে কিন্তু আধুনিক মানের মান পূরণ করে না। লিগ্যাসি একটি পুরনো ভাষায় লেখা হতে পারে (যেমন, Objective-C Swift-এর পরিবর্তে), অসমর্থিত লাইব্রেরি বা আর্কিটেকচারাল প্যাটার্ন ব্যবহার করতে পারে যা দীর্ঘদিন ধরে অ্যান্টি-প্যাটার্ন হিসেবে বিবেচিত।

লিগ্যাসির মূল বৈশিষ্ট্য হল পরীক্ষার অনুপস্থিতি। Michael Feathers (2004)-এর সংজ্ঞা অনুযায়ী, লিগ্যাসি কোড হল পরীক্ষাবিহীন কোড। যদি আপনি নিরাপদে আচরণ পরিবর্তন করতে না পারেন, তাহলে সিস্টেম বয়স নির্বিশেষে লিগ্যাসি অবস্থায় রয়েছে। ইউনিট টেস্ট ছাড়া নতুন কোড প্রথম দিন থেকেই লিগ্যাসি।

লিগ্যাসি অগত্যা খারাপ নয়। Java 8-এ একটি সুপরিকল্পিত সিস্টেম, কোরুটিন সহ Kotlin-এ বিশৃঙ্খল কোডের চেয়ে বেশি নির্ভরযোগ্য এবং বোধগম্য হতে পারে। কোডের বয়স গুণমানের সূচক নয় — গুরুত্বপূর্ণ হল সিস্টেমটি কত সহজে পরিবর্তন ও সম্প্রসারণ করা যায়।

কেন লিগ্যাসি কোড স্বাভাবিক

প্রত্যেক সফল সিস্টেম সময়ের সাথে সাথে লিগ্যাসি হয়ে যায়। এটি একটি স্বাভাবিক প্রক্রিয়া: প্রযুক্তি কোড পুনর্লিখনের চেয়ে দ্রুত বিকশিত হয়। ৫ বছর আগে Swift 2-এ লেখা একটি অ্যাপ আজ লিগ্যাসি, যদিও এটি তৈরির সময় আধুনিক ছিল।

লিগ্যাসির ব্যবসায়িক মূল্য প্রায়ই অবমূল্যায়িত হয়। সিস্টেম নির্ভরযোগ্যভাবে কাজ করে, লেনদেন প্রক্রিয়া করে, ডেটা সংরক্ষণ করে — পুনর্লিখন ঝুঁকি বহন করে। Standish Group (2024) অনুযায়ী, সম্পূর্ণ পুনর্লিখন প্রকল্পের ৩৫% ব্যর্থতায় শেষ হয়। অর্থনৈতিকভাবে লিগ্যাসি থেকে মুক্তি পাওয়া নয়, বরং এর সাথে কাজ করতে শেখা যুক্তিযুক্ত।

সেরা কৌশল — ধীরে ধীরে মাইগ্রেশন, নতুন ইন্টারফেসের পিছনে পুরনো কোড এনক্যাপসুলেট করা এবং স্বয়ংক্রিয় পরীক্ষা। লিগ্যাসি তখনই সমস্যা হয় যখন এটি পূর্বাভাসযোগ্য খরচে পরিবর্তনযোগ্য থাকে না।

লিগ্যাসি সিস্টেমের প্রধান লক্ষণ

স্বয়ংক্রিয় পরীক্ষার অভাব — প্রধান সূচক। যদি একটি লাইন পরিবর্তনের পর ডেভেলপার পরীক্ষা চালিয়ে নিশ্চিত করতে না পারেন যে কিছু ভাঙেনি — আপনি লিগ্যাসির সম্মুখীন। অতিরিক্ত লক্ষণ: ডিপ্লয় প্রক্রিয়ায় ঘন্টা লাগে এবং ম্যানুয়াল পদক্ষেপ প্রয়োজন।

ডকুমেন্টেশন কোডের সাথে মেলে না — আরেকটি চিহ্ন। আর্কিটেকচারাল ডায়াগ্রাম পুরনো, মন্তব্য এমন আচরণ বর্ণনা করে যা ইতিমধ্যে পরিবর্তিত হয়েছে। নতুন ডেভেলপারের জন্য শেখার সময় এক মাসের বেশি — উচ্চ জটিলতা এবং কম রক্ষণাবেক্ষণযোগ্যতার লক্ষণ।

অতিরিক্ত লক্ষণ: স্পষ্ট সীমানা ছাড়া মনোলিথিক আর্কিটেকচার, প্রধান যাচাই পদ্ধতি হিসেবে ম্যানুয়াল পরীক্ষা, দীর্ঘ CI পাইপলাইন (৩০ মিনিটের বেশি), বর্তমান সংস্করণ ছাড়া লাইব্রেরি ব্যবহার, এবং সম্পর্কিত মডিউল ভাঙা ছাড়া নির্ভরতা আপডেট করতে অক্ষমতা।

ভঙ্গুর কোডের ঘটনা — এক জায়গায় পরিবর্তন তিনটি অন্য জায়গা ভেঙে দেয়। এটি টাইট কাপলিংয়ের ফল, যখন মডিউল একে অপর সম্পর্কে খুব বেশি জানে। কাপলিং যত বেশি, সিস্টেম তত দ্রুত লিগ্যাসি বিভাগে চলে যায়।

পুরনো কোড নিয়ে কাজের ঝুঁকি

গতি হ্রাস — প্রধান ঝুঁকি। একটি সাধারণ ফিচার যোগ করতে কোড অধ্যয়নে ঘন্টা এবং পরীক্ষায় দিন লাগে। Stripe (2024) অনুযায়ী, ডেভেলপাররা তাদের ৩৩% সময় টেকনিক্যাল ডেট কাটিয়ে উঠতে ব্যয় করে, যা সরাসরি প্রকল্পে লিগ্যাসি মডিউলের উপস্থিতির সাথে সম্পর্কিত।

বিশেষজ্ঞতা ফাঁস — মূল কোডের লেখক কোম্পানি ছেড়ে চলে যান এবং ডকুমেন্টেশন অসম্পূর্ণ। নতুন ডেভেলপাররা অপরিচিত মডিউল স্পর্শ করতে ভয় পান, যার ফলে হিমায়িত কোডের প্রভাব পড়ে: মডিউল বিকশিত হয় না কিন্তু কাজ করতে থাকে। এই ধরনের সিস্টেমের বাস ফ্যাক্টর গুরুতরভাবে কম।

নিরাপত্তা — পুরনো লাইব্রেরিতে পরিচিত দুর্বলতা থাকে। Java প্রকল্পে OpenSSL 1.0.2 বা Jackson-এর পুরনো সংস্করণ ব্যবহার করা নিরাপত্তা ঘটনার সরাসরি পথ যা ব্যবসার সুনাম এবং গ্রাহকদের ক্ষতি করতে পারে।

টিমের অনুপ্রেরণা হ্রাস — উন্নতির কৌশল ছাড়া লিগ্যাসি নিয়ে কাজ ডেভেলপার সন্তুষ্টি কমিয়ে দেয়। টিম পণ্য নিয়ে গর্বিত হওয়া বন্ধ করে দেয়, কর্মচারী টার্নওভার বেড়ে যায়, যা সিস্টেম উন্নয়নকে আরও ধীর করে দেয়।

লিগ্যাসি রিফ্যাক্টরিং কৌশল

Characterization tests — লিগ্যাসি কোডে কোনো পরিবর্তনের আগে প্রথম ধাপ। পরিচিত ইনপুট ডেটায় কোড চালান এবং প্রত্যাশিত আউটপুট রেকর্ড করুন। এই পরীক্ষাগুলি বর্তমান আচরণকে একটি নির্দিষ্টকরণ হিসাবে ক্যাপচার করে। Golden master testing — একটি পদ্ধতি যেখানে আউটপুট একটি রেফারেন্স ফাইলের সাথে তুলনা করা হয়।

Seam বিশ্লেষণ — সেই বিন্দুগুলি খুঁজে বের করা যেখানে আচরণ পরিবর্তন না করেই কাপলিং ভাঙা যায়। Michael Feathers বিভিন্ন ধরনের seams চিহ্নিত করেন: preprocessor seam, object seam, link seam। Object seam সবচেয়ে সাধারণ: একটি ইন্টারফেসের মাধ্যমে বাস্তব অবজেক্টকে টেস্ট স্টাব দিয়ে প্রতিস্থাপন করা।

Sprout method এবং Sprout class — পুরনো কোডের ভিতরে না হয়ে পাশে নতুন কোড যোগ করার কৌশল। বিদ্যমান মেথড পরিবর্তন করার পরিবর্তে, পছন্দসই লজিক সহ একটি নতুন মেথড তৈরি করুন এবং পুরনো থেকে এটি কল করুন। এতে কাজ করা কোড ভাঙার ঝুঁকি কমে যায়।

উদাহরণ: লিগ্যাসিতে লগিং যোগ করা

class LegacyPaymentProcessor {
    def process(payment) {
        // পুরনো কোডের ২০০ লাইন যা স্পর্শ করা উচিত নয়
        logPayment(payment) // sprout পদ্ধতি
    }
    def logPayment(payment) {
        // পুরনো কোডের পাশে যোগ করা নতুন কোড
    }
}

আধুনিক টেক স্ট্যাকে মাইগ্রেশন

Strangler Fig প্যাটার্ন — লিগ্যাসি মাইগ্রেশনের জন্য প্রস্তাবিত পদ্ধতি। একটি নতুন মডিউল সমান্তরালে তৈরি করা হয়, ট্রাফিক ধীরে ধীরে পুরনো থেকে নতুনে স্যুইচ করা হয়। পুরনো মডিউল স্বাভাবিকভাবেই শেষ হয়ে যায় যখন এটি অনুরোধ পাওয়া বন্ধ করে দেয়। প্যাটার্ন ঝুঁকি কমায় এবং সমস্যার ক্ষেত্রে রোলব্যাকের অনুমতি দেয়।

Branch by Abstraction — একটি কৌশল যেখানে পুরনো এবং নতুন বাস্তবায়নের উপর একটি অ্যাবস্ট্র্যাকশন তৈরি করা হয়। ক্লায়েন্ট কোড অ্যাবস্ট্র্যাকশনে স্যুইচ করে, এবং পুরনো বাস্তবায়ন ধীরে ধীরে প্রতিস্থাপিত হয়। উদাহরণ: একটি ইউনিফাইড NetworkService প্রোটোকলের মাধ্যমে AFNetworking থেকে Alamofire-এ নেটওয়ার্কিং লেয়ার প্রতিস্থাপন করা।

ধাপে ধাপে মাইগ্রেশন — স্থানান্তরকে ছোট ছোট ধাপে ভাঙা: পুরনো মডিউল এনক্যাপসুলেট করুন → পরীক্ষা লিখুন → নতুন মডিউল তৈরি করুন → সমান্তরালে চালান → পুরনো মডিউল সরান। প্রতিটি ধাপ একটি স্থিতিশীল সিস্টেম অবস্থায় শেষ হয়, যা যেকোনো মুহূর্তে ডিপ্লয়মেন্টের অনুমতি দেয়।