ডেভেলপমেন্টে জাঙ্ক — এটি কী, কেন জাঙ্ক কোড ক্ষতিকর এবং কীভাবে সরাবেন

জাঙ্ক কোড কী?

জাঙ্ক (junk code) হল কোড, কনফিগারেশন এবং ডিপেন্ডেন্সির জন্য একটি সমষ্টিগত শব্দ যা প্রকল্পে বিদ্যমান কিন্তু কোনো কার্যকরী মূল্য প্রদান করে না। জাঙ্ক অগত্যা ভাঙা বা অব্যবহৃত নয় — সমস্যা হল এর উপস্থিতি পর্যাপ্ত যুক্তি ছাড়াই প্রকল্প মেট্রিক্স খারাপ করে।

জাঙ্ক চারটি শ্রেণীতে বিভক্ত। প্রথম — অপ্রয়োজনীয় ডিপেন্ডেন্সি: একটি মাত্র ফিচারের জন্য যোগ করা লাইব্রেরি যা মানক টুল দিয়ে বাস্তবায়ন করা যেত। দ্বিতীয় — মৃত বোঝা: মন্তব্যকৃত ব্লক, টিকেট ছাড়া TODO, খালি মেথড এবং স্টাব ক্লাস। তৃতীয় — ডুপ্লিকেট সমাধান: দুটি লাইব্রেরি একই কাজ করে (যেমন একটি প্রকল্পে Gson এবং Kotlin Serialization)। চতুর্থ — ওভার-ইঞ্জিনিয়ারিং: আর্কিটেকচারাল স্তর যা ব্যবহৃত হয় না কিন্তু “শুধু ক্ষেত্রে” রক্ষণাবেক্ষণ করা হয়।

Stripe Engineering Productivity (2025) গবেষণা অনুযায়ী, একটি সাধারণ প্রকল্প থেকে 10 শতাংশ জাঙ্ক অপসারণ করলে পূর্ণ বিল্ড সময় গড়ে 22 শতাংশ কমে। কারণ: প্রতিটি অতিরিক্ত ডিপেন্ডেন্সি বিল্ড গ্রাফ বাড়ায়, প্রতিটি খালি অ্যাবস্ট্র্যাকশন বুঝতে সময় নেয়, প্রতিটি মন্তব্যকৃত ব্লক মনোযোগ বিভ্রান্ত করে।

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

জাঙ্ক ডিপেন্ডেন্সি এবং কীভাবে চিহ্নিত করবেন

জাঙ্ক ডিপেন্ডেন্সি হল লাইব্রেরি এবং প্যাকেজ যা প্রকল্পে যোগ করা হয়েছে কিন্তু কোডে সরাসরি ব্যবহৃত হয় না, অথবা শুধুমাত্র একটি ফিচারের জন্য ব্যবহৃত হয় যা মানক API দিয়ে বাস্তবায়ন করা সহজ হবে।

সাধারণ উদাহরণ: JSON প্রসেসিংয়ের জন্য লাইব্রেরি যখন প্রকল্প ইতিমধ্যে Kotlin Serialization ব্যবহার করে (দুটি পার্সার জাঙ্ক); একটি StringUtils.isEmpty কলের জন্য Apache Commons Lang লাইব্রেরি যা Kotlin এক্সটেনশন isNullOrBlank দিয়ে প্রতিস্থাপন করা যায়; দশটির মধ্যে এক মডিউলে ব্যবহৃত DI লাইব্রেরি যখন অন্যরা ম্যানুয়ালি কন্সট্রাক্টরের মাধ্যমে ডিপেন্ডেন্সি পায়।

প্রতিটি অতিরিক্ত ডিপেন্ডেন্সি বাইনারিতে শুধু অতিরিক্ত কোড নয়। এটি দুর্বলতার জন্য আক্রমণের পৃষ্ঠতল বাড়ায়: GitHub Advisory Database (2025) অনুযায়ী, মোবাইল প্রকল্পে 40 শতাংশ গুরুতর CVE ট্রানজিটিভ ডিপেন্ডেন্সি থেকে আসে যা ডেভেলপাররা নিয়ন্ত্রণ করে না। যত কম ডিপেন্ডেন্সি, তত ছোট আক্রমণের পৃষ্ঠতল।

