অ্যাপ ডেভেলপমেন্টে YAGNI: এটি কী, নীতির সারমর্ম এবং ব্যবহারিক সুবিধা

YAGNI কী?

YAGNI (You Aren't Gonna Need It) — এক্সট্রিম প্রোগ্রামিং (XP)-এর একটি নীতি যার অর্থ “আপনার এটি প্রয়োজন হবে না”। নিয়মটি বলে: বর্তমান ব্যবহারকারীর গল্প দ্বারা প্রয়োজনীয় নয় এমন কার্যকারিতা কখনও বাস্তবায়ন করবেন না। যদি একটি বৈশিষ্ট্য আজ প্রয়োজন না হয় — তবে এটি তৈরি করবেন না, এমনকি “প্রয়োজন হতে পারে” ভেবেও নয়।

শব্দটি রন জেফ্রিজ তৈরি করেছিলেন, যিনি এক্সপি পদ্ধতির সহ-লেখকদের একজন (কেন্ট বেকের সাথে)। জেফ্রিজ বলেছিলেন: “সবচেয়ে সহজ জিনিসটি বাস্তবায়ন করুন যা কাজ করে, এবং প্রয়োজন না হওয়া পর্যন্ত কিছু যোগ করবেন না”। YAGNI পরিকল্পনার উপর নিষেধাজ্ঞা নয়, বরং অকাল বাস্তবায়নের উপর নিষেধাজ্ঞা।

Standish Group CHAOS Report (2023) অনুসারে, একটি গড় সফটওয়্যার পণ্যের 64% বৈশিষ্ট্য খুব কমই বা কখনও ব্যবহৃত হয় না। মোবাইল অ্যাপে প্রয়োগ করলে — লেখা কোডের অর্ধেকের বেশি ব্যবহারকারীর জন্য মূল্য আনে না। YAGNI সম্পদের এই অপচয় রোধ করে।

YAGNI একটি কঠোর ফিল্টার হিসাবে প্রয়োগ করুন: প্রতিটি বৈশিষ্ট্যের প্রশ্নের উত্তর দেওয়া উচিত “এটি এখন কোন নির্দিষ্ট ব্যবহারকারীর সমস্যা সমাধান করে?” যদি উত্তর না থাকে — বৈশিষ্ট্যটি প্রয়োজনীয় নয়।

YAGNI বনাম অলসতা এবং কোণ কাটা

YAGNI মানসম্পন্ন আর্কিটেকচার প্রত্যাখ্যান নয়। YAGNI অপ্রয়োজনীয় কোড লেখা নিষিদ্ধ করে, কিন্তু সঠিক কোড লেখা নিষিদ্ধ করে না। যদি একটি বর্তমান বৈশিষ্ট্যের জন্য একটি পরিষ্কার অ্যাবস্ট্রাকশন লেয়ারের প্রয়োজন হয় — এটি তৈরি করুন। যদি লেয়ারটির প্রয়োজন না হয় — এটি তৈরি করবেন না। মূল পার্থক্য: YAGNI কার্যকারিতা সম্পর্কে, গুণমান সম্পর্কে নয়।

ডেভেলপাররা প্রায়ই YAGNI-কে ইচ্ছাকৃত টেকনিক্যাল ডেবট জমার সাথে গুলিয়ে ফেলেন (টেকনিক্যাল ডেবট সর্বদা একটি আপস, YAGNI দক্ষতার একটি নীতি)। পার্থক্য হল যে টেকনিক্যাল ডেবট স্বীকার এবং নথিভুক্ত করা হয়, যখন YAGNI লঙ্ঘন কেবল অতিরিক্ত কাজ।

নিজেকে জিজ্ঞাসা করুন: “আমি যদি এখন এই অ্যাবস্ট্রাকশনটি না তৈরি করি, তবে যখন প্রয়োজন হবে তখন রিফ্যাক্টরিং করতে কত সময় লাগবে?” যদি রিফ্যাক্টরিংয়ের সময় এখন লেখার সময়ের চেয়ে কম হয় — তবে এটি স্থগিত করুন।

মোবাইল প্রকল্পের জন্য YAGNI কেন গুরুত্বপূর্ণ?

মোবাইল ডেভেলপমেন্ট তিনটি কারণে YAGNI লঙ্ঘনের জন্য বিশেষভাবে সংবেদনশীল: APK/IPA-র আকার সরাসরি ইনস্টলেশন রূপান্তর হারকে প্রভাবিত করে, মোবাইল প্রকল্পের কম্পাইলেশন সময় কোডের পরিমাণের সাথে রৈখিকভাবে বৃদ্ধি পায়, এবং প্রতিটি অতিরিক্ত বৈশিষ্ট্য ব্যর্থতার পয়েন্ট যোগ করে। YAGNI অলসতা সম্পর্কে নয়, বরং ফোকাস সম্পর্কে।

Google Play Console Data (2023)-এর একটি গবেষণায় দেখা গেছে: APK আকারের প্রতি 10 MB ইনস্টলেশনের সম্ভাবনা 1.2% কমিয়ে দেয়। অব্যবহৃত কোড শুধু রিপোজিটরিতে আবর্জনা নয় — এটি সরাসরি আর্থিক ক্ষতি। অতিরিক্ত লাইব্রেরি (যে কার্যকারিতার জন্য “হয়তো পরে যোগ করব”) APK ফোলার সবচেয়ে সাধারণ উৎস।

Gradle Build Performance Report (2024) অনুসারে, Android প্রকল্পে প্রতিটি অতিরিক্ত মডিউল সম্পূর্ণ বিল্ড সময় 3–7 সেকেন্ড বাড়িয়ে দেয়। যদি আপনি “প্রয়োজন হতে পারে” ভেবে 5টি মডিউল যোগ করেন — বিল্ড সময় বৃদ্ধি প্রতি বিল্ডে 15–35 সেকেন্ড হবে। এক বছরে, 5 ডেভেলপারের একটি দল কম্পাইলেশনের অপেক্ষায় 200 জন-ঘণ্টা পর্যন্ত হারায়।

CI-তে বাইনারি আকার মনিটর করুন: একটি সতর্কতা সীমা নির্ধারণ করুন (যেমন, প্রতি কমিটে +500 KB)। যদি নতুন বৈশিষ্ট্য ছাড়াই আকার বেড়ে যায় — এটি YAGNI-এর লঙ্ঘন যা কোড রিভিউতে আলোচনা করা উচিত।

YAGNI বনাম গোল্ড-প্লেটিং: ব্যবহারিক উদাহরণ

গোল্ড-প্লেটিং: অকাল অ্যানিমেশন

গোল্ড-প্লেটিং — পণ্যকে “উন্নত” করার প্রচেষ্টায় প্রয়োজনীয়তার বাইরে কার্যকারিতা যোগ করা। একটি সাধারণ উদাহরণ: ডেভেলপার স্ক্রিনের মধ্যে জটিল ট্রানজিশন অ্যানিমেশন যোগ করে, যদিও ডিজাইনে একটি সাধারণ fade উল্লেখ করা আছে। অ্যানিমেশনটিতে 2 দিন সময় লাগে, ব্যবহারকারী এটি লক্ষ্য করে না, এবং বিভিন্ন ডিভাইসে বাগগুলি বছরের পর বছর প্রকল্পকে তাড়া করে।

UX Collective Annual Report (2023) অনুসারে, 78% ব্যবহারকারী অ্যানিমেশন দ্বারা নয়, গতি এবং স্থিতিশীলতা দ্বারা একটি অ্যাপ মূল্যায়ন করেন। YAGNI বলে: যদি অ্যানিমেশন প্রয়োজনীয়তায় উল্লেখ না থাকে — তবে এটি বাস্তবায়ন করবেন না। ডিজাইনার অ্যানিমেশন যোগ করবেন যখন সত্যিই একটি UX সমস্যা সমাধানের জন্য প্রয়োজন হবে।

শুধু মকআপে যা আছে তা বাস্তবায়ন করুন। যদি ডিজাইনার অ্যানিমেশন না আঁকেন — তবে এটি থাকা উচিত নয়। মকআপ থেকে যেকোনো বিচ্যুতি YAGNI-এর লঙ্ঘন।

20টি ভাষায় অকাল স্থানীয়করণ

স্টার্টআপের একটি সাধারণ ভুল: “ভবিষ্যতে আন্তর্জাতিক বাজারে প্রবেশের জন্য″ অবিলম্বে 20+ ভাষার সমর্থন তৈরি করা। YAGNI সুপারিশ করে: শুধুমাত্র বর্তমান বাজারের ভাষায় স্থানীয়করণ করুন। প্রতিটি নতুন ভাষা যোগ করতে অনুবাদকের সময়, স্ট্রিং কাটার পরীক্ষা এবং RTL লেআউট ডিবাগিং প্রয়োজন।

Deloitte Digital Globalization Survey (2022) অনুসারে, 60% মোবাইল অ্যাপ কখনও তাদের প্রথম বাজার ছেড়ে যায় না। যদি এটি আপনার ক্ষেত্রে হয় — বহুভাষিক সমর্থনে ব্যয় করা সম্পদ নষ্ট। YAGNI পদ্ধতি: ইংরেজি (ভিত্তি) + লক্ষ্য বাজারের ভাষা। অন্যগুলি — যখন প্রকৃতপক্ষে কোনো অঞ্চলে প্রবেশ করবেন।

অগ্রাধিকার নির্ধারণের জন্য YAGNI ব্যবহার করুন: যদি কোনো বৈশিষ্ট্য আগামী দুই ত্রৈমাসিকের রোডম্যাপে না থাকে — তবে এটি শুরু করবেন না। রোডম্যাপটি নথিভুক্ত এবং পণ্য ব্যবস্থাপক দ্বারা অনুমোদিত হতে হবে।

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

Android-এ YAGNI: অপ্রয়োজনীয় লাইব্রেরি যোগ করবেন না

Android প্রকল্প লাইব্রেরি মুদ্রাস্ফীতিতে ভোগে। ডেভেলপাররা Retrofit, OkHttp, Gson, Room, Dagger Hilt, Navigation Component, DataStore যোগ করে — ব্যবসায়িক যুক্তির প্রথম লাইন লেখার আগেও। YAGNI সুপারিশ করে: প্রকৃত প্রয়োজন অনুসারে লাইব্রেরি যোগ করুন, প্রতিরোধমূলকভাবে নয়।

// YAGNI লঙ্ঘন: লাইব্রেরির প্রতিরোধমূলক অন্তর্ভুক্তি
// build.gradle (module)
implementation("com.squareup.retrofit2:retrofit:2.9.0")
implementation("com.squareup.retrofit2:converter-gson:2.9.0")
implementation("androidx.room:room-runtime:2.6.0")

// এবং অ্যাপটি এখন শুধু "Hello World" দেখায়

লাইব্রেরিগুলি নিজস্ব জটিলতা সহ নির্ভরতা। প্রতিটির সংস্করণ আপডেট, ব্রেকিং চেঞ্জেসে মাইগ্রেশন প্রয়োজন এবং APK আকার বাড়ায়। যোগ করুন একটি লাইব্রেরি যখন একটি নির্দিষ্ট কাজ দেখা দেয় যা এই লাইব্রেরি সমাধান করে। OkHttp (ন্যূনতম HTTP ক্লায়েন্ট) দিয়ে শুরু করুন, যখন REST ক্লায়েন্ট প্রয়োজন তখন Retrofit যোগ করুন, এবং এভাবেই চলতে থাকে।

iOS-এ YAGNI: SwiftUI জোর করে চাপিয়ে দেবেন না

SwiftUI একটি শক্তিশালী ফ্রেমওয়ার্ক, কিন্তু এর গ্রহণ বাস্তব প্রয়োজন দ্বারা চালিত হওয়া উচিত। যদি একটি প্রকল্প iOS 14+ দিয়ে শুরু হয় এবং কাস্টম UI উপাদানের প্রয়োজনীয়তা ন্যূনতম হয় — SwiftUI একটি ভাল পছন্দ। যদি একটি প্রকল্পকে iOS 13 সমর্থন করতে হয় বা জটিল কাস্টম জেসচার প্রয়োজন — UIKit সঠিক সমাধান থাকে। YAGNI “কারণ এটি ট্রেন্ডি” বলে SwiftUI-তে মাইগ্রেট করার বিরোধী।

// YAGNI: SwiftUI থেকে প্রকৃত লাভ না থাকা পর্যন্ত UIKit ব্যবহার করুন
class ProfileViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "প্রোফাইল"
    }
}

