YAGNI Design Principle

তুমি কি কখনো এমন কোড লিখেছ, যা প্রজেক্টে যুক্ত করার পর আর কখনোই ব্যবহার হয়নি? অথবা, "ভবিষ্যতে কাজে লাগতে পারে" ভেবে একগাদা ফিচার আগেভাগেই বানিয়ে রেখেছ, কিন্তু পরে দেখা গেল ক্লায়েন্ট বা ইউজারের সেগুলো আদতেই দরকার নেই? যদি তোমার উত্তর 'হ্যাঁ' হয়, তবে YAGNI প্রিন্সিপালটি বিশেষভাবে তোমার জন্যই তৈরি হয়েছে!

YAGNI এর পূর্ণরূপ হলো—You Ain't Gonna Need It (তোমার এটা লাগবে না)। এটি Extreme Programming (XP) এবং Agile সফটওয়্যার ডেভেলপমেন্টের অন্যতম শক্তিশালী একটি নীতি। এর মূল কথা খুবই সহজ এবং স্পষ্ট: "যতক্ষণ না কোনো ফিচার বা কোডের সত্যিকার অর্থে প্রয়োজন হচ্ছে, ততক্ষণ সেটি লিখবে না।"

অনেক ডেভেলপারই "What if" বা "ভবিষ্যতে যদি এমন হয়" ট্র্যাপে পা দেন। তারা সম্ভাব্য প্রয়োজনীয়তা অনুমান করে (যাকে Over-engineering বলা হয়) সিস্টেমে অপ্রয়োজনীয় ফিচার, ভেরিয়েবল বা ক্লাস যোগ করে ফেলেন। কিন্তু সফটওয়্যার ডেভেলপমেন্টে ভবিষ্যৎ নিখুঁতভাবে অনুমান করা প্রায় অসম্ভব। এই অপ্রয়োজনীয় কোডগুলো সিস্টেমের জটিলতা বাড়ায়, মেইনটেন্যান্স কঠিন করে তোলে এবং অযথাই সময় নষ্ট করে।

কেন YAGNI এতটা গুরুত্বপূর্ণ?

তুমি যদি YAGNI অনুসরণ করো, তবে তোমার ডেভেলপমেন্ট প্রসেসে বেশ কিছু বৈপ্লবিক পরিবর্তন আসবে:

১. Time and Cost Efficiency (সময় ও অর্থের সাশ্রয়): যে ফিচারটি এখন লাগছেই না, তার পেছনে সময় ব্যয় করা মানে প্রোডাক্টিভিটি নষ্ট করা। YAGNI বর্তমানের আসল সমস্যার দিকে ফোকাস করতে সাহায্য করে। ২. Reduces Technical Debt (টেকনিক্যাল ডেবট কমানো): অব্যবহৃত কোড বা "Dead Code" প্রজেক্টের সাইজ বাড়ায়। পরবর্তীতে অন্য ডেভেলপাররা এই কোড দেখে কনফিউজড হন যে, এটি আসলে কোথায় ব্যবহৃত হচ্ছে। ৩. Faster Delivery (দ্রুত রিলিজ): শুধু বর্তমান রিকোয়ারমেন্ট অনুযায়ী কাজ করলে প্রজেক্ট দ্রুত শেষ হয় এবং ক্লায়েন্টকে দ্রুত ডেলিভারি দেওয়া যায়। ৪. Less Testing Overhead (টেস্টিংয়ের ঝামেলা কমানো): তুমি যে কোডটি লিখবে, তার জন্য ইউনিট টেস্টও (Unit Test) লিখতে হবে। অপ্রয়োজনীয় ফিচারের জন্য টেস্ট লিখে সময় নষ্ট করার কোনো মানে নেই।

YAGNI না মানলে বনাম মানলে

ধরো, তুমি একটি ই-কমার্স ওয়েবসাইটের জন্য শুধুমাত্র একটি পার্সেন্টেজ ডিসকাউন্ট সিস্টেম (Discount System) তৈরি করছ। কিন্তু কাজ করতে গিয়ে তোমার মনে হলো, "ভবিষ্যতে তো কুপন কোড সিস্টেমও লাগতে পারে, তাই সেটাও একসাথে লিখে ফেলি!"

Bad Practice (YAGNI ভঙ্গ করে ভবিষ্যতের কোড লেখা):