Android প্রকল্প ডিপেন্ডেন্সি বিশ্লেষণ

// View Gradle dependency tree
./gradlew app:dependencies --configuration releaseRuntimeClasspath

// Find unused dependencies (Gradle plugin)
plugins {
    id "com.autonomousapps.dependency-analysis" version "2.0.0"
}

// Generate unused library report
./gradlew buildHealth

iOS-এর জন্য, swift package show-dependencies কমান্ড ব্যবহার করুন যা পূর্ণ ডিপেন্ডেন্সি ট্রি দেখায়। Xcode Build Timeline টুল দেখায় প্রতিটি লাইব্রেরি বিল্ডে কতটা সময় যোগ করে। যদি কোনো লাইব্রেরি 30 শতাংশ কম্পাইলেশন সময় নেয় কিন্তু একটি স্ক্রিনে ব্যবহৃত হয়, তাহলে তা অপসারণ বা প্রতিস্থাপনের প্রার্থী।

Node.js (React Native)-এর জন্য, depcheck ব্যবহার করুন — একটি ইউটিলিটি যা package.json-এ অব্যবহৃত ডিপেন্ডেন্সি খুঁজে পায়, এবং npm-check যা অতিরিক্তভাবে পুরনো সংস্করণ দেখায়। একটি নিয়ম চালু করুন: প্রতিটি নতুন ডিপেন্ডেন্সিকে “কেন মানক টুল ব্যবহার করা যাবে না” এই যুক্তিসহ কোড পর্যালোচনার মধ্য দিয়ে যেতে হবে।

মৃত ইম্পোর্ট এবং মন্তব্যকৃত কোড

মৃত ইম্পোর্ট সবচেয়ে সাধারণ ধরনের জাঙ্ক। এগুলি রানটাইমকে প্রভাবিত করে না কিন্তু কম্পাইলেশন সময় বাড়ায়: কম্পাইলার প্রতিটি ইম্পোর্ট প্রসেস করে, এমনকি অব্যবহৃতও। বড় প্রকল্পে, অব্যবহৃত ইম্পোর্ট অপসারণ বিল্ড সময় 5–10 শতাংশ কমায়।

আধুনিক IDE স্বয়ংক্রিয়ভাবে অব্যবহৃত ইম্পোর্ট ধূসর রঙে হাইলাইট করে। ফাইল সংরক্ষণে অটো-পরিষ্কার সেট করুন: IntelliJ IDEA-তে — Optimize Imports on the fly, Xcode-এ — Editor > Remove Unused Imports। CI-তে একটি পরীক্ষা যোগ করুন: লিন্টার যেন অব্যবহৃত ইম্পোর্টযুক্ত কমিট ব্লক করে।

মন্তব্যকৃত কোড আরেক ধরনের জাঙ্ক। ডেভেলপাররা রিফ্যাক্টরিংয়ের সময় কার্যকারিতা “হারানো এড়াতে” ব্লক মন্তব্য করে। তবে, git পরিবর্তনের সম্পূর্ণ ইতিহাস সংরক্ষণ করে: যেকোনো সরানো কোড একটি git revert বা git log -S কমান্ড দিয়ে পুনরুদ্ধার করা যায়। master-এ মন্তব্যকৃত কোড দলের প্রতি অসম্মান: প্রতিটি ডেভেলপার মানসিক শক্তি এই প্রশ্নে খরচ করে “কেন এটি মন্তব্য করা হয়েছে এবং কখন আনমন্তব্য করা উচিত?”