// যদি SwiftUI প্রয়োজন হয় — UIHostingController-এর মাধ্যমে সংহত করুন
let swiftUIView = ProfileView()
let hostingVC = UIHostingController(rootView: swiftUIView)

Point-Free: “SwiftUI vs UIKit Decision Guide” (2024)-এর বিশ্লেষণ সুপারিশ করে: স্পষ্ট ব্যবসায়িক কারণ ছাড়া (যেমন, ডিজাইনারের জন্য লাইভ প্রিভিউয়ের প্রয়োজন) বিদ্যমান UIKit স্ক্রিন SwiftUI-তে মাইগ্রেট করবেন না। কাজ করা কোড পুনরায় লেখা YAGNI-এর সরাসরি লঙ্ঘন। SwiftUI — নতুন স্ক্রিনের জন্য, UIKit — বিদ্যমানের জন্য।

YAGNI অনুসরণ করার সময় সাধারণ ভুল

YAGNI খারাপ আর্কিটেকচারের অজুহাত হিসাবে

সবচেয়ে বিপজ্জনক ভুল হল খারাপ আর্কিটেকচারের অজুহাত হিসাবে YAGNI ব্যবহার করা। “আমরা রিপোজিটরি লেয়ার তৈরি করব না কারণ YAGNI — আমরা সরাসরি ViewModel-এ কুয়েরি লিখব”। এটি YAGNI নয়, এটি টেকনিক্যাল ডেবট জমা করা। YAGNI অপ্রয়োজনীয় কার্যকারিতা নিষিদ্ধ করে, আর্কিটেকচারাল অখণ্ডতা নয়।