class DiscountSystem:
    def __init__(self):
        self.discount_percentage = 10.0
        # Added for future use, not required right now
        self.coupons = {}  

    def apply_discount(self, price):
        return price - (price * self.discount_percentage / 100)

    # Developer assumes coupon feature will be needed in the future
    def add_coupon(self, code, amount):
        self.coupons[code] = amount

    def apply_coupon(self, price, code):
        if code in self.coupons:
            return price - self.coupons[code]
        return price

# Usage
system = DiscountSystem()
print(system.apply_discount(500))

# Wasted effort on writing and maintaining these extra lines
system.add_coupon("SAVE50", 50)
print(system.apply_coupon(500, "SAVE50"))

সমস্যা: এখানে add_coupon এবং apply_coupon ফিচারগুলো বর্তমানে দরকার নেই। কয়েক মাস পর হয়তো ক্লায়েন্ট জানাল যে তাদের কুপন সিস্টেমের কোনো প্ল্যানই নেই। এর মানে হলো, তুমি শুধু সময় নষ্ট করেছ এবং কোডবেস জটিল করেছ।

Good Practice (YAGNI অনুসরণ করে সঠিক কোড):

class DiscountSystem:
    def __init__(self):
        self.discount_percentage = 10.0

    # Only writing what is required today
    def apply_discount(self, price):
        return price - (price * self.discount_percentage / 100)

# Usage
system = DiscountSystem()
print(system.apply_discount(500))

সুবিধা: দ্বিতীয় কোডটিতে শুধুমাত্র প্রয়োজনীয় ডিসকাউন্ট সিস্টেম রাখা হয়েছে। কোডটি একদম ক্লিন, বুঝতে সহজ এবং এখানে কোনো লুকানো বাগ থাকার সম্ভাবনা নেই। পরবর্তীতে যদি আসলেই কুপন সিস্টেম দরকার হয়, তখন ওপেন/ক্লোজড প্রিন্সিপাল (OCP) ব্যবহার করে সহজেই তা যুক্ত করা যাবে।

YAGNI vs Over-engineering (কিছু মিসিং কনসেপ্ট)

অনেকে মনে করেন YAGNI মানতে গিয়ে সফটওয়্যারের আর্কিটেকচার হয়তো দুর্বল হয়ে যাবে। এটি সম্পূর্ণ ভুল ধারণা। YAGNI মানে এই নয় যে তুমি বাজে কোড লিখবে বা স্কেলেবিলিটির কথা ভাববে না। এর আসল অর্থ হলো: তুমি সলিড এবং এক্সটেনসিবল আর্কিটেকচার বানাবে, কিন্তু ফিচারের ইমপ্লিমেন্টেশন শুধু ততটুকুই করবে যতটুকু আজ তোমার দরকার।

কখন এবং কীভাবে YAGNI প্রয়োগ করবে?

নতুন কোনো লজিক, ফাংশন বা ফিচার লেখার আগে নিজেকে সবসময় একটি প্রশ্ন করবে "এটি কি এখনই, এই স্প্রিন্টে বা রিলিজেই দরকার?"

  • যদি উত্তর হয় 'হ্যাঁ', তবে সেটি ডেভেলপ করো।

  • যদি উত্তর হয় 'না, কিন্তু আগামী মাসে লাগতে পারে', তবে সেটি ব্যাকলগে (Backlog) বা টু-ডু লিস্টে টুকে রাখো। কিন্তু আজকে তার জন্য এক লাইন কোডও লিখবে না।

YAGNI না মানলে কী সমস্যা হয়?

  • কোডবেস ভারী (Bloated) হওয়া: অপ্রয়োজনীয় কোডের কারণে প্রজেক্টের সাইজ অযথাই বড় হয়ে যায়।

  • মেইনটেন্যান্স নাইটমেয়ার: যে ফিচার ব্যবহারই হচ্ছে না, সিস্টেম আপডেট করার সময় সেগুলোর কথাও মাথায় রাখতে হয়, যা খুবই কষ্টকর।

  • ডেডলাইন মিস হওয়া: ফিউচার ফিচারের পেছনে সময় দেওয়ায় বর্তমানের কোর ফিচারগুলোর কাজ পিছিয়ে যায়।

YAGNI প্রিন্সিপাল মানলে কোড থাকে ক্লিন, সহজ এবং কার্যকরী। এক কথায়, যা আজ দরকার নেই, তা আজ লিখবে না। শুধুমাত্র বর্তমান প্রয়োজনের ওপর ভিত্তি করে ডেভেলপ করো, দেখবে তোমার সফটওয়্যার ইঞ্জিনিয়ারিং লাইফ অনেক বেশি চিন্তামুক্ত এবং গোছানো হয়ে গেছে।