নিয়ম: রিপোজিটরিতে কোনো মন্তব্যকৃত কোড নেই। যদি কোডের প্রয়োজন না হয়, স্থায়ীভাবে মুছে ফেলুন। যদি কোড প্রয়োজনীয় কিন্তু সাময়িকভাবে নিষ্ক্রিয়, টিকেট এবং মেয়াদ শেষের তারিখসহ ফিচার টগল ব্যবহার করুন। // TODO: remove after migration-এর মতো মন্তব্য — সময়সীমা ছাড়া রাখবেন না। একটি তারিখ নির্ধারণ করুন এবং ক্যালেন্ডার দিয়ে নিজেকে মনে করান।

অপ্রয়োজনীয় অ্যাবস্ট্র্যাকশন এবং ওভার-ইঞ্জিনিয়ারিং

ওভার-ইঞ্জিনিয়ারিং হল আর্কিটেকচারাল স্তর তৈরি করা যা বর্তমান সমস্যা সমাধান করে না কিন্তু রক্ষণাবেক্ষণ দাবি করে। এটি জাঙ্কের সবচেয়ে কঠিন ধরনের একটি কারণ আনুষ্ঠানিকভাবে কোড “সঠিক”: এটি SOLID অনুসরণ করে, পরীক্ষা দ্বারা আচ্ছাদিত এবং আর্কিটেকচারের সাথে সামঞ্জস্যপূর্ণ। সমস্যা হল এটি অপ্রয়োজনীয়।

একটি ক্লাসিক উদাহরণ হল অ্যাবস্ট্র্যাক্ট UseCase ক্লাস যার একটি মাত্র invoke মেথড আছে যা শুধু একটি রিপোজিটরি কল করে। যদি UseCase কোনো যুক্তি (ক্যাশিং, রিট্রাই, ট্রান্সফর্মেশন) যোগ না করে এবং শুধু কল পাস করে, তাহলে এটি একটি অতিরিক্ত সত্তা। এটি প্রকল্পে নেভিগেশন বাড়ায়: একজন ডেভেলপার UseCase খোলে, invoke → রিপোজিটরি দেখে এবং বন্ধ করে দেয়। সময় নষ্ট, লাভ শূন্য।

আরেকটি উদাহরণ হল অতিরিক্ত প্যারামিটারাইজেশন। ছয়টি টাইপ প্যারামিটারযুক্ত জেনেরিক ইন্টারফেস যা একমাত্র জায়গায় ব্যবহৃত হয়। প্রতিটি টাইপ প্যারামিটার জ্ঞানীয় বোঝা: কোড পড়ার সময়, আপনাকে ছয়টি টাইপ মনে রাখতে হয় যখন বাস্তবে মাত্র দুটি ব্যবহৃত হয়। যদি কোনো অ্যাবস্ট্র্যাকশন পুনরায় ব্যবহৃত না হয়, তা অপ্রয়োজনীয়।

কাট-অফ মাপকাঠি: যদি কোনো অ্যাবস্ট্র্যাকশন তিনটি ভিন্ন প্রসঙ্গে পুনরায় ব্যবহৃত না হয়, তা সরিয়ে ফেলুন। অ্যাবস্ট্র্যাকশন তখনই ন্যায্য যখন এটি সত্যিই পুনরাবৃত্তির সমস্যা সমাধান করে, কাল্পনিক ভবিষ্যৎ পরিস্থিতির ভবিষ্যদ্বাণী করে না। YAGNI (You Ain’t Gonna Need It) ওভার-ইঞ্জিনিয়ারিং প্রতিরোধের সেরা নীতি।

জাঙ্ক অডিট টুল

জাঙ্ক অডিটের জন্য স্থিতিশীল বিশ্লেষণ, ডিপেন্ডেন্সি বিশ্লেষণ এবং ম্যানুয়াল পর্যালোচনার সমন্বয় প্রয়োজন। অপ্রয়োজনীয় অ্যাবস্ট্র্যাকশন সনাক্তকরণ সম্পূর্ণ স্বয়ংক্রিয় করা অসম্ভব, কিন্তু প্রযুক্তিগত জাঙ্ক (মৃত ইম্পোর্ট, অব্যবহৃত লাইব্রেরি, মন্তব্যকৃত কোড) টুল দিয়ে পাওয়া যায়।