আর্কিটেকচার রক্ষণাবেক্ষণযোগ্যতায় একটি বিনিয়োগ। যদি আপনি 3টির বেশি স্ক্রিন লিখছেন — একটি মৌলিক আর্কিটেকচারাল লেয়ার (MVVM, রিপোজিটরি) ইতিমধ্যেই ন্যায়সঙ্গত। যদি 1টি স্ক্রিন হয় — আপনি একটি সরল পদ্ধতি নিতে পারেন। চাবিকাঠি: বর্তমান বৈশিষ্ট্যের জন্য প্রয়োজনীয় আর্কিটেকচারাল ন্যূনতম নির্ধারণ করুন এবং আর যোগ করবেন না।

সিদ্ধান্তগুলিকে “আর্কিটেকচারাল” এবং “কার্যকরী”-এ ভাগ করুন। আর্কিটেকচারাল সিদ্ধান্ত (লেয়ার, নেভিগেশন, DI) YAGNI দ্বারা আচ্ছাদিত নয় — এগুলি রক্ষণাবেক্ষণের জন্য প্রয়োজনীয়। কার্যকরী সিদ্ধান্ত (বৈশিষ্ট্য, স্ক্রিনশট, অ্যানিমেশন) — আচ্ছাদিত।

API-এর সাথে কাজ করার সময় YAGNI-কে অন্ধভাবে অনুসরণ করা