পূর্ণ অডিটের জন্য, প্রতি স্প্রিন্ট buildHealth (Android) বা depcheck (Node.js) চালান। CI-তে একটি ড্যাশবোর্ড তৈরি করুন যা স্প্রিন্ট অনুযায়ী ডিপেন্ডেন্সি সংখ্যার প্রবণতা দেখায়। যদি সংখ্যা বাড়ে কিন্তু কার্যকারিতা আনুপাতিকভাবে না বাড়ে, দল জাঙ্ক জমা করছে।

ডুপ্লিকেট ক্লাস লক্ষ্য করুন — একটি ত্রুটি যখন দুটি লাইব্রেরিতে একই ক্লাস থাকে। এটি শুধু জাঙ্ক নয় বরং বিল্ড দ্বন্দ্বের সরাসরি উৎস। Gradle-এ, এই দ্বন্দ্ব force বা exclude-এর মাধ্যমে সমাধান করা হয়, কিন্তু প্রতিটি সমাধান সংকেত যে একটি লাইব্রেরি অপ্রয়োজনীয়।

নিয়মিত প্রকল্প পরিষ্কার করার প্রক্রিয়া

জাঙ্ক পরিষ্কার করা একবারের কর্ম নয় বরং একটি নিয়মিত প্রক্রিয়া। পদ্ধতি ছাড়া, জাঙ্ক দুই-তিন স্প্রিন্টের মধ্যে ফিরে আসে। সর্বোত্তম অভ্যাস হল প্রতিটি স্প্রিন্টের 10–15 শতাংশ সক্ষমতা প্রযুক্তিগত পরিষ্কারের জন্য বরাদ্দ করা, যার মধ্যে জাঙ্ক অডিট অন্তর্ভুক্ত।

প্রক্রিয়াটি চারটি ধাপে গঠিত। প্রথম — নির্ণয়: টুল চালান, রিপোর্ট পান, অগ্রাধিকার নির্ধারণ করুন। উচ্চ অগ্রাধিকার: পরিচিত CVE-যুক্ত ডিপেন্ডেন্সি এবং ডুপ্লিকেট লাইব্রেরি। মধ্যম অগ্রাধিকার: মৃত ইম্পোর্ট এবং মন্তব্যকৃত কোড। নিম্ন অগ্রাধিকার: অপ্রয়োজনীয় অ্যাবস্ট্র্যাকশন (ম্যানুয়াল বিশ্লেষণ প্রয়োজন)।

দ্বিতীয় — পরিষ্কার: মৃত ডিপেন্ডেন্সি সরান, ডুপ্লিকেট লাইব্রেরি একটিতে প্রতিস্থাপন করুন, মন্তব্যকৃত কোড মুছুন। প্রতিটি পরিবর্তন স্পষ্ট বার্তাসহ পৃথক কমিট হতে হবে: “remove unused dependency: gson (replaced by kotlinx.serialization)”, “delete commented code in LoginViewModel.”

তৃতীয় — যাচাইকরণ: প্রকল্প বিল্ড করুন, পরীক্ষা চালান, UI পরীক্ষা করুন। ডিপেন্ডেন্সি সরানোর পর যদি পরীক্ষা পাস হয়, ডিপেন্ডেন্সিটি সত্যিই অপ্রয়োজনীয় ছিল। যদি পরীক্ষা ব্যর্থ হয়, কোথাও লুকানো রেফারেন্স আছে যা স্থিতিশীল বিশ্লেষক সনাক্ত করেনি।

চতুর্থ — প্রতিরোধ: কোড পর্যালোচনা চেকলিস্ট আপডেট করুন, Definition of Done-এ “যুক্তি ছাড়া কোনো নতুন ডিপেন্ডেন্সি নয়” নিয়ম যোগ করুন, CI-তে স্বয়ংক্রিয় পরীক্ষা সেট করুন। প্রতিরোধই জাঙ্ক পুনরায় জমা হওয়া রোধের একমাত্র উপায়।