অন্য চরম — ভবিষ্যতের API চুক্তি উপেক্ষা করা। একজন ডেভেলপার ব্যাকএন্ড থেকে 5টি ফিল্ড সহ JSON পান এবং শুধু 3টি পার্স করেন, কারণ “YAGNI অনুসারে বাকিগুলির প্রয়োজন নেই”। সমস্যা: যখন একটি ফিল্ড যোগ করা হয়, ব্যাকএন্ড পার্সিং ভেঙে দিতে পারে যদি প্রতিক্রিয়া পরিবর্তিত হয়। সমাধান হল সমস্ত প্রতিক্রিয়া ফিল্ড ম্যাপ করা, যদিও সব এখন ব্যবহার না হয়।

Meta API Design Guidelines (2023) অনুসারে, ক্লায়েন্টকে সার্ভার দ্বারা ফেরত দেওয়া সমস্ত ফিল্ড পার্স করতে হবে, অব্যবহৃতগুলি উপেক্ষা করে, কিন্তু সম্পূর্ণ কাঠামো বাদ না দিয়ে। YAGNI এখানে অন্য কিছু সম্পর্কে: “হয়তো ব্যাকএন্ড সেগুলি ফেরত দেবে” ভেবে যেসব ফিল্ড এখনও স্পেসিফিকেশনে নেই সেগুলির হ্যান্ডলিং যোগ করবেন না।

সম্পূর্ণ প্রতিক্রিয়া কাঠামো পার্স করুন (সার্ভার বর্তমানে যে সমস্ত ফিল্ড ফেরত দেয়)। বর্তমান API স্পেসিফিকেশনে নেই এমন ফিল্ডের হ্যান্ডলিং যোগ করবেন না। এটি YAGNI এবং পরিবর্তনের প্রতি স্থিতিস্থাপকতার মধ্যে একটি ভারসাম্